<trackbot> Date: 27 March 2014

<scribe> scribenick: cabanier

How to calculate bboxes for text

ed: I was looking at a bug for text rendering in blink
... for some fonts, the bouding box was not encompassing the text
... the filter that I was applying, didn't cover the text. I found that the spec is unclear
... I was hoping to get agreement and clarification on glyph cells and bounding boxes on text elements
... if you have a font where the glyphs go outside the advance width

<ed> https://www.google.com/fonts/specimen/Bangers

ed: some browser use this for the bounding box

heycam: I've used glyphs that go outside the box

ed: if you look that page and select the text, you will see that the last charactor is not selected
... my first question is: the x position of the glyph cell, should that always be 0 or can it be a negative value?

heycam: I can't remember the term in the font
... weren't we going to take the glyph cells and union that with the ink boundary?

tav: this is quite complicated because kerning can move the characters
... the box is a good starting point, but maybe you need an additional margin

ed: I would like to see a boundingbox that tightly encompasses the glyphs shapes

tav: a font designer spends a lot of time thinking about htis
... I'm not sure that using the painted region is what you want
... because the text shouldn't always change the dimension of the box
... give what the font designers give you and then add padding

ed: for first last characters? all the glyphs?

tav: the height is always the same
... this makes it an easy calculation

cabanier: doesn't the font have the bounding box?

Tav: that is not always the correct one
... I'm not sure if you can do better by looking at the painted region

heycam: maybe you want to make sure that hit testing uses the painted area of the text

ed: what would you base the padding on?

heycam: the author would set it

ed: that doesn't work for web fonts since you don't know if you get it or if there's a fallback one

Tav: it should be pretty simila

heycam: if there's overflow etc. maybe the padding should be based on the worst character of the font

Tav: if you have a stem going down the line, you don't want them to be different height

ed: when it comes to the width, there's a difference between the browser

<ed> <text filter="url(#obb-filter)">some slanted text</text>

ed: obb-filter could put the text back, you don't get all the text back

cabanier: and this is a spec bug?

ed: it's not clear enough
... we never define the term of glyph cell

cabanier: advance is clearly incorrect

ed: you could look at things

heycam: you will have to look at the glyphs in the glyphs in case they overflow a lot too
... this does need extra calculations

ed: some browsers do it the way I expect
... so they have something like a painted bounding box

heycam: we could add an extra flag to opt into that

cabanier: not as the default

heycam: would we still union it so it's possible to make it bigger?

<Tav> http://fontforge.org/overview.html#Baseline

heycam: would you like to have it controlable?

ed: that sounds like a good thing. I would like the default to cover the rendered area

heycam: do you know what the different browsers do?

ed: I have a test case. FF, presto gave a bbox that encompassed the rendered glyphs fully. Chrome did not.
... (looking for test case)

<heycam> "right"

:-)

ed: Firefox and presto had the full rendered bounding box of the text run
... I'll bring the text case to the F2F

heycam: I can see 3 different behaviors
... 1 = exact glyph shapes
... 2 = union of glyph cells and the bounding box of each glyph
... 3 = just the glyph cells
... hit testing would be interesting as well

ed: a 4th one would include text decorations

cabanier: those would be needed for filters as well?

Tav: a 5th one would include padding

ed: I don't think we define anything for how hit testing on text is done
... it's up to the ua to figure this out

heycam: I think hit testing for mouseover was the reason we added the glyph cell approach

ed: text rendering, should that affect the result?
... you might get different bounds for different rendering modes
... we don't call this out in the spec

heycam: it probably should

ed: these are all the questions I had in the mail

heycam: what should be the default and how many options should be offer?

ed: yes, and define the correct term

heycam: let's make a decision at the F2F

Charter to use for SVG/PF work on SVG ARIA mapping

richardschwerdtfeger: we had a meeting yesterday on what spec type to create (respec, etc)
... whose IP policy do we follow?
... where do publish it? PF or SVG?
... what does the group think about that

heycam: Doug would be the best one to know
... how does the FX group work?

ed: the IP policy is for both of the groups

richardschwerdtfeger: it could be a joint publication
... I do know that HTML5 implementation
... there's a core ARIA spec that says how to map the a11y API
... and then there's a HTML 5 spec that references that
... each platform implements it differently

heycam: my feeling is that the PF people will do most of the work
... so it feels like it makes most sense to do it there

richardschwerdtfeger: does that mean that members need to join in order to contribute?

heycam: I'm unsure

richardschwerdtfeger: let me check with Doug

heycam: Chris is the official team contact
... I would like to know from them what is the best approach

richardschwerdtfeger: you're OK if it's done by PF

heycam: let me look into that

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

Media queries in switch

http://lists.w3.org/Archives/Public/www-svg/2014Mar/0008.html

heycam: this was a request from the mailing list
... the proposal was for an additional processing attribute called 'media'
... the first one that matches would be rendered
... is this a good idea? If so, what timeframe?

<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#5.9.2_The_.27switch.27_element

heycam: I don't remember the decision
... my feeling is that it's a simple thing to add
... and it would be Ok to add in the SVG 2 timeframe

cabanier: you can't just do this by using CSS?

heycam: it's slightly tricky. you would have to combinate them somehow

cabanier: it feels like CSS should solve that

heycam: maybe
... you could imagine that something like that exists
... but that would be similar to adding it to the markup
... it feels like a natural place to put it
... let's discuss it at the F2F

ed: doesn't sound like a bad idea but I'm not a fan of the switch element

heycam: in HTML some elements have the media attribute
... in SVG, it seems like a reasonable parallel
... let's keep it on the agenda of the F2F
... next week we won't have a meeting

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/encompasses/tightly encompasses/
Succeeded: s/correctly/the way I expect/
Succeeded: s/did it right/gave a bbox that encompassed the rendered glyphs fully/
Found ScribeNick: cabanier
Inferring Scribes: cabanier
Default Present: [IPcaller], ed, heycam, cabanier, stakagi, Tav, Rich_Schwerdtfeger, birtles
Present: [IPcaller] ed heycam cabanier stakagi Tav Rich_Schwerdtfeger birtles
Regrets: Brian Dirk
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0139.html
Found Date: 27 Mar 2014
Guessing minutes URL: http://www.w3.org/2014/03/27-svg-minutes.html
People with action items: