W3C home > Mailing lists > Public > www-svg@w3.org > January 2016

minutes, 14 January 2016 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 15 Jan 2016 08:13:58 +1100
To: www-svg <www-svg@w3.org>
Message-ID: <20160114211358.GA24090@wok.mcc.id.au>
Minutes for today’s call:

  https://www.w3.org/2016/01/14-svg-minutes.html

and below as text for bots:


   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

14 Jan 2016

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/www-svg/2016Jan/0007.html

   See also: [3]IRC log

      [3] http://www.w3.org/2016/01/14-svg-irc

Attendees

   Present
          nikos, heycam, shepazu, stakagi, AmeliaBR, Tav

   Regrets
   Chair
          Nikos

   Scribe
          Cameron

Contents

     * [4]Topics
         1. [5]Bounding box for text
         2. [6]position and accuracy of spatial data
         3. [7]SVG 2 Chapters
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam

Bounding box for text

   <nikos>
   [10]https://lists.w3.org/Archives/Public/www-svg/2016Jan/0003.h
   tml

     [10] https://lists.w3.org/Archives/Public/www-svg/2016Jan/0003.html

   nikos: an www-svg email was sent yesterday referring to some
   various browser bug reports
   ... it has a question about getBBox for various elements,
   tspan, textPath and text
   ... getBBox on textPath is new in SVG 2, but we don't have text
   on how behaviour should be

   <nikos> [11]http://jsfiddle.net/dodgeyhack/902mvwq5/

     [11] http://jsfiddle.net/dodgeyhack/902mvwq5/

   nikos: Chrome and WebKit currently support getBBox on textPath,
   here's a test file
   ... they return the bbox of the ancestor text element
   ... I think that's not the behaviour we'd be going for

   AmeliaBR: one of the complications is that when it comes to
   stuff like paint servers it is very clearly said that on a
   tspan the reference bounding box is the entire text element's
   bbox
   ... that might be where the problem came in in implementations
   ... as you say that's not what user's expect when they're doing
   getBBox on a tspan or textPath

   nikos: for the Chrome and WebKit implementations, I'm not sure
   they're new, so they might be nonconforming from a while ago

   BogdanBrinza_: I haven't looked into this issue but am trying
   now

   AmeliaBR: right now we don't have specific text related to bbox
   in the Text chapter, it's just in coords and interfaces

   nikos: I thought the existing description should imply that the
   union of the glyph cells for the text path should be returned
   ... but it might be unclear

   AmeliaBR: there are the new getBBox parameters, so that's one
   option: add parameters that are text specific, whether you get
   the local bbox or the entire element's bbox
   ... but there's nothing text-specific in the general definition

   BogdanBrinza_: in Edge we don't have getBBox on <textPath>

   <AmeliaBR> Current SVG 2 text for getBBox:
   [12]https://svgwg.org/svg2-draft/types.html#InterfaceSVGGraphic
   sElement

     [12] https://svgwg.org/svg2-draft/types.html#InterfaceSVGGraphicsElement

   nikos: do implementors see any difficulties in returning a box
   just for glyphs in the textPath?

   heycam: no it should be straightforward

   BogdanBrinza_: I think it makes sense

   nikos: I propose we resolve on that then

   <AmeliaBR> Bounding Box for painting text:
   [13]https://svgwg.org/svg2-draft/text.html#TextElement

     [13] https://svgwg.org/svg2-draft/text.html#TextElement

   AmeliaBR: I think that is old text in that link there
   ... [quotes text regarding objectBoundingBox calculations]

   [14]https://svgwg.org/svg2-draft/coords.html#BoundingBoxes

     [14] https://svgwg.org/svg2-draft/coords.html#BoundingBoxes

   heycam: that section I added, which defines how getBBox return
   values are computed
   ... I don't think we want to change how objectBoundingBox for
   paint servers is interpreted

   AmeliaBR: we perhaps should allow specifying which bbox should
   be used for objectBoundingBox
   ... so perhaps you could have text-specific things in there
   (choose the "tspan" box for example)
   ... I don't think it would be confusing to stick with the
   current behaviour for now, though
   ... there are two sections of text that need clarification
   ... in the Text chapter, this paragraph about object bounding
   boxes it would be good to clarify that that doesn't affect the
   result of getBBox
   ... and then in the Coords chapter, when it's giving the
   default of getBBox calculations, to have a sentence
   specifically about tspans and textPaths

   [15]https://svgwg.org/svg2-draft/coords.html#issue14

     [15] https://svgwg.org/svg2-draft/coords.html#issue14

   "a shape that includes each of the glyph cells corresponding to
   the text within the elements"

   AmeliaBR: I think as far as a normative definition we don't
   have to change anything, but it would be worth having a short
   informative note pointing out the difference between getBBox
   and objectBoundingBox
   ... cross-linked to the Text chapter
   ... because it is a logical inconsistency

   RESOLUTION: Only the glyphs included within a tspan or textPath
   are included in the calculations for getBBox

   <scribe> ACTION: Nikos to clarify that getBBox on
   tspan/textPath includes only that element's glyphs, but that
   objectBoundingBox values still are computed relative to the
   entire text element [recorded in
   [16]http://www.w3.org/2016/01/14-svg-minutes.html#action01]

     [16] http://www.w3.org/2016/01/14-svg-minutes.html#action01]

   <trackbot> Created ACTION-3829 - Clarify that getbbox on
   tspan/textpath includes only that element's glyphs, but that
   objectboundingbox values still are computed relative to the
   entire text element [on Nikos Andronikos - due 2016-01-21].

position and accuracy of spatial data

   <nikos>
   [17]https://lists.w3.org/Archives/Public/www-svg/2016Jan/0006.h
   tml

     [17] https://lists.w3.org/Archives/Public/www-svg/2016Jan/0006.html

   nikos: an email from Chris Little
   ... I haven't done a lot of background research into this

   <AmeliaBR> This is current text on precision in SVG:
   [18]https://svgwg.org/svg2-draft/types.html#Precision

     [18] https://svgwg.org/svg2-draft/types.html#Precision

   <stakagi>
   [19]https://svgwg.org/svg2-draft/conform.html#ConformingSVGView
   ers

     [19] https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewers

   AmeliaBR: it's the issue of being able to maintain precise
   differences between numbers while also having an overall
   magnitude -- when you're talking about mapping neighbourhoods,
   110.003 vs 110.004 for example

   <stakagi> > The viewer must use at least single-precision
   floating point for intermediate ....

   AmeliaBR: and that can be problematic when using single
   precision floats

   nikos: I was thrown off by his mention of the mapping data
   itself being out by a certain amount

   heycam: we get bug reports about these kinds of precision
   issues
   ... we usually tell users to transform the coords into a
   smaller range so it can work

   AmeliaBR: performing those calculations normalising those
   coords wouldn't be feasible for the implementation to do

   nikos: yes that's not likely to be specced

   AmeliaBR: we can encourage the SDW WG to consider ways of
   clearly defining precision/accuracy so that a certain graphic
   could declare the transforms that would be necessary to
   maintain accuracy and precision, I don't know
   ... but we'd need a specific request from them

   nikos: should we resolve to have a short informative text
   pointing out this issue?

   <nikos>
   [20]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assess
   ment

     [20] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

   <scribe> ACTION: Cameron to draft a couple of sentences
   describing lat/long map data accuracy issue [recorded in
   [21]http://www.w3.org/2016/01/14-svg-minutes.html#action02]

     [21] http://www.w3.org/2016/01/14-svg-minutes.html#action02]

   <trackbot> Created ACTION-3830 - Draft a couple of sentences
   describing lat/long map data accuracy issue [on Cameron
   McCormack - due 2016-01-21].

SVG 2 Chapters

   <nikos>
   [22]http://webcache.googleusercontent.com/search?q=cache:PYxr1j
   dMuGIJ:https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Ass
   essment+&cd=1&hl=en&ct=clnk&gl=us

     [22] http://webcache.googleusercontent.com/search?q=cache:PYxr1jdMuGIJ:https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment+&cd=1&hl=en&ct=clnk&gl=us

   nikos: for me, I was going to look at Coords chapter, I haven't
   done a lot on that yet. my plan is to take a solid week before
   the F2F to work on that.
   ... I'll tidy up what I can, resolve the two issues in there,
   and a couple of other actions about stroking

   heycam: I am focussing on the text layout algorithm before the
   F2F
   ... in Painting there is really just the marker orientation
   issue, I'll coordinate with Bogdan so he take it from me to
   investigate

   <AmeliaBR>
   [23]https://svgwg.org/svg2-draft/interact.html#issue4

     [23] https://svgwg.org/svg2-draft/interact.html#issue4

   AmeliaBR: Interactivity currently issue 4 is listed as needing
   discussion
   ... that's related to focus and tabindex. I can see if the SVG
   Accessibility TF can look over it.

   nikos: struct.html has three issues for discussion; I'll mail
   Erik to see if he will have a chance, otherwise we can talk
   about them next week

   heycam: Styling has two issues both just about pointing to
   css-text-4 for the new white-space value
   ... I'll check if that spec has been published

   RRSAgent: make minutes

Summary of Action Items

   [NEW] ACTION: Cameron to draft a couple of sentences describing
   lat/long map data accuracy issue [recorded in
   [24]http://www.w3.org/2016/01/14-svg-minutes.html#action02]
   [NEW] ACTION: Nikos to clarify that getBBox on tspan/textPath
   includes only that element's glyphs, but that objectBoundingBox
   values still are computed relative to the entire text element
   [recorded in
   [25]http://www.w3.org/2016/01/14-svg-minutes.html#action01]

     [24] http://www.w3.org/2016/01/14-svg-minutes.html#action02
     [25] http://www.w3.org/2016/01/14-svg-minutes.html#action01

Summary of Resolutions

    1. [26]Only the glyphs included within a tspan or textPath are
       included in the calculations for getBBox

   [End of minutes]
     __________________________________________________________


-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 14 January 2016 21:14:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:43 UTC