Stroke rendering regression from 0.48.4 to 0.91

[Séverin Lemaignan]

The attached SVG renders correctly in Inkscape 0.48 but incorrectly in Inkscape 0.91: a gap between the stroke and the fill is visible. See attached PNG.

[Alvin Penner (apenner)]

- not reproduced on Windows 7 (32 bit), Inkscape 0.91 r13725 (Jan 30 2015)
- attached is a screenshot
- just for curiosity, was this originally a circle? because now it is not, it is a Bezier path, as though a `Object to Path` was done
- could you indicate, which OS?, which version of Inkscape, see Help->About

[Séverin Lemaignan (skadge)]

Thanks for following up.

The problematic render occurs on Ubuntu (tested on 3 different machines) with Inkscape 0.91 r13725 (stock Inkscape on Ubuntu 16.04).

The shape is indeed not a circle, but a path (actually generated by a 3rd party app).

[ScislaC (scislac)]

I am indeed seeing this issue on Ubuntu 16.04 as well both in 0.91 and trunk r14862.

[ScislaC (scislac)]

Now for the fun stuff... Chrome 52-dev renders it like Inkscape 0.91+ on Ubuntu. Firefox 46 renders it like 0.48 did.

[ScislaC (scislac)]

And I believe we have a winner, but will wait for Tavmjong or another source to comment. Batik renders it like Inkscape 0.91+ on Ubuntu 16.04 as well.

[Alvin Penner (apenner)]

- also confirmed on Windows XP, Inkscape 0.91+devel r14860 (Apr 19 2016)

- fwiw the unusual behavior is related to the endpoint type in the stroke style. The original drawing uses the default stroke style of "butt cap". If you switch to "round cap" the problem disappears.

[LucaDC (lucadc)]

I had noticed that the new stroke renderer has problems when the stroke thickness is higher than the object dimensions.
For example, set the stroke width to 50 mm and try drawing a 20x2 mm ellipse: I get an instable internal void area (i.e. not filled with the fill color, between the stroke and the fill) while dragging the second point, both on XP 32bit and 7 64bit.
There is also a point when the ellipse is "narrow" enough (e.g. 50x0,5 mm) where its two halves are drawn misaligned and this effect changes with the zoom level, where the halves become more misaligned when zooming out.

[LucaDC (lucadc)]

Ah, and I just realized that while writing I was trying the above examples with round caps so that's not the main point.

[LucaDC (lucadc)]

Some 50 mm thick black stroke, red filled ellipses with bad rendering on XP (could make the same drawing with Windows 7 64 bit) r14865.

[su_v (suv-lp)]

@ScislaC - AFAIU this is mentioned/explained in Tav's blog already (including the different stroking methods implemented in various SVG renderers):

* Paths: Stroking and Offsetting
  http://tavmjong.free.fr/blog/?p=1257

(Scroll down to «There are two different ways to stroke a path.» and read on ...)

[su_v (suv-lp)]

ScislaC wrote:
> Chrome 52-dev renders it like Inkscape 0.91+ on Ubuntu.
> Firefox 46 renders it like 0.48 did.

JFTR: Firefox 0.46 on OS X renders it the same as all tested Chromium-based browsers, as Batik and as Inkscape 0.91+. There is also this bug report for Firefox on Ubuntu/Linux:
* 896248 – Rendering differences with Chrome/Opera when stroke-width is much larger than the element being stroked
  https://bugzilla.mozilla.org/show_bug.cgi?id=896248

[LucaDC (lucadc)]

The "Ellipses1 Firefox.png" shows what happens in Firefox 46.0.1 under Windows XP and Windows 7 64bit (the picture is taken under XP but I can see the exact same thing under Windows 7) when opening the "Ellipses1.svg" file.
The "Ellipses1 Inkscape.png" and "Ellipses1 Inkscape (outline).png" Next attached files show Inkscape in normal and outline view. The pictures are at a small zoom level because the visual results are worse in this way (here also, pictures taken under XP but same results under XP and 7).

There are two problems here: one is the legitimate choice of how to render the stroke (and my opinion is that it should be conservative, that is: paint whatever should be painted, no holes in overlaps) and the other is the evidently broken renderer that paints diamond holes or completely scrambled shapes where they should be curved.
We can probably discuss forever about the first (IMHO just looking at what others do is not entirely the correct way: we should have our own idea about what is better, then compare it with what others do and decide) while the second should just be fixed.

Besides, I can't understand how Firefox can paint straight borders in the two bottom ellipses: it seems that they make a simplification so a very thin ellipse becomes a straight line.
In any case it's always better than Inkscape's unintelligible result (maybe they did it so to avoid this situation?).

[Séverin Lemaignan (skadge)]

While I understand the difficulties of stroking a shape (thanks for the link to the great Tav's explanation), I certainly support the option of *not* leaving holes when drawing the stroke: as I initially reported in this bug, a circle that renders as a donut just drives the user mad: I've spent a fair amount of time trying to figure out why this simple shape would result in a donut, almost exploring all Inkscape's options/filters to see if I had mistakenly applied 'something' to my render (even though it was pretty clear from the XML code that I didn't).

And the 'average' user just think: oh, Inkscape has a bug.

This is made even worst by the fact it is a regression! Stroking was working 'as expected' (at least for this case) until recently...