SVG non-scaling-stroke affects more then just the width
Reported by
s.charpe...@gmail.com,
Jun 6 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: 1. Make a SVG path with non-scaling-stroke effect 2. Make the SVG responsive to scale in % with browser size 3. Give SVG a stroke-dashArray and dashOffset 4. Resize the browser to see how the Dash follows the shape scaling of the stroke 5. Remove the non-scaling-stroke effect and compare how the Dash reacts to resizing. What is the expected behavior? non-scaling-stroke should only affect the stroke width according to this spec https://www.w3.org/TR/SVGTiny12/painting.html It shouldn't affect the dash array like it does. What went wrong? The dashArray and dashOffset scales like the width. Did this work before? N/A Does this work in other browsers? No I tested on Firefox and the same behavior were observed. Chrome version: 58.0.3029.110 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 25.0 r0
,
Jun 6 2017
The spec say that "the stroke outline" should be computed in the "host" coordinate space when non-scaling-stroke is in effect. It's hard to interpret this as not including any of the other stroke-affecting properties, hence the dash-generation take place in the host coordinate space as well. (IIRC initial use-cases for this feature was mapping applications, where I believe this interpretation make sense. That the spec mentions the "visual modification" of the stroke-width is probably more meant as an informational note than anything else.) With that as background, my reading of the steps above is that it is behaving as expected - the length of the path in its userspace (as returned by getPathLength) is not the same as the length of the path in the "host" coordinate space. Because of this, the result of the dash-generation will differ. (To contrast, consider a more "regular" dash pattern [say "5 2"] representing a "border" between two regions on a map.)
,
Jun 7 2017
Well in the W3 article I linked in the original post it specifically state that it has to do with the width. "The resulting visual effect of this modification is that stroke WIDTH is not dependant on the transformations of the element (including non-uniform scaling and shear transformations) and zoom level." Perhaps I should ask for a clearer specifications or the possibility to have non-scaling-stroke = "width" as a possible solution. It might have to do with the clarity of the specs
,
Jun 7 2017
Well, other stroke properties are dependent on the stroke width (such as the caps and joins - and caps apply to dashes.) But, yes, the spec could be made more clear.
,
Jun 7 2017
I raised an issue on the spec: https://github.com/w3c/svgwg/issues/323
,
Jun 7 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 7 2018
fs@, is this WontFix?
,
Jun 7 2018
Based on the responses in the issue I raised (link in c#5), I'd say it is. Otherwise it would be ExternalDependency - which isn't much better in practice. |
||||
►
Sign in to add a comment |
||||
Comment 1 by schenney@chromium.org
, Jun 6 2017Status: Available (was: Unconfirmed)