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

[Juhász P. <pet...@gm...>]

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.

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.

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

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


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.

Or should the pattern be specified with strings like "--...",
interpreted in a do-what-I-mean sense?

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

(I prefer the string version, with the addition that "solid" should be
an allowed keyword because it's a common, trivial case.)

Peter Juhasz