dashed lines with arrow heads have red line after save as to PDF

[David Mathog]

Create an SVG with dashed lines and arrowheads. (I did not test if this happens for lines without arrowheads).
Save as to PDF.
Open the PDF with any viewer.

There is a fine red line running down the middle of the dashed lines. It does not seem to matter which dash line pattern is used. Dashed path around a circle does not have this issue.

Inkscape 0.48.2 r9819 on Windows XP

[David Mathog (mathog)]

Note, PDF was generated with:

version 1.5 selected
no boxed checked
90 dpi for rasterization (but there should not be any in the example)

[David Mathog (mathog)]

After some more experimenting, I see the problem. In all of these examples fill was set to 255,0,0. That wasn't visible in the SVG rendering but it is visible in the PDF. I only noticed it after adding more points to the line and moving them around, whereupon the fill showed up. The arrow heads do not matter.

In any case, in Inkscape"fill" is not visible on straight lines, either dashed or solid. After save as to PDF the resulting red line segment (in the PDF) lies under any dashes, and presumably, under the solid line if there are no dashes.

[su_v (suv-lp)]

Linking as duplicate to
Bug #389451 in Inkscape: “undefined filling color leads to grey Export.”

This is not a bug of Inkscape itself: whether a small center line of straight dashed paths with fill color 'Unset' (instead of 'None') is displayed as hairline or not depends on the PDF viewer used to view the file. Your file for example looks fine in Apple's Preview.app and Evince 2.30.3, but displays the hairline in Xpdf @3.02pl5 and gv (Ghostscript 9.04).

As tested and confirmed in bug #389451 a PDF file converted with the command line utility 'rsvg-convert' (based on librsvg) exposes the same differences among PDF viewers.

[su_v (suv-lp)]

The minor difference in your attached SVG file is that the straight dashed paths do not have 'Unset' as fill, but each use a solid fill color. The effect is the same (an 'unset' fill is per SVG specification rendered as solid black fill).

If you would add a third, vertically offset node to the dashed paths, or curve the line segment, the paths would have a solid filled area unless you remove the fill (set it to 'None'). Some PDF viewers apparently render the edges of the (collapsed) filled area of straight lines visibly different from the background.

[su_v (suv-lp)]

Sorry - I didn't reload the page while writing my comments, and only saw your revised interpretation of your report after having added the second comment.

[David Mathog (mathog)]

I went back to examine why those lines had fill set, as it did not make sense that they do. On reviewing my notes the way those lines were constructed was:

1. draw a rectangle
2. convert to path
3. edit points
4. select two, break path
5. delete those two points

I know, it is an odd way to make a line, but that is how it was done. Doing that left the remaining line with a set fill value. I'm not sure that it makes sense for Inkscape to leave fill "set" when a path is reduced to two points connected by a straight line, or an entire path falls on a straight line - doing so serves no purpose (as far as I can tell) but it does open the door for these sorts of glitches.

 I can see where this might also be an issue when converting the dashed boundary of a rectangle to separate line segments.
Trying it...

1. draw a filled rectangle
2. set border to dashes
3. extensions -> modify path -> convert to dashes

Yup, the fill is set on all of the segments created. It can be seen in a couple of the corners where the line sements wrapped around and there is some area to fill. Interestingly the fill is lost on the original rectangle, which was and still is bounded by the path. After "break apart" it looks the same, and that is the point at which I would have expected to lose the fill corresponding to the original object.

[su_v (suv-lp)]

> I'm not sure that it makes sense for Inkscape to leave fill "set"
> when a path is reduced to two points connected by a straight line

Yes, it makes sense that Inkscape does not act as if it knew better than the user: can it anticipate my intentions in any way? Maybe I want to bend that line to create a filled bulge, or insert a new corner to create a filled triangle, etc.

IMHO it is up to the user to control whether a path (be it a single straight line, a curve, or a complex intertwined one) has a fill color, has it 'Unset' or explicitly set to 'None'.

[David Mathog (mathog)]

suv wrote in #8: can it anticipate my intentions in any way?

Yes, in certain specific instances. If the user has created a straight line in Inkscape for which the current fill attribute does not result in a visible change in the drawing within Inkscape, then the application can anticipate that the user has no intention of having that fill attribute affect the view in any other exported format. I agree that the program cannot anticipate what the user might do next within inkscape, but that isn't the point at which these things become a problem, that happens when they are exported to other formats.

This seems to be a recurring issue with inkscape, where a "hidden" property, here defined as some property being set which is invisible in the inkscape drawing, is exported in such a way that it becomes visible in another format. Other instances I have run into are zero width bounding lines (indistinguishable in the Inkscape display from no bounding line, but drawn as minimum width lines in many other programs) and the dashed attribute remaining set on dashed lines which have been converted to dashes (there is already a patch for this last one). What these have in common is that the user cannot tell by looking at the drawing that the problem exists. The only way to find these issues is to examine the fill and stroke parameters for objects one by one. Perhaps there is a way to make "find..." select all objects with dashes set, for instance, but so far I have not figured out how to do so.

[su_v (suv-lp)]

This discussion has moved off-topic and outside the scope of the particular issue reported here. As I had shown in bug #389451 (which this one is a duplicate of), there is nothing wrong in the PDF file:
1) Only _some_ PDF viewers apparently render the edges of the filled area with zero width as visible hairline, possibly due to antialiasing algorithms used.
2) Such an effect in those PDF viewers is _not_ limited to PDF files generated by Inkscape
3) Nor is it limited to having created the original SVG files with Inkscape.

<off-topic>
> Perhaps there is a way to make "find..." select all objects with dashes set
> (…) but so far I have not figured out how to do so.

You might have some success using 'Edit > Find…' where one can search for partial strings of the style attribute (e.g. "stroke-dasharray:"), but the problem is that the property can be either set to 'none' or not exist at all for paths with solid strokes i.e. a simple search testing for its existence does not necessarily return only paths with dashed strokes. Searching for a certain type of dashes however works fine (e.g. "stroke-dasharray:5, 2.5" or "stroke-dasharray:20, 10, 5, 10").
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Select.html#Select-Find>

There are already feature requests filed about either redesigning the 'Find…' dialog, or providing more sophisticated (or predefined) search and selection capabilities based on attributes/properties - this is beyond the scope of the reported issue here.

There are also filed requests to remove superfluous, redundant or default properties (like "stroke-dasharray:none;") though there are many situations where the attribute is intentionally left in place to guarantee the same appearance in case a parent container element sets a different value for the same property (style inheritance is an basic aspect of SVG). Recently work from one of this years' GSoC projects was checked into trunk which will allow to have more control over Inkscape's SVG output in future releases:
<http://article.gmane.org/gmane.comp.graphics.inkscape.devel/37649>
</off-topic>

Further discussion and questions about usage should be moved elsewhere IMHO (forum, mailing list, etc).