- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 15 Jan 2016 08:13:58 +1100
- To: www-svg <www-svg@w3.org>
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