Closed Bug 885585 Opened 6 years ago Closed 6 years ago
svg stroke-dasharray in osx does not render path with zero length fragment
169 bytes, image/svg+xml
3.44 KB, text/plain
2.05 KB, text/plain
7.92 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36 Steps to reproduce: Open the attached svg file in firefox. OSX 10.8.4 FF 21.0 Actual results: Vertical line fails to render. Expected results: Vertical line should render. On the path element there's a stroke-dasharray attribute with a value of '23,0'. This should be valid (should just draw a line) but the zero value for skip appears to causing the path to fail to render.
I see the line with FF21 on Win 7: http://i.imgur.com/jvZODS6.jpg Maybe it's specific to OSX. Did it use to work in previous versions of FF?
Component: Untriaged → SVG
Product: Firefox → Core
It is specific to more recent versions of OSX, though this may be due to different GPU settings if the SVG rendering is going through the hardware pipeline. I'm also seeing this in Safari but not Chrome or Opera. I've attached a report from about:support. Let me know if you need any other info.
Did you test with a fresh profile? https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles (even if I think it's likely not the reason)
I still see the same result, which isn't surprising since we've seen some reports from customers for our SVG export. You'll likely be able to repro this on a Macbook Air.
I am somewhat confused in that the a.svg testcase has a stroke-dasharray='1,0' and yet comment 0 says the problem is with stroke-dasharray='23,0' Which one is the problem or is it either? Given a non-working testcase, if you change nothing other than remove the stroke-dasharray attribute it displays right? I can't see any issue but I'm on Windows so that's perhaps not so surprising.
To clarify, you can trigger this issue with any value greater than zero followed by a zero length fragment. stroke-dasharray="x,0" where x is > 0. And yes, if you remove the attribute the path draws correctly. The path also draws correctly for me when stroke-dasharray="0". So this is a pretty corner case issue, but I wanted to report this one. I've already filed a bug on our side for Gliffy. http://jira.gliffy.com/browse/JXFORM-612
Per http://www.w3.org/TR/SVG/painting.html#StrokeDasharrayProperty If the sum of the values is zero, then the stroke is rendered as if a value of none were specified So that's why stroke-dasharray="0" works.
Verified on OS X. I guess this is a problem with Quartz. The documentation for CGContextSetLineDash doesn't say anything about not handling particular dash arrays. I tested with stroke-dasharray="10,10,10,0" and that renders OK. So I guess it is just a problem when the gaps all add up to 0.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → cam
Status: NEW → ASSIGNED
Attachment #766214 - Flags: review?(longsonr)
Can't we do this at a lower level i.e. when we render the line in Quartz in the platform code?
Yeah, we could do this as a Cairo patch instead.
I think that would be better.
Comment on attachment 766280 [details] [diff] [review] patch v2 and r?longsonr for the SVG test.
Attachment #766280 - Flags: review?(longsonr)
Attachment #766280 - Flags: review?(longsonr) → review+
Attachment #766280 - Flags: review?(vladimir) → review+
Backed out in http://hg.mozilla.org/integration/mozilla-inbound/rev/75895fe57f56 because Windows says it's had way too much coffee to draw a straight diagonal line, https://tbpl.mozilla.org/php/getParsedLog.php?id=24480773&tree=Mozilla-Inbound
b2g, unwilling to let anyone do a worse job of rendering than it, also failed.
And bringing up the rear, Android.
Let's just try without the diagonal line. https://hg.mozilla.org/integration/mozilla-inbound/rev/6409ddd66eaa
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.