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