single lines may have fill set
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
New
|
Undecided
|
Unassigned |
Bug Description
Current versions of inkscape allow a single line to be "filled", and such lines are not obviously visually different from another line.
Setting a line like this is easy enough to do with a slip of a finger, when trying to change the color of a line, by clicking on the color bar instead of shift clicking on it. (ctrl-click fills, and that is just a misplaced pinky one key away typo away from shift-click.) In the attached SVG the red line has "fill" set, whereas the blue one does not.
While Inkscape itself seems to be oblivious to this impossible fill, other programs are not. It causes problems on export to other file formats, because in one case "stroke_and_fill" is set, whereas in the other it is not. For instance, in EMF import the fill attribute causes an automatic "z" to be appended to the path to close it, and that results in an incorrect line when that EMF is reimported. Similar problems have been seen on PPT import.
Does it ever make sense for "fill" to be set on a 1D object? I don't think so, and the code should probably not allow it.
Also, in simpler terms, to work around the typo aspect, perhaps ctrl-shift should be mapped into either an error popping up,
or mapped to do the same thing as shift click.
Related bug 905032, where the filled line was obtained by editing a rectangle down to a line. Note that in current versions of inkscape lines produced by editing down a rectangle, when viewed with the node editor on, have handles attached to the end points, whereas those handles are not visible on a line erroneously set to fill. Perhaps they have zero length and are over the end points?
> Does it ever make sense for "fill" to be set on a 1D object? I don't think so, and the code should probably not allow it.
Since the SVG specs allow it, Inkscape must allow it too. There's nothing wrong or invalid with the SVG file, and it renders correctly with Inkscape, Firefox and Batik. I'd say it's up to the export code to handle that as needed.