Stroke to Path on thin strokes results in random segment widths

[Jean-Paul Larocque]

Hi.

On open paths which have strokes of a fraction of a pixel, but no fill, Stroke to Path renders erratic filled paths. (I'm being specific because I haven't tried other situations, like closed paths.) The thickness of each rendered segment seems to be off by small random amounts each time. You can even duplicate the same path several times, run Stroke to Path on a multiple selection of all the paths, and each one will be rendered uniquely.

A sample SVG with before and after paths is attached. To reproduce, select the original stroke, then run Stroke to Path. (The SVG won't be legible in a browser without zooming in. The width of the image is only a few pixels.)

I'm experiencing this problem with Inkscape 0.48.1 r9760 on Ubuntu 11.04 amd64 (package version 0.48.1-2ubuntu2) and Inkscape 0.47 r22583 on Debian 6.0.2 amd64 (package version 0.47.0-2+b1).

[Jean-Paul Larocque (jplarocque)]

Adding PNG attachment for viewing convenience

[su_v (suv-lp)]

Reproduced with Inkscape 0.48.4 and current trunk r12000 on OS X 10.7.4.

Related:
Bug #1094802 “bounding box too large for 0.001 to 0.04 mm stroke width”
<https://bugs.launchpad.net/inkscape/+bug/1094802>

[Alvin Penner (apenner)]

three separate problems were encountered at narrow linewidths. Two of them have been fixed, the third cannot be fixed within the scope of the current algorithm.

1. there was a lower limit of 0.1px on the allowable stroke width to be used when converting a stroke to an outline path. This has been reduced from 0.1 to 0.01, similar to what was done in Bug 1094802.

2. the algorithm that is used to convert a stroke to an outline path is a multi-stage method. The first stage draws an outline path that contains some redundant nodes and perhaps some unwanted crossings of paths. The second stage converts this path to a Shape object by putting the outline nodes on a grid which has a spacing of 1/32 px. = 0.03125 px. Then the redundant nodes are eliminated. The grid can be seen by inspecting the resulting outline path in the XML editor, where all the points will be in steps of 0.03125. (The three stages of production can be seen in the file 'crossover.svg' at http://article.gmane.org/gmane.comp.graphics.inkscape.devel/38180).
    While doing the quantization of the path coordinates, it is possible that two points that were originally very close together may get separated by 0.03125 by chance. This is the origin of the horizontal glitches, and also some vertical glitches, in the figure 'stroke_to_path_bug.png'. These glitches have been removed by removing the redundant points in the original outline path.

3. the resulting outline shape should now be smooth, but at small stroke widths it will still be noticeable that the outline path width is not always constant because there is always an ambiguity of about .03125 in the width. This cannot be fixed within the scope of the algorithm that is being used to produce the final shape.

committed to rev 12069.

I would propose that the bug report be changed to either "Fix Committed" or "Will Not Fix", not sure which is better.

[su_v (suv-lp)]

One side-effect of r12069 appears to be that (axis-aligned) straight lines with a stroke width <= 0.03125px are not outlined as filled paths anymore - they tend to remain a line (probably after the 'redundant' nodes are removed?) - and the converted paths are not visibly rendered on-canvas anymore (because 'Stroke to Path' removes the stroke and adds instead a fill color). This observation relates to bug #1094802, and the test file from comment #4 there. The overall precision for bug #1094802 has again improved with r12069, but for really small path widths, the user might now have trouble finding the outlined paths (no visual indication in normal view mode).

[Alvin Penner (apenner)]

yes, rather than use a lower limit of 0.01 px on the stroke width (which was a rather arbitrary value, chosen for no particular reason) it might be better to use a lower limit of 0.03125 px. I'll investigate that to see if it helps.

[Alvin Penner (apenner)]

in order to prevent horizontal and vertical lines from collapsing to zero width, the minimum stroke width used in the outline has been changed from 0.01 to 0.032. It was necessary to use a number that was slightly larger than 0.03125 in order to guarantee that the outlined width would never be zero.

committed to rev 12072

[su_v (suv-lp)]

@Alvin - could you please take a look at the attached file, and check the size of the group on the current layer? AFAICT the path with id "path 6556" (inside a nested group structure) is what triggers a huge (visual) bounding box in r12069 and later revisions, but not with older ones (<= 12068)...

[Alvin Penner (apenner)]

yes, I see there is something very unusual here. Unfortunately it happened only once and now I cannot reproduce it.
- running XP, recent build, I loaded the file. Clicked on the main image. Noted that the Visual bbox was correct. (Visual bbox is the chosen default in Preferences). However, the Y coordinate reported in the bottom right display was extremely large, at least 6 figures or so. Also the entire menu system was hung. Could not click on Edit to bring down a menu display. I believe everything was hung.
- running Windows 7 and Inkscape 0.48.4, everything behaves correctly.
- going back to XP and recent build and everything behaves normally, I cannot reproduce the problem. I clicked on the path6556 in the XML editor to highlight it and encountered no problem

- will investigate some more on the weekend.

[Alvin Penner (apenner)]

the problem was caused by a division by zero (head slap)

fix committed to rev 12084

[Alvin Penner (apenner)]

with respect to the following comment, in comment 4 above:

>> 3. the resulting outline shape should now be smooth, but at small stroke widths it will still be noticeable that the outline path >> width is not always constant because there is always an ambiguity of about .03125 in the width. This cannot be fixed within
>> the scope of the algorithm that is being used to produce the final shape.

the situation has changed in rev 12399. The quantization of the coordinates into increments of 1/32 px has been removed, with the result that the path widths should now be more consistently uniform, assuming they were originally uniform.

[su_v (suv-lp)]

Test case repeated with latest trunk (r12980) is ok.