Agenda, 14 January 2016 SVG WG telcon

Previous Topic Next Topic
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Agenda, 14 January 2016 SVG WG telcon

Nikos Andronikos
Please find the agenda for this week’s telcon below.
Phone: +1-617-324-0000 (access code: 649 040 824)
IRC for minutes/discussion: #svg on, port 6665
Agenda requests:
WebEx logistics:

* Behaviour of getBBox on the various text elements ( (nikos)
* Precision and Accuracy for spatial data ( (nikos)
* SVG 2 chapter progress followed by spec editing (nikos)


The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Reply | Threaded
Open this post in threaded view

minutes, 14 January 2016 SVG WG telcon

Cameron McCormack-4
Minutes for today’s call:

and below as text for bots:



                               - DRAFT -

                    SVG Working Group Teleconference

14 Jan 2016



   See also: [3]IRC log



          nikos, heycam, shepazu, stakagi, AmeliaBR, Tav




     * [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: 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]


   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
   ... 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

   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:


   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:


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



   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



   "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


   <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: 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:




   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
   ... 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?



   <scribe> ACTION: Cameron to draft a couple of sentences
   describing lat/long map data accuracy issue [recorded in


   <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: 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
   ... in Painting there is really just the marker orientation
   issue, I'll coordinate with Bogdan so he take it from me to



   AmeliaBR: Interactivity currently issue 4 is listed as needing
   ... 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
   [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


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 ≝