IRC log of svg on 2016-01-14

Timestamps are in UTC.

20:29:18 [RRSAgent]
RRSAgent has joined #svg
20:29:18 [RRSAgent]
logging to http://www.w3.org/2016/01/14-svg-irc
20:29:20 [trackbot]
RRSAgent, make logs public
20:29:22 [trackbot]
Zakim, this will be GA_SVGWG
20:29:22 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
20:29:23 [trackbot]
Meeting: SVG Working Group Teleconference
20:29:23 [trackbot]
Date: 14 January 2016
20:29:42 [nikos]
RRSAgent, make logs public
20:30:04 [nikos]
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Jan/0007.html
20:30:08 [nikos]
present+ nikos
20:33:03 [heycam]
present+ heycam
20:34:16 [shepazu]
present+ shepazu
20:34:20 [stakagi]
present+ stakagi
20:34:21 [BogdanBrinza_]
BogdanBrinza_ has joined #svg
20:35:01 [AmeliaBR]
present+ AmeliaBR
20:35:19 [heycam]
Scribe: Cameron
20:35:21 [heycam]
ScribeNick: heycam
20:35:21 [nikos]
chair: Nikos
20:35:36 [heycam]
Topic: Bounding box for text
20:35:48 [nikos]
https://lists.w3.org/Archives/Public/www-svg/2016Jan/0003.html
20:36:05 [heycam]
nikos: an www-svg email was sent yesterday referring to some various browser bug reports
20:36:17 [heycam]
... it has a question about getBBox for various elements, tspan, textPath and text
20:36:28 [heycam]
... getBBox on textPath is new in SVG 2, but we don't have text on how behaviour should be
20:36:34 [nikos]
http://jsfiddle.net/dodgeyhack/902mvwq5/
20:36:39 [heycam]
... Chrome and WebKit currently support getBBox on textPath, here's a test file
20:36:45 [heycam]
... they return the bbox of the ancestor text element
20:36:52 [heycam]
... I think that's not the behaviour we'd be going for
20:37:18 [heycam]
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
20:37:29 [heycam]
... that might be where the problem came in in implementations
20:37:43 [heycam]
... as you say that's not what user's expect when they're doing getBBox on a tspan or textPath
20:38:13 [heycam]
nikos: for the Chrome and WebKit implementations, I'm not sure they're new, so they might be nonconforming from a while ago
20:38:46 [heycam]
BogdanBrinza_: I haven't looked into this issue but am trying now
20:39:12 [heycam]
AmeliaBR: right now we don't have specific text related to bbox in the Text chapter, it's just in coords and interfaces
20:39:26 [heycam]
nikos: I thought the existing description should imply that the union of the glyph cells for the text path should be returned
20:39:30 [heycam]
... but it might be unclear
20:40:00 [heycam]
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
20:40:08 [heycam]
... but there's nothing text-specific in the general definition
20:40:27 [heycam]
BogdanBrinza_: in Edge we don't have getBBox on <textPath>
20:40:36 [AmeliaBR]
Current SVG 2 text for getBBox: https://svgwg.org/svg2-draft/types.html#InterfaceSVGGraphicsElement
20:40:48 [heycam]
nikos: do implementors see any difficulties in returning a box just for glyphs in the textPath?
20:40:56 [heycam]
heycam: no it should be straightforward
20:41:10 [heycam]
BogdanBrinza_: I think it makes sense
20:41:23 [heycam]
nikos: I propose we resolve on that then
20:42:27 [AmeliaBR]
Bounding Box for painting text: https://svgwg.org/svg2-draft/text.html#TextElement
20:42:42 [heycam]
AmeliaBR: I think that is old text in that link there
20:43:03 [heycam]
AmeliaBR: [quotes text regarding objectBoundingBox calculations]
20:43:20 [heycam]
https://svgwg.org/svg2-draft/coords.html#BoundingBoxes
20:44:37 [heycam]
heycam: that section I added, which defines how getBBox return values are computed
20:45:47 [heycam]
heycam: I don't think we want to change how objectBoundingBox for paint servers is interpreted
20:46:02 [heycam]
AmeliaBR: we perhaps should allow specifying which bbox should be used for objectBoundingBox
20:46:19 [heycam]
... so perhaps you could have text-specific things in there (choose the "tspan" box for example)
20:46:29 [heycam]
... I don't think it would be confusing to stick with the current behaviour for now, though
20:47:25 [heycam]
AmeliaBR: there are two sections of text that need clarification
20:47:39 [heycam]
... 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
20:48:00 [heycam]
... and then in the Coords chapter, when it's giving the default of getBBox calculations, to have a sentence specifically about tspans and textPaths
20:48:04 [heycam]
https://svgwg.org/svg2-draft/coords.html#issue14
20:48:24 [heycam]
"a shape that includes each of the glyph cells corresponding to the text within the elements"
20:48:56 [heycam]
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
20:49:03 [heycam]
... cross-linked to the Text chapter
20:49:10 [heycam]
... because it is a logical inconsistency
20:49:11 [Tav]
present+ Tav
20:50:15 [heycam]
RESOLUTION: Only the glyphs included within a tspan or textPath are included in the calculations for getBBox
20:50:27 [heycam]
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
20:50:28 [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].
20:51:10 [heycam]
Topic: position and accuracy of spatial data
20:51:13 [nikos]
https://lists.w3.org/Archives/Public/www-svg/2016Jan/0006.html
20:51:18 [heycam]
nikos: an email from Chris Little
20:51:26 [heycam]
... I haven't done a lot of background research into this
20:52:42 [AmeliaBR]
This is current text on precision in SVG: https://svgwg.org/svg2-draft/types.html#Precision
20:53:43 [stakagi]
https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewers
20:54:21 [heycam]
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
20:54:27 [stakagi]
> The viewer must use at least single-precision floating point for intermediate ....
20:54:29 [heycam]
... and that can be problematic when using single precision floats
20:54:53 [heycam]
nikos: I was thrown off by his mention of the mapping data itself being out by a certain amount
20:56:16 [heycam]
heycam: we get bug reports about these kinds of precision issues
20:56:25 [heycam]
... we usually tell users to transform the coords into a smaller range so it can work
20:56:54 [heycam]
AmeliaBR: performing those calculations normalising those coords wouldn't be feasible for the implementation to do
20:56:59 [heycam]
nikos: yes that's not likely to be specced
20:57:32 [heycam]
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
20:57:39 [heycam]
... but we'd need a specific request from them
20:58:00 [heycam]
nikos: should we resolve to have a short informative text pointing out this issue?
20:58:47 [nikos]
https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment
20:58:50 [heycam]
ACTION: Cameron to draft a couple of sentences describing lat/long map data accuracy issue
20:58:50 [trackbot]
Created ACTION-3830 - Draft a couple of sentences describing lat/long map data accuracy issue [on Cameron McCormack - due 2016-01-21].
21:00:19 [heycam]
Topic: SVG 2 Chapters
21:00:49 [nikos]
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
21:01:30 [heycam]
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.
21:02:01 [heycam]
... I'll tidy up what I can, resolve the two issues in there, and a couple of other actions about stroking
21:03:20 [heycam]
heycam: I am focussing on the text layout algorithm before the F2F
21:05:37 [heycam]
... in Painting there is really just the marker orientation issue, I'll coordinate with Bogdan so he take it from me to investigate
21:06:18 [AmeliaBR]
https://svgwg.org/svg2-draft/interact.html#issue4
21:06:33 [heycam]
AmeliaBR: Interactivity currently listed as 4
21:07:19 [heycam]
... that's related to focus and tabindex. I can see if the SVG Accessibility TF can look over it.
21:07:54 [heycam]
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
21:08:29 [AmeliaBR]
s/listed as 4/issue 4 is listed as needing discussion/
21:09:25 [heycam]
heycam: Styling has two issues both just about pointing to css-text-4 for the new white-space value
21:09:35 [heycam]
... I'll check if that spec has been published
21:10:21 [heycam]
RRSAgent: make minutes
21:10:21 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/01/14-svg-minutes.html heycam
21:26:22 [stakagi]
stakagi has joined #svg
23:17:00 [jdaggett]
jdaggett has joined #svg