Menu
▾
▴
gnuplot-beta
|
From: Juhász P. <pet...@gm...> - 2014-03-09 22:49:18
|
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
|
|
From: sfeam <sf...@us...> - 2014-03-10 00:32:21
|
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
|
|
From: Tait <gnu...@t4...> - 2014-03-11 08:27:37
|
sfeam said (on 2014/03/10): > On Sunday, 09 March 2014 11:49:09 PM Juhász Péter wrote: > > ... > > So there would be a new line property "dashtype" or "dt", allowed > > everywhere a line specification is accepted. > > ... > > 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 ... > > > Sort of. I think I would typically define all the linetypes to default > to solid, which I suppose is dt 0. > > > Here we hit a snag: what do the numeric dashtypes exactly mean? > > ... > > 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" ... Do you mean synonym for "dt 0"? Keywords like "dashed" and "dot-dash" seem too limiting if we want to support user-defined dash types. But predefined dash types are much easier to implement. For the user-specified "set dashtype", the user-given pattern is implicitly assumed to loop around itself? set dashtype 1 "--- " would end up drawing "--- --- --- --- " etc.? I assume that each character space in the dashtype string maps to a minimal-length chunk of line? So '-' is a bit of solid line, and ' ' is presumably nothing drawn, and '=' would be a double-line. I'm not sure what '.' is expected to produce? A dot, but raised to centerline, like '·'? I thought about inserting other glyphs, e.g. '»'. Or normal letters, e.g. set dashtype 2 "----- A --" set dashtype 3 "--- B ----" But then one has to deal with fonts, sizes, weights, rotation, offset, etc. Maybe it is better to accomplish that sort of idea with just "set dashtype 2 "----- --" and then follow with a second line "with labels" to fill in the glyphs. But now the user has to try and synchronize the "set samples" and/or "every" so that the letters all fall into the gaps in the dashes. What do linewidth and pointsize mean to a dotted/dashed line? Does a line with dashtype '···········' ignore pointsize and increasing linewidth just adds to the vertical height of each dot (thus in the extreme making it look more like '|||||||||||')? Or will linewidth implicitly also increase the horizontal spacing so '·' -> '•' -> '●' ... etc. continues to retain its aspect ratio as it grows larger? |
|
From: sfeam <sf...@us...> - 2014-03-11 14:56:25
|
On Tuesday, 11 March 2014 08:27:29 AM Tait wrote: > sfeam said (on 2014/03/10): > > On Sunday, 09 March 2014 11:49:09 PM Juhász Péter wrote: > > > ... > > > So there would be a new line property "dashtype" or "dt", allowed > > > everywhere a line specification is accepted. > > > ... > > > 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 ... > > > > > Sort of. I think I would typically define all the linetypes to default > > to solid, which I suppose is dt 0. > > > > > Here we hit a snag: what do the numeric dashtypes exactly mean? > > > ... > > > 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" ... > > Do you mean synonym for "dt 0"? Whichever. Currently "linetype 0" is the dotted one. It would be kind of weird if the first and possibly only line in a plot is anything other than solid, but the sequence starts at lt=1. > I assume that each character space in the dashtype string maps to a > minimal-length chunk of line? So '-' is a bit of solid line, and ' ' is > presumably nothing drawn, and '=' would be a double-line. I'm not sure > what '.' is expected to produce? A dot, but raised to centerline, like > '·'? > > I thought about inserting other glyphs, e.g. '»'. Or normal letters, > e.g. > set dashtype 2 "----- A --" > set dashtype 3 "--- B ----" This is already possible in version 4.6 using a combination of "pointinterval" and "with labels". This doesn't involve dashtype that I can see, although one could imagine providing a shortcut that accomplishes the same result with a single command rather than two separate commands. > But then one has to deal with fonts, sizes, weights, rotation, offset, > etc. Maybe it is better to accomplish that sort of idea with just "set > dashtype 2 "----- --" and then follow with a second line "with labels" > to fill in the glyphs. But now the user has to try and synchronize the > "set samples" and/or "every" so that the letters all fall into the gaps > in the dashes. That is what the existing "pointinterval" property is for. > What do linewidth and pointsize mean to a dotted/dashed line? Does a > line with dashtype '···········' ignore pointsize and increasing > linewidth just adds to the vertical height of each dot (thus in the > extreme making it look more like '|||||||||||')? Or will linewidth > implicitly also increase the horizontal spacing so '·' -> '•' -> '●' ... > etc. continues to retain its aspect ratio as it grows larger? Currently there is a "dashlength" property that is independent of both "linewidth" and "pointsize". However right now this is a terminal setting rather than a property of the current line or plot. We might want to rethink that. Ethan |
