Meeting minutes 2014-03-27

here are the meeting minutes from March 13 2014:  http://www.w3.org/2014/03/27-svg-minutes.html

SVG Working Group Teleconference

27 Mar 2014

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0139.html

   See also: [3]IRC log

      [3] http://www.w3.org/2014/03/27-svg-irc

Attendees

   Present
          [IPcaller], ed, heycam, cabanier, stakagi, Tav,
          Rich_Schwerdtfeger, birtles

   Regrets
          Brian, Dirk

   Chair
          Cameron

   Scribe
          cabanier

Contents

     * [4]Topics
         1. [5]How to calculate bboxes for text
         2. [6]Charter to use for SVG/PF work on SVG ARIA mapping
         3. [7]Media queries in switch
     * [8]Summary of Action Items
     __________________________________________________________

   <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> [9]https://www.google.com/fonts/specimen/Bangers

      [9] 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> [10]http://fontforge.org/overview.html#Baseline

     [10] 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

   [11]http://lists.w3.org/Archives/Public/www-svg/2014Mar/0008.ht
   ml

     [11] 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>
   [12]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Li
   ke_Syntax#5.9.2_The_.27switch.27_element

     [12] 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

Summary of Action Items

Received on Thursday, 27 March 2014 21:31:29 UTC