20:27:31 <RRSAgent> RRSAgent has joined #svg
20:27:31 <RRSAgent> logging to http://www.w3.org/2014/03/27-svg-irc
20:27:33 <trackbot> RRSAgent, make logs public
20:27:33 <Zakim> Zakim has joined #svg
20:27:35 <trackbot> Zakim, this will be GA_SVGWG
20:27:35 <Zakim> ok, trackbot; I see GA_SVGWG(SVG1)4:30PM scheduled to start in 3 minutes
20:27:36 <trackbot> Meeting: SVG Working Group Teleconference
20:27:36 <trackbot> Date: 27 March 2014
20:27:53 <heycam> Regrets: Brian, Dirk
20:27:56 <heycam> Chair: Cameron
20:28:02 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0139.html
20:28:25 <Zakim> GA_SVGWG(SVG1)4:30PM has now started
20:28:31 <Zakim> +[IPcaller]
20:28:41 <ed> Zakim, [IP is me
20:28:41 <Zakim> +ed; got it
20:29:01 <Zakim> +[IPcaller]
20:29:03 <heycam> Zakim, [ is me
20:29:03 <Zakim> +heycam; got it
20:31:24 <Zakim> +cabanier
20:32:29 <Zakim> +??P9
20:32:53 <stakagi> zakim, ??p9 is me
20:32:53 <Zakim> +stakagi; got it
20:33:37 <heycam> Zakim, who is on the call?
20:33:37 <Zakim> On the phone I see ed, heycam, cabanier, stakagi
20:34:31 <Zakim> +Tav
20:35:24 <cabanier> scribenick: cabanier
20:35:36 <cabanier> topic: How to calculate bboxes for text
20:35:48 <Zakim> +Rich_Schwerdtfeger
20:35:54 <cabanier> ed: I was looking at a bug for text rendering in blink
20:36:14 <cabanier> ... for some fonts, the bouding box was not encompassing the text
20:36:23 <Zakim> -stakagi
20:36:36 <cabanier> ... the filter that I was applying, didn't cover the text. I found that the spec is unclear
20:37:01 <cabanier> ... I was hoping to get agreement and clarification on glyph cells and bounding boxes on text elements
20:37:25 <Zakim> +??P9
20:37:40 <stakagi> zakim, ??p9 is me
20:37:40 <Zakim> +stakagi; got it
20:37:41 <cabanier> ed: if you have a font where the glyphs go outside the advance width
20:37:51 <ed> https://www.google.com/fonts/specimen/Bangers
20:37:58 <cabanier> ... some browser use this for the bounding box
20:38:27 <cabanier> heycam: I've used glyphs that go outside the box
20:38:47 <cabanier> ed: if you look that page and select the text, you will see that the last charactor is not selected
20:39:48 <cabanier> .. my first question is: the x position of the glyph cell, should that always be 0 or can it be a negative value?
20:40:15 <cabanier> heycam: I can't remember the term in the font
20:40:42 <cabanier> ... weren't we going to take the glyph cells and union that with the ink boundary?
20:41:08 <cabanier> tav: this is quite complicated because kerning can move the characters
20:41:27 <cabanier> ... the box is a good starting point, but maybe you need an additional margin
20:41:53 <cabanier> ed: I would like to see a boundingbox that encompasses the glyphs shapes
20:42:20 <cabanier> tav: a font designer spends a lot of time thinking about htis
20:42:28 <ed> s/encompasses/tightly encompasses/
20:42:37 <cabanier> ... I'm not sure that using the painted region is what you want
20:43:05 <cabanier> ... because the text shouldn't always change the dimension of the box
20:43:35 <cabanier> ... give what the font designers give you and then add padding
20:43:57 <cabanier> ed: for first last characters? all the glyphs?
20:44:12 <cabanier> tav: the height is always the same
20:44:27 <cabanier> ... this makes it an easy calculation
20:45:03 <cabanier> cabanier: doesn't the font have the bounding box?
20:45:19 <cabanier> Tav: that is not always the correct one
20:46:02 <cabanier> ... I'm not sure if you can do better by looking at the painted region
20:46:23 <cabanier> heycam: maybe you want to make sure that hit testing uses the painted area of the text
20:46:34 <cabanier> ed: what would you base the padding on?
20:47:03 <cabanier> heycam: the author would set it
20:47:26 <cabanier> ed: that doesn't work for web fonts since you don't know if you get it or if there's a fallback one
20:47:43 <cabanier> Tav: it should be pretty simila
20:48:42 <cabanier> heycam: if there's overflow etc. maybe the padding should be based on the worst character of the font
20:49:26 <cabanier> Tav: if you have a stem going down the line, you don't want them to be different height
20:50:57 <cabanier> ed: when it comes to the width, there's a difference between the browser
20:51:23 <ed> <text filter="url(#obb-filter)">some slanted text</text>
20:51:53 <cabanier> ed: obb-filter could put the text back, you don't get all the text back
20:52:06 <cabanier> cabanier: and this is a spec bug?
20:52:19 <cabanier> ed: it's not clear enough
20:52:40 <cabanier> ... we never define the term of glyph cell
20:53:00 <cabanier> cabanier: advance is clearly incorrect
20:54:14 <cabanier> ed: you could look at things
20:54:37 <cabanier> heycam: you will have to look at the glyphs in the glyphs in case they overflow a lot too
20:55:13 <cabanier> ... this does need extra calculations
20:55:33 <cabanier> ed: some browsers do it correctly
20:55:48 <cabanier> ... so they have something like a painted bounding box
20:56:01 <cabanier> heycam: we could add an extra flag to opt into that
20:56:09 <cabanier> cabanier: not as the default
20:56:15 <ed> s/correctly/the way I expect/
20:56:58 <cabanier> heycam: would we still union it so it's possible to make it bigger?
20:57:01 <Tav> http://fontforge.org/overview.html#Baseline
20:59:51 <cabanier> heycam: would you like to have it controlable?
21:00:15 <cabanier> ed: that sounds like a good thing. I would like the default to cover the rendered area
21:00:42 <cabanier> heycam: do you know what the different browsers do?
21:01:09 <cabanier> ed: I have a test case. FF, presto did it right. Chrome did not.
21:01:16 <cabanier> ... (looking for test case)
21:01:19 <heycam> "right"
21:02:02 <cabanier> :-)
21:02:24 <cabanier> ed: Firefox and presto had the full rendered bounding box of the text run
21:02:49 <cabanier> ... I'll bring the text case to the F2F
21:02:59 <cabanier> heycam: I can see 3 different behaviors
21:03:11 <cabanier> ... 1 = exact glyph shapes
21:04:01 <cabanier> ... 2 = union of glyph cells and the bounding box of each glyph
21:04:12 <cabanier> ... 3 = just the glyph cells
21:04:34 <cabanier> ... hit testing would be interesting as well
21:04:49 <cabanier> ed: a 4th one would include text decorations
21:05:15 <cabanier> cabanier: those would be needed for filters as well?
21:05:29 <cabanier> Tav: a 5th one would include padding
21:06:01 <ed> s/did it right/gave a bbox that encompassed the rendered glyphs fully/
21:06:50 <cabanier> ed: I don't think we define anything for how hit testing on text is done
21:07:07 <cabanier> ... it's up to the ua to figure this out
21:07:40 <cabanier> heycam: I think hit testing for mouseover was the reason we added the glyph cell approach
21:08:06 <cabanier> ed: text rendering, should that affect the result?
21:08:27 <cabanier> ... you might get different bounds for different rendering modes
21:08:36 <cabanier> ... we don't call this out in the spec
21:08:45 <cabanier> heycam: it probably should
21:09:08 <cabanier> ed: these are all the questions I had in the mail
21:09:25 <cabanier> heycam: what should be the default and how many options should be offer?
21:09:33 <cabanier> ed: yes, and define the correct term
21:10:00 <cabanier> heycam: let's make a decision at the F2F
21:10:08 <cabanier> topic: Charter to use for SVG/PF work on SVG ARIA mapping
21:10:47 <cabanier> richardschwerdtfeger: we had a meeting yesterday on what spec type to create (respec, etc)
21:10:58 <cabanier> ... whose IP policy do we follow?
21:11:14 <cabanier> ... where do publish it? PF or SVG?
21:11:23 <cabanier> ... what does the group think about that
21:11:36 <cabanier> heycam: Doug would be the best one to know
21:11:45 <cabanier> ... how does the FX group work?
21:11:57 <cabanier> ed: the IP policy is for both of the groups
21:12:11 <cabanier> richardschwerdtfeger: it could be a joint publication
21:12:27 <cabanier> ... I do know that HTML5 implementation
21:12:43 <cabanier> ... there's a core ARIA spec that says how to map the a11y API
21:12:59 <cabanier> ... and then there's a HTML 5 spec that references that
21:13:18 <cabanier> ... each platform implements it differently
21:13:54 <cabanier> heycam: my feeling is that the PF people will do most of the work
21:14:03 <cabanier> ... so it feels like it makes most sense to do it there
21:14:19 <cabanier> richardschwerdtfeger: does that mean that members need to join in order to contribute?
21:14:27 <cabanier> heycam: I'm unsure
21:14:35 <cabanier> richardschwerdtfeger: let me check with Doug
21:14:45 <cabanier> heycam: Chris is the official team contact
21:14:55 <cabanier> ... I would like to know from them what is the best approach
21:15:11 <cabanier> richardschwerdtfeger: you're OK if it's done by PF
21:15:17 <cabanier> heycam: let me look into that
21:16:40 <cabanier> richardschwerdtfeger: the group agrees that the PF group does the work. I will ask if  people would have to join the PF group if they want to contribute
21:17:22 <cabanier> topic: Media queries in switch
21:17:27 <cabanier>    http://lists.w3.org/Archives/Public/www-svg/2014Mar/0008.html
21:17:36 <cabanier> heycam: this was a request from the mailing list
21:18:02 <cabanier> ... the proposal was for an additional processing attribute called 'media'
21:18:11 <cabanier> ... the first one that matches would be rendered
21:19:01 <cabanier> ... is this a good idea? If so, what timeframe?
21:19:57 <heycam> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#5.9.2_The_.27switch.27_element
21:20:12 <cabanier> ... I don't remember the decision
21:20:36 <cabanier> ... my feeling is that it's a simple thing to add
21:20:48 <cabanier> ... and it would be Ok to add in the SVG 2 timeframe
21:21:06 <cabanier> cabanier: you can't just do this by using CSS?
21:21:35 <cabanier> heycam: it's slightly tricky. you would have to combinate them somehow
21:21:54 <Zakim> +[IPcaller]
21:21:55 <cabanier> cabanier: it feels like CSS should solve that
21:22:01 <cabanier> heycam: maybe
21:22:27 <cabanier> ... you could imagine that something like that exists
21:22:46 <cabanier> ... but that would be similar to adding it to the markup
21:22:58 <cabanier> ... it feels like a natural place to put it
21:23:25 <cabanier> ... let's discuss it at the F2F
21:23:40 <cabanier> ed: doesn't sound like a bad idea but I'm not a fan of the switch element
21:24:06 <cabanier> heycam: in HTML some elements have the media attribute
21:24:21 <cabanier> ... in SVG, it seems like a reasonable parallel
21:24:50 <cabanier> ... let's keep it on the agenda of the F2F
21:25:27 <cabanier> heycam: next week we won't have a meeting
21:26:27 <glenn> glenn has joined #svg
21:26:33 <Zakim> -ed
21:26:34 <Zakim> -Tav
21:26:35 <Zakim> -birtles
21:26:36 <Zakim> -heycam
21:26:36 <Zakim> -Rich_Schwerdtfeger
21:26:38 <Zakim> -stakagi
21:28:16 <Zakim> -cabanier
21:28:17 <Zakim> GA_SVGWG(SVG1)4:30PM has ended
21:28:17 <Zakim> Attendees were [IPcaller], ed, heycam, cabanier, stakagi, Tav, Rich_Schwerdtfeger, birtles
21:29:11 <cabanier> RRSAgent, make minutes
21:29:11 <RRSAgent> I have made the request to generate http://www.w3.org/2014/03/27-svg-minutes.html cabanier
22:27:21 <glenn> glenn has joined #svg
23:00:11 <shans__> shans__ has joined #svg
23:28:00 <glenn> glenn has joined #svg
23:43:42 <shans__> shans__ has joined #svg
23:43:42 <stakagi> stakagi has joined #svg
23:43:42 <ed> ed has joined #svg
23:43:42 <heycam> heycam has joined #svg
23:43:42 <astearns> astearns has joined #svg
23:43:42 <slightlyoff> slightlyoff has joined #svg
23:43:42 <krit> krit has joined #svg
23:43:42 <TabAtkins> TabAtkins has joined #svg
23:43:42 <cabanier> cabanier has joined #svg
23:43:42 <birtles> birtles has joined #svg
23:43:42 <nikos> nikos has joined #svg
23:43:42 <plinss> plinss has joined #svg
23:43:42 <pdr__> pdr__ has joined #svg
23:43:42 <Tav> Tav has joined #svg