single lines may have fill set

[David Mathog]

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?

[jazzynico (jazzynico)]

> 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.

[David Mathog (mathog)]

OK, it must allow it. Does not mean it should encourage it. The palette shortcuts listed here:

http://inkscape.org/doc/keys045.html

are

click set fill color on selection
Shift+click set stroke color on selection
mouse drag drag fill color to objects
Shift+mouse drag drag stroke color to objects

ctrl-click is NOT listed. Yet when it is typo'd in by accident, it acts like a plain click.

Should it not be rejected/ignored?

Ditto for alt-click, shift-alt-click, and so forth, all of which currently fill the selected object with the color clicked on.

[nightrow (jb-benoit)]

As the behavior reported must be allowed, can we close this as invalid ?

[David Mathog (mathog)]

No. The dropper tool performs undocumented and undesired actions. Specifically, with a line selected and the cursor over a color:

ctrl-click
alt-click
(and probably others)

set the fill value. They should do nothing.

The behavior of shift-alt-click appears to have changed, 4 months ago it set fill, now it sets stroke. Neither is documented
here: http://inkscape.org/doc/keys045.html.

The initial complaint (setting fill on a zero width line) must be allowed, but the GUI should not encourage users to do so accidentally with a typo.

[su_v (suv-lp)]

<off-topic>
On 11/12/2012 18:05, David Mathog wrote:
> The behavior of shift-alt-click appears to have changed, 4 months
> ago it set fill, now it sets stroke. Neither is documented
> here: http://inkscape.org/doc/keys045.html.

The keys and mouse references files are versioned (see file name): it makes no sense (at least to me) to compare a documentation written for an old release (0.45) from 2007-02-04 with current trunk, which has not been released yet, nor branched in preparation for the next release (0.49). It makes also no sense (at least to me) to expect an all-time up-to-date documentation for the development version (aka trunk).
<off-topic>

[su_v (suv-lp)]

> 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.

This "1D object" (a regular <path> if created with Inkscape's tools) can be edited and gain a second dimension anytime…

Instead of adding workarounds and constraints in various places, here's another thought to consider:
The SVG 1.1 specification defines several types of "lines": <line>, <polyline>, <polygon> and <path> [1]. Inkscape supports all for rendering, but only edits and writes <path>.

For 'path' elements, it makes no sense to restrict the styling properties (no fill allowed under certain circumstances, which might change anytime the object is edited). The actual request seems to be to add (optional) full support for all basic SVG shapes [2] to Inkscape (currently, this is limited to <rect>), including any constrains as defined in the SVG spec (e.g. for <line> to have no fill [2]).
Using 'path' elements though is more versatile (e.g. because it supports SVG features like 'text-on-path', which shape elements do not), which is AFAIK the main reason why even the parameterized Inkscape shapes like circle/ellipse and star/polygon are defined as SVG <path> types in the SVG source.

---
[1] <http://www.w3.org/TR/SVG11/shapes.html>
[2] e.g. Bug #170934, Bug #377982
[3] «9.5 The ‘line’ element

The ‘line’ element defines a line segment that starts at one point and ends at another.
(…)
Because ‘line’ elements are single lines and thus are geometrically one-dimensional, they have no interior; thus, ‘line’ elements are never filled (see the ‘fill’ property).»
<http://www.w3.org/TR/SVG11/shapes.html#LineElement>

[David Mathog (mathog)]

Re comment 6 - there is no other documentation available, that's what comes up with trunk for Help Keys and Mouse reference.

I think the GUI should, at present, ignore ctrl-click and alt-click, rather than remapping them silently to "click".
At least until such time they are actually assigned intended meanings. Letting undefined key/mouse combinations default to who knows what actions is a bad idea. Defined (and documented) should do what is intended, all others should be ignored. Or to flip it over, if one accidentally uses an undefined key combination and it changes the drawing, there is simply no way to determine from the documentation what it is that you might have done. (Which is how I discovered the filled straight line problem in the first place - making one like that was never intended.)

[su_v (suv-lp)]

<off-topic cont.>
> Re comment 6 - there is no other documentation available, that's what comes
> up with trunk for Help Keys and Mouse reference.

Current trunk opens the keys and mouse reference from current stable Inkscape 0.48, which is at least closer with regard to feature set to trunk than Inkscape 0.45 (released 2007):
<http://inkscape.org/doc/keys048.html>
</off-topic>