This test is based on painting-control-04-f.svg from SVG 1.1SE testsuite. Both FF and Opera pass this one.
(In reply to comment #0) > This test is based on painting-control-04-f.svg from SVG 1.1SE testsuite. Both FF and Opera pass this one. Actually I got that wrong, I think neither support it. But the Spec clearly states it under http://www.w3.org/TR/SVG11/painting.html#StrokeProperties.
Created attachment 94333 [details] Patch
Comment on attachment 94333 [details] Patch Attachment 94333 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/8722558 New failing tests: svg/W3C-SVG-1.1-SE/painting-control-04-f.svg
Created attachment 94334 [details] Archive of layout-test-results from ec2-cr-linux-03 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-03 Port: Chromium Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment on attachment 94333 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=94333&action=review > Source/WebCore/rendering/svg/RenderSVGPath.cpp:97 > + p.move(0.0001f, 0); Ok, what if you have the following: <svg width="100%" height="100%" viewBox="0 0 0.0001 0.0001"> <path d="M 0 0.00005" stroke="blue"/> </svg> With your patch the rect would be as width as the whole SVG document but with a different height, wouldn't it?
Comment on attachment 94333 [details] Patch See my last comment.
Marking this bug as duplicate. *** This bug has been marked as a duplicate of bug 18356 ***
Comment on attachment 94333 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=94333&action=review > Source/WebCore/rendering/svg/RenderSVGPath.cpp:100 > + if (svgStyle->capStyle() == SquareCap && m_fillBoundingBox.width() < 1 && m_fillBoundingBox.height() < 1) { > + FloatPoint p = origPath.currentPoint(); > + p.move(0.0001f, 0); > + tempPath = origPath; > + tempPath.addLineTo(p); > + return tempPath; If we really want to handle it in WebKit, what about the following proposal: If we know, that the Path is not empty but has a length of zero, couldn't we emulate circles and rects here by creating them manually? we just have to take the stroke as fill and the stroke operation shouldn't get applied. We are in the correct user space at this point, so it shouldn't be hard to calculate the bounds of a rect or circle here. We just need the information about stroke-width.
(In reply to comment #8) > (From update of attachment 94333 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=94333&action=review > > > Source/WebCore/rendering/svg/RenderSVGPath.cpp:100 > > + if (svgStyle->capStyle() == SquareCap && m_fillBoundingBox.width() < 1 && m_fillBoundingBox.height() < 1) { > > + FloatPoint p = origPath.currentPoint(); > > + p.move(0.0001f, 0); > > + tempPath = origPath; > > + tempPath.addLineTo(p); > > + return tempPath; > > If we really want to handle it in WebKit, what about the following proposal: I think we have no choice but to support it, really... > If we know, that the Path is not empty but has a length of zero, couldn't we emulate circles and rects here by creating them manually? we just have to take the stroke as fill and the stroke operation shouldn't get applied. We are in the correct user space at this point, so it shouldn't be hard to calculate the bounds of a rect or circle here. We just need the information about stroke-width. I think this will always be a hack, unless toolkits magically will support it :) But your idea sounds like less of a hack than my idea, so I'll work on it as soon as I get some other patches out of the way. Cheers, Rob.