See also: IRC log
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
<nikos> 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> 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: 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: https://svgwg.org/svg2-draft/text.html#TextElement
AmeliaBR: I think that is old
text in that link there
... [quotes text regarding objectBoundingBox calculations]
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
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 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].
<nikos> 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: https://svgwg.org/svg2-draft/types.html#Precision
<stakagi> 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> 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 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].
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> 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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/listed as 4/issue 4 is listed as needing discussion/ Found Scribe: Cameron Found ScribeNick: heycam Present: nikos heycam shepazu stakagi AmeliaBR Tav Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Jan/0007.html Found Date: 14 Jan 2016 Guessing minutes URL: http://www.w3.org/2016/01/14-svg-minutes.html People with action items: cameron nikos[End of scribe.perl diagnostic output]