Re: RFC: dashtype, aka separate control of line property descibing the dot-dash pattern

[sfeam <sf...@us...>]

On Sunday, 09 March 2014 11:49:09 PM Juhász Péter wrote:
> There was discussion about this (separating the control of line pattern
> from the linetype property) in conjunction with the upcoming major
> release. I thought a bit on it and I'd like to know if I'm on the right
> track.
> 
> So there would be a new line property "dashtype" or "dt", allowed
> everywhere a line specification is accepted.
> 
> E.g.
> 
>    set linetype 1 dashtype 2 linewidth 3
>    set linestyle 2 dashtype 4 linecolor rgb "red"
>    plot x with lines dashtype 5
> 
> This new property would of course be reported by show {linestyle|
> linetypes}, save etc., however, the output of these show commands would
> be a bit different. Currently, they are like this:
> 
>    show linetypes
> 
> 	Linetypes repeat every 0 unless explicitly defined
> 	linetype 1,  linetype 1 linecolor linewidth 3.000 pointtype 1 pointsize
> default pointinterval 0
> 
>    show linestyle
> 
> 	linestyle 2,  linetype 2 linecolor rgb "red"  linewidth 1.000 pointtype
> 2 pointsize default pointinterval 0
> 
> 
> Especially in the first case the multiple references to "linetype" is
> confusing. So with the new dashtype property introduced it would replace
> "linetype" in these reports.

Yes. This is exactly the way I see it also.

> Now for the meaning and semantics of the new property:
> Unless otherwise specified, the numeric dashtype would increase
> monotonically in subsequent plots in a single plot command, just as
> linecolor and pointtype do.

That is misleading.
The only thing that increases monotonically is the linetype.
Each linetype has a set of associated properties, so progressing from
lt 1 to lt 2  has the effect of progressing from the point type associated
with lt 1 to the point type associates with lt 2.  These are typically
different, but there is no requirement that they be different.  
It is perfectly reasonable to want all my linetypes to use pt 7
(solid circle) and be differentiated from each other only by color.

That might be what you were saying anyhow, but I thought I'd try 
stating it more clearly.

> So e.g. "plot for [i=0:10] i*x" would do exactly the same as before.
> But "plot for [i=0:10] i*x" dashtype 1 would keep the line pattern the
> same for all plotted lines while still cycling the color (as opposed to
> the current state of affairs, where "lt 1" fixes the color as well).

Sort of.  I think I would typically define all the linetypes to default
to solid, which I suppose is dt 0.   So either of those commands would
produce only solid lines.  If I wanted to increment over dash patterns
and not color (typically for monochrome plots) I would substitute a
new set of default linetypes
   set linetype 1 dt 1 lc rgb "black"
   set linetype 2 dt 2 lc rgb "black"
   set linetype 3 dt 3 lc rgb "black"
This is more or less what the existing file .../share/colors_mono.gp
does, except that it uses "dt" rather than "lt" in the definitions.

> Here we hit a snag: what do the numeric dashtypes exactly mean?
> The answer is that it depends on the terminal.
> I haven't looked at all of them but each one supports a different set of
> line patterns in a different order (if they support dashes at all).
> 
> This should be made consistent, which seems to be a large amount of work
> because the specific patterns are usually hardcoded deep into the
> terminal code (e.g. in the postscript terminal they are implemented in
> native postscript).

That is what I envision the state being for 5.0.rc1
We have defined a new syntax that distinguishes lt from dt,
but have not yet changed the set of dash patterns that are
actually available.

I then see two ways forward from there.  Well three.

1) Leave it at that.  Each terminal is different, hopefully in a way
   that makes sense for that terminal.  No worse than we have now.

2) Work through all the terminals to standardize the first N dash
   patterns.  I don't really know what N would be, 4? 8?

3) Leave the underlying terminal-specific sequence alone, but implement
   a new set of commands
     set dashtype N {n1, n2, n3, ...}  # like svg.trm SVG_dashpattern[][]
     set dashtype N "xxxx..."          # where x is ' ' or '.' or '-'
   The second one is a user-friendly version of the first, where
   the program converts internally to the first form.
   This is what I would prefer long-term.

Option 3 treats the dash patterns analogously to the v4.6 treatment of
linetypes.  The original ones are still there underneath because for at
least some terminals they are intrinsic to the terminal.  But the
"linetype" you see as a user is a defined construct that can be 
customized as you like for colors, points, etc.

> One final question: what about user-specified patterns? Are they needed
> at all? If yes, what would be the preferred syntax?
> Should there be a separate "set dashtype" command where the user could
> set explicit dash and space lengths? This would offer the most
> flexibility, but it would be hard to implement it across all terminals.

See above.  I think we are in agreement.

> Or should there be separate keywords, like "solid", "dashed", "dot-dash"
> etc?

I don't like that in the general case, but I suppose it might be
useful to accept "solid" as a synonym for "dt 1"  just as we currently
accept "bgnd" as a synonym for "lc whatever-the-background-got-set-to".
 
> (I prefer the string version, with the addition that "solid" should be
> an allowed keyword because it's a common, trivial case.)

We are clearly on the same page :-)

> Peter Juhasz