User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.12) Gecko/20080302 SeaMonkey/1.1.8 Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b3) Gecko/20100804 Firefox/4.0b3 A path with stroke-linecap="round" like <path d="M0,0z m50,0z m50,0z m50,0z"/> is only partly visible if it extends over a large area. Note that this doesn't happen if "M0,0h0" is used instead of "M0,0z". Reproducible: Always Steps to Reproduce: 1. Load testcase Actual Results: Several points are clipped off. Expected Results: Each row should have 4 visible black points. First 15 rows are of type "M0,0z" (exposing the bug), next 15 rows are of type "M0,0h0" (no bug).

Here's a reduced testcase with just 1 path that has 2 single-point subpaths. It demonstrates the bug for me. (Left circle is clipped, with the amount of clipping depending on the offset of the right circle.) Note: * Opera & Inkscape draw no circles at all, for both testcases here. * Midori (Webkit) draws full circles, for both testcases here. (though on the first one, I had to remove the doctype tag and the 'encoding' from the xml-version tag, in order to get midori to render it at all) Not sure which is correct (i.e. whether zero-length subpaths are supposed to get linecaps), but as long as we're drawing the linecaps, we shouldn't be clipping them.

BTW, I'm using: Mozilla/5.0 (X11; Linux i686; rv:2.0b3pre) Gecko/20100803 Minefield/4.0b3pre

> Not sure which is correct (i.e. whether zero-length subpaths are supposed to > get linecaps), but as long as we're drawing the linecaps, we shouldn't be > clipping them. The second edition of SVG 1.1 is even clearer than previous versions of the spec: | A subpath (see Paths) consisting of a single moveto shall not be stroked. | Any zero length subpath shall not be stroked if the ‘stroke-linecap’ | property has a value of butt but shall be stroked if the ‘stroke-linecap’ | property has a value of round or square, producing respectively a circle | or a square centered at the given point. Examples of zero length subpaths | include 'M 10,10 L 10,10', 'M 20,20 h 0', 'M 30,30 z' and | 'M 40,40 c 0,0 0,0 0,0'. http://www.w3.org/TR/SVG/painting.html#StrokeProperty Zero length subpaths are very useful to get stylable circles and to plot graphs with many values and still compact code. The bug not to draw them is quite common in SVG browser and renderer and tends to be broken again once it has been fixed. It has been fixed in Mozilla at least 2 times: bug 355842 bug 510177

Actually a Cairo bug. Current Cairo code is much different from the code included in Mozilla, but the bug seems to be still present. The workaround introduced in bug 510177 attachment 418529 [details] [diff] [review] doesn't work for cases with multiple subpaths and seems obsolete if Cairo code is fixed.

We need a better cairo API (that returns the device space region) or fixes to the current one to return something sensible here. I suggest you take this up on the cairo mailing list http://lists.cairographics.org/archives/cairo/

(In reply to comment #6) > We need a better cairo API (that returns the device space region) or fixes to > the current one to return something sensible here. I suggest you take this up > on the cairo mailing list http://lists.cairographics.org/archives/cairo/ What's the problem with the Cairo API with respect to this bug? cairo_path_extents() claims to do what it should to avoid this bug, but actually doesn't. http://library.gnome.org/devel/cairo/stable/cairo-paths.html#cairo-path-extents I filed a bug against Cairo: https://bugs.freedesktop.org/show_bug.cgi?id=29422

This bug is no longer present for me in ff4 b9 on Mac 10.6.

It's still present on Windows.

Still present on linux, too (left circle in reduced testcase still clipped, as described in comment 2)

The upstream bug is said to have been fixed in October, so this bug may be gone if you build using your system Cairo library. I haven't verified it; the path bounder has been rewritten instead of applying a patch. https://bugs.freedesktop.org/show_bug.cgi?id=29422 However, it would be easy to fix this in Mozilla by applying the patch in attachment 463333 [details] [diff] [review] until the Cairo copy is upgraded.

Comment on attachment 463333 [details] [diff] [review] patch This will need a patch added to the cairo directory as well.

Also, make sure this makes it in as a reftest if possible.

Pushed by longsonr@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/edc9a58cf92e fix cairo bounds calculation for zero length lines. r=jmuizelaar