Menu
▾
▴
gnuplot-beta
|
From: Allin C. <cot...@wf...> - 2008-10-20 23:07:17
|
Five days ago I wrote: "With most terminal types, if you specify a color plot then it seems that by default solid lines are used, not dash patterns, for line graphs. However, the postscript terminal behaves differently: it uses dash patterns by default even when color mode is selected." "I think it would be preferable if the post terminal behaved in the same way as the others." Are there good reasons for not doing this? If not, would my idea get more attention if I were to submit a patch? Thanks. -- Allin Cottrell Department of Economics Wake Forest University |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-10-20 23:43:29
|
On Monday 20 October 2008 16:07:11 Allin Cottrell wrote: > Five days ago I wrote: > > "With most terminal types, if you specify a color plot then it > seems that by default solid lines are used, not dash patterns, for > line graphs. However, the postscript terminal behaves > differently: it uses dash patterns by default even when color mode > is selected." > > "I think it would be preferable if the post terminal behaved in > the same way as the others." > > Are there good reasons for not doing this? I know of only one, but it's a core element of the development policy: being consistent with the way it has worked for the last 20 years. > If not, would my idea get more attention if I were to submit a patch? I see two ways to move forward; there may be others: 1) Formulate a more general model in which you can specify dash-pattern as an independent property at all times. Most of the code necessary to support this is already in place (see http://gnuplot.sourceforge.net/demo_4.3/dashcolor.htm ) but it is not exposed to the user in a friendly fashion. 2) Allow the user to customize the default order of line properties across all terminals. I have posted a series of patches to implement this, patchset #2004590, but haven't received much feedback. If you invoke your preferred line style definitions in ~/.gnuplot, then the "set terminal" options for solid/dash are irrelevant. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Allin C. <cot...@wf...> - 2008-10-21 14:35:57
|
On Mon, 20 Oct 2008, Ethan Merritt wrote: > On Monday 20 October 2008 16:07:11 Allin Cottrell wrote: > > "With most terminal types, if you specify a color plot then it > > seems that by default solid lines are used, not dash patterns, for > > line graphs. However, the postscript terminal behaves > > differently: it uses dash patterns by default even when color mode > > is selected." > > > > "I think it would be preferable if the post terminal behaved in > > the same way as the others." > > > > Are there good reasons for not doing this? > > I know of only one, but it's a core element of the development policy: > being consistent with the way it has worked for the last 20 years. That's fair enough. > I see two ways to move forward; there may be others: > > 1) Formulate a more general model in which you can specify dash-pattern > as an independent property at all times. Most of the code necessary to > support this is already in place > (see http://gnuplot.sourceforge.net/demo_4.3/dashcolor.htm ) > but it is not exposed to the user in a friendly fashion. That looks interesting. But am I right in thinking that the dash-pattern spec doesn't work for x11, png, pngcairo and pdfcairo? (It does for postscript.) > 2) Allow the user to customize the default order of line > properties across all terminals. I have posted a series of > patches to implement this, patchset #2004590, but haven't > received much feedback. If you invoke your preferred line style > definitions in ~/.gnuplot, then the "set terminal" options for > solid/dash are irrelevant. Thanks, I'll take a look at that. Allin Cottrell |
|
From: Ethan A M. <merritt@u.washington.edu> - 2008-10-21 15:35:18
|
On Tuesday 21 October 2008, Allin Cottrell wrote: > But am I right in thinking that the > dash-pattern spec doesn't work for x11, png, pngcairo and > pdfcairo? (It does for postscript.) This is not correct. All the cairo-based terminals support dashed lines. In fact, most of the reasonably modern terminals do. x11 has the most flexible support for dot/dash patterns of any of the current terminals, since you can redefine it dynamically using the X Resources gnuplot*line1Dashes and so on. However, dotted/dashed lines on x11 look horrible, so it's a moot point. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Allin C. <cot...@wf...> - 2008-10-21 16:46:09
|
On Tue, 21 Oct 2008, Ethan A Merritt wrote: > On Tuesday 21 October 2008, Allin Cottrell wrote: > > But am I right in thinking that the > > dash-pattern spec doesn't work for x11, png, pngcairo and > > pdfcairo? (It does for postscript.) > > This is not correct. > > All the cairo-based terminals support dashed lines. > In fact, most of the reasonably modern terminals do. Ah, duh! With the top-level "dashed" option. I see. Allin Cottrell |
|
From: Allin C. <cot...@wf...> - 2008-10-23 19:30:23
|
On Mon, 20 Oct 2008, Ethan Merritt wrote: > I see two ways to move forward; there may be others: > > 1) Formulate a more general model in which you can specify dash-pattern > as an independent property at all times. Most of the code necessary to > support this is already in place > (see http://gnuplot.sourceforge.net/demo_4.3/dashcolor.htm ) > but it is not exposed to the user in a friendly fashion. It seems to me that a nice solution would be if "set style line" were extended to include a "dashtype/dt" option, in the same way that pointtype can be selected independently of other features of the line. To be a bit more explicit, the idea is that you wouldn't need to set a top-level "dashed" option, but could choose from a common enumeration of types such as 0 = solid 1 = regular dashes 2 = dots 3 = short dashes 4 = dash-dot ... (or some such), with the understanding that not all terminals would necessarily support all options. Allin Cottrell |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-10-23 23:04:14
|
On Thursday 23 October 2008 12:30:21 Allin Cottrell wrote: > On Mon, 20 Oct 2008, Ethan Merritt wrote: > > > I see two ways to move forward; there may be others: > > > > 1) Formulate a more general model in which you can specify dash-pattern > > as an independent property at all times. Most of the code necessary to > > support this is already in place > > (see http://gnuplot.sourceforge.net/demo_4.3/dashcolor.htm ) > > but it is not exposed to the user in a friendly fashion. > > It seems to me that a nice solution would be if "set style line" > were extended to include a "dashtype/dt" option, in the same way > that pointtype can be selected independently of other features of > the line. Isn't that what it does now? Each line type has an explicit dash pattern, selected by saying "lt N", analogous to selecting point type by saying "pt N". > To be a bit more explicit, the idea is that you > wouldn't need to set a top-level "dashed" option, but could choose > from a common enumeration of types such as > > 0 = solid > 1 = regular dashes > 2 = dots > 3 = short dashes > 4 = dash-dot ... > > (or some such), with the understanding that not all terminals > would necessarily support all options. Is there a difference between this and simply deciding to set all terminals to dashed mode by default? What you are describing is, so far as I understand it, the way it already works. This is exactly what is shown by the demo I pointed to. The limitation that I see in the current setup is that you pretty much have to set up all these line styles in advance; you can't easily just toggle dashed mode on for one line out of 20. It is possible, but only by explicitly by setting the characteristics of the other 19 lines to "lt 1 lc N". -- Ethan A Merritt |
|
From: Allin C. <cot...@wf...> - 2008-10-23 23:31:07
|
On Thu, 23 Oct 2008, Ethan Merritt wrote: > On Thursday 23 October 2008 12:30:21 Allin Cottrell wrote: > > It seems to me that a nice solution would be if "set style line" > > were extended to include a "dashtype/dt" option, in the same way > > that pointtype can be selected independently of other features of > > the line. > > Isn't that what it does now? > Each line type has an explicit dash pattern, selected by saying "lt N", > analogous to selecting point type by saying "pt N". Yes, but this depends on the terminal type, making it more or less impossible to produce a "portable" gnuplot command file which will produce similar effects (modulo inevitable differences in capabilities) across the various terminals. I'm particularly interested in eps, pdf(cairo), png(cairo) and emf (on behalf of Windows users). To get any dashes you have to set the "dashed" option for these terminals (except for postscript, which as I noted is exceptional in doing dashes by default). But the "linetype" numbers in dashed mode produce different effects as noted below: In postscript, dashed mode: solid lines: 1, 10, 19, 28 regular dash: 2, 11, 20, 29 short dash: 3, 12, 21, 30 in pngcairo, pdfcairo, dashed mode: solid lines: 1, 6, 11, 16, 21 regular dash: 2, 7, 12, 17, 22 short dash: 3, 8, 13, 18 in emf, dashed mode: solid lines: 1 to 15 regular dash: 16 to 30 short dash: 31 to 33 This is a total nightmare with regard to portability. Allin Cottrell |
|
From: Ethan M. <merritt@u.washington.edu> - 2008-10-23 23:52:00
|
On Thursday 23 October 2008 16:31:01 Allin Cottrell wrote: > On Thu, 23 Oct 2008, Ethan Merritt wrote: > > > On Thursday 23 October 2008 12:30:21 Allin Cottrell wrote: > > > It seems to me that a nice solution would be if "set style line" > > > were extended to include a "dashtype/dt" option, in the same way > > > that pointtype can be selected independently of other features of > > > the line. > > > > Isn't that what it does now? > > Each line type has an explicit dash pattern, selected by saying "lt N", > > analogous to selecting point type by saying "pt N". > > Yes, but this depends on the terminal type, making it more or less > impossible to produce a "portable" gnuplot command file which will > produce similar effects (modulo inevitable differences in > capabilities) across the various terminals. Ah, I misunderstood. That's an entirely different issue. We made a concerted effort for 4.2 to bring the sequence of point types into conformity across terminals. So far as I recall, no one argued for doing the same to dash patterns. I have no objections to someone offering a series of patches that re-orders the sequence of dash patterns to achieve some level of cross-terminal agreement. I don't particularly like the sequence used by postscript, but I guess it is the most likely terminal for which we would have to worry about compatibility with existing scripts. Perhaps a more interesting question is how many of the terminals could support user-defined dash patterns? set style dash 1 2,4,2,4 # short-dashes set style dash 2 8,4,1,4 # long-dash, dot plot sin(x) lc rgb "blue" dashstyle 2, ... > I'm particularly interested in eps, pdf(cairo), png(cairo) and emf > (on behalf of Windows users). To get any dashes you have to set > the "dashed" option for these terminals (except for postscript, > which as I noted is exceptional in doing dashes by default). But > the "linetype" numbers in dashed mode produce different effects > as noted below: > > In postscript, dashed mode: > > solid lines: 1, 10, 19, 28 > regular dash: 2, 11, 20, 29 > short dash: 3, 12, 21, 30 > > in pngcairo, pdfcairo, dashed mode: > > solid lines: 1, 6, 11, 16, 21 > regular dash: 2, 7, 12, 17, 22 > short dash: 3, 8, 13, 18 > > in emf, dashed mode: > > solid lines: 1 to 15 > regular dash: 16 to 30 > short dash: 31 to 33 > > This is a total nightmare with regard to portability. > > Allin Cottrell > -- Ethan A Merritt |
|
From: Allin C. <cot...@wf...> - 2008-10-24 00:05:03
|
On Thu, 23 Oct 2008, Ethan Merritt wrote: > We made a concerted effort for 4.2 to bring the sequence of > point types into conformity across terminals. So far as I > recall, no one argued for doing the same to dash patterns. I > have no objections to someone offering a series of patches that > re-orders the sequence of dash patterns to achieve some level of > cross-terminal agreement. Since I haven't yet looked into the code in detail on this point I'm somewhat in the dark. But what I had (vaguely) in mind was some sort of analogue to the way in which one can now force colors on "line styles" in a consistent, more or less terminal-independent, manner. Could one force a consistently enumerated set of dash-patterns using "set style line dt"? If so, that would avoid disrupting time-honored per-terminal default patterns. You could stay with the defaults if you like, or if you're interested in cross-terminal compatibility you could define a set of line styles including dash-types. (?) Allin Cottrell |
