IRC log of svg on 2014-03-27

Timestamps are in UTC.

20:27:31 [RRSAgent]
RRSAgent has joined #svg
20:27:31 [RRSAgent]
logging to
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]
20:28:25 [Zakim]
GA_SVGWG(SVG1)4:30PM has now started
20:28:31 [Zakim]
20:28:41 [ed]
Zakim, [IP is me
20:28:41 [Zakim]
+ed; got it
20:29:01 [Zakim]
20:29:03 [heycam]
Zakim, [ is me
20:29:03 [Zakim]
+heycam; got it
20:31:24 [Zakim]
20:32:29 [Zakim]
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]
20:35:24 [cabanier]
scribenick: cabanier
20:35:36 [cabanier]
topic: How to calculate bboxes for text
20:35:48 [Zakim]
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]
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]
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]
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]
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]
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]
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]
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]
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]
21:26:34 [Zakim]
21:26:35 [Zakim]
21:26:36 [Zakim]
21:26:36 [Zakim]
21:26:38 [Zakim]
21:28:16 [Zakim]
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 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