Two bugs relating to line patterns

Bug #1029584 reported by David Mathog on 2012-07-26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
David Mathog

Bug Description

Here are two bugs relating to the handling of dash patterns on lines. This turned up on imports from EMF files but it is an unrelated Inkscape issue. The bug is present in a recent trunk and release 0.48.2. and on Windows and Linux.

In brief:

1. Some patterns are not recognized when the path is selected and the fill/stroke point/stroke style dialog is open. The solid
line pattern is shown, even when the pattern in the line corresponds to a standard one (here 3,1). It appears that this happens
for patterns less than 1 pixel in width, but I have not thoroughly explored the input space to be sure something else isn't
going on.

2. Some line patterns are converted to solid lines, without the user intending that, by doing:
   1. select line with pattern
   2. click on "stroke paint" in dialog
   3. click on "stroke style" in dialog

but not
   2'. click on "stroke style" in dialog
   3'. click on "stroke paint" in dialog

   1. set dialog to "stroke style" tab
   2. select line with pattern

No change is intended, but one is applied anyway. The really bizarre thing about this one is that it is a function of the width (see tables below). .3751 does this (as do many, many other widths), but it isn't a number of digits issue, as both .375 and .3750 act the same.

path color width miter ends
2884 red 0.375 8 round
2885 green 0.3751 8 round
2886 blue 0.3750 4 butt
2887 black 1 4 butt
2888 black 1 8 round

  A dash pattern recognized
  B select click stroke paint, click stroke style converts to solid

path A B
2884 N N
2885 N Y
2886 N N
2887 Y N
2888 Y N

Related branches

David Mathog (mathog) wrote :
David Mathog (mathog) wrote :

For the conversion problem it varies in some strange way as a function of width:
  These do not convert (dashes to solid): 0.5, 1.0, 2.0, 5.0
  These do: 0.51, 1.01, 2.01, 5.01

For dash pattern being recognized here are some observations, which don't make
a lot of sense to me. Perhaps the person who wrote that bit of code can explain what is going on?

width dash shows as (S)olid line or (D)ash pattern
1 3,1 D
1 3,2 S
0.5 3,2 S
0.5 3,1 D
0.5 1,3 D
0.5 2,3 S
2.0 1,3 S
1 1,3 D
5 1,3 S
5 6,7 S

su_v (suv-lp) wrote :

The colored paths in 'line_stroke_bugs.svg' are using a custom dash array which is not among the stock dasharrays as defined in the default preferences file (which are based on a 1px stroke width):

0.375 px stroke and dasharray:3,1
corresponds to
1.0 px stroke width and dasharray:8, 2.66666667

Dash arrays are using absolute units (Inkscape only supports default px user units currently). To keep them proportional relative to the stroke width, Inkscape recalculates them whenever the stroke width changes (can be easily verified via XML Editor: draw a new path (defaults to 1px width), apply stock dash style, and watch the dasharray update whenever the stroke width is changed).

Note: custom dasharrays are currently not supported in the GUI:
 Bug #170233 “A window for editing dash arrays”
 Bug #172164 “Custom dash patterns”
 Bug #512242 “Custom dashed lines impossible without the XML editor”

Workaround for this specific file: quit Inkscape, open the preferences file, add you custom dasharray to the group 'id="dashes"':

         style="stroke-dasharray:8,2.66666667" />

David Mathog (mathog) wrote :

Yes, I see what is going on. Most of this happens in SPDashSelector::set_dash().

The conversion to solid lines was happening because the way this routine works is it checks the dash pattern (where dashes
are the ratio of the actual dash length/width) against the standard patterns. If it doesn't match, it uses pos=0, which is a solid line. Editing the line widths from .5 to .51, for instance, was causing patterns to miss and it would then select the solid line.

I tried changing the code in there like

   pos = -1;

  // the code matching pattern or set pos to 0 if the number of dashes == 0

       this->set_data("pattern", dashes[pos]);

which eliminated the conversions to solid lines, but sometimes the unscaled dasharray would, by chance, match one
of the patterns, and it could convert to that. Will think about this some more...

David Mathog (mathog) wrote :

The attached patch creates a "custom" slot in the pull down dot/dash pattern list. Anything that has a pattern, but isn't one of the predefined patterns goes in there. Currently this is only going to work if the program finds preferences.xml and reads patterns from there. A little test file with some custom dash/dot patterns in it will be the next attachment.

Near as I can tell this works about as one would wish:

1. select a line with a custom dot/dash pattern - the other options (size, miter, ends, color) can still be used, but the pattern is retained.

2. It is possible to copy a custom pattern's style and paste style onto another line.

3. Custom dot/dash patterns can be entered with the XML editor or by reading in SVG (or, from an EMF, in my experimental code).

Needing a fix:

1. The font used for the "custom" text doesn't match the rest of the dialog. I still need to hunt down the font used there.

David Mathog (mathog) wrote :

On Windows the one extra slot ("custom") now makes the pull down list so long that the only way to reach it is to autohide
the toolbar. At least on my 1280 x 1024 desktop. Otherwise icons from the toolbar prevent it from being selected.

The pattern under "custom" will be whatever the last custom pattern selected was. So one could do:

select a line with a custom pattern
select a solid line
go to dialog, pull down to "custom"
solid line now has custom pattern.

But the shift-ctrl-V method is probably easier, if you remember the shortcut.

David Mathog (mathog) wrote :

Let me clarify, by "reach it" I meant "select the last entry on the list", which is "custom". The rest of the entries are as accessible as they ever were.

David Mathog (mathog) wrote :

Updated patch.

Changed font for the "custom" label from "Courier" to "Sans" and recentered the text.

Added code so that "custom" should work even if there are no dash patterns defined in preferences.xml. The new path is not fully tested, as deleting preferences.xml, and then running inkscape, resulted in a new preferences.xml being created before
this part of the code was called - so that it still used preferences. Maybe it will use the built-in dashes if preferences.xml is corrupted?

Kris (kris-degussem) on 2013-08-16
Changed in inkscape:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → David Mathog (mathog)
su_v (suv-lp) wrote :

Assuming fixed with the merge of Daivd's branch in r12488.

Changed in inkscape:
milestone: none → 0.49
status: In Progress → Fix Committed
Bryce Harrington (bryce) on 2015-02-21
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers