Two bugs relating to line patterns

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

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"':

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

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

    if(pos>=0){
       this->set_data("pattern", dashes[pos]);
       this->dash_combo.set_active(pos);
       this->offset->set_value(o);
    }

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

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.

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.

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.

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?

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