Bug 61243 – zero-length path stroke test from ietestcenter fails

• Component: SVG
• Status: RESOLVED DUPLICATE

[Rob Buis]

This test is based on painting-control-04-f.svg from SVG 1.1SE testsuite. Both FF and Opera pass this one.

[Rob Buis]

(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.

[Rob Buis]

Created attachment 94333 [details]
Patch

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[Dirk Schulze]

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?

[Dirk Schulze]

Comment on attachment 94333 [details]
Patch

See my last comment.

[Dirk Schulze]

Marking this bug as duplicate.

*** This bug has been marked as a duplicate of bug 18356 ***

[Dirk Schulze]

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.

[Rob Buis]

(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.