Menu
▾
▴
gnuplot-beta
|
From: Harald H. <h.h...@tu...> - 2005-02-05 16:19:51
|
A view days ago, Ethan has told me that it is possible to give the line color by specifying the rgb value. This is a great thing but I have not found out how to specify the line type (i.e., dash style), too. set style line 1 lt rgb "#000000" set style line 2 lt rgb "#00FF00" set style line 3 lt rgb "#FF0000" This sequence, for instance, produces a black solid line type, a green one with long dashes and a red one with shord dashes. But how to produce too solid line types and then a dashed one? Do I miss something in the documentation or is that not possible yet? Another thing: Why does gnuplot switch on the color palette when using an rgb-defined color? I think it should not do that, automatically. In this code, set output 'asdf.ps' set terminal postscript dashed color dashlen 4 set style line 1 lt rgb "#000000" set style line 2 lt rgb "#00FF00" set style line 3 lt rgb "#FF0000" plot sin(x) ls 1, cos(x) ls 2, sin(x)*cos(x) ls 3 set output for example, the color palette is useless. Regards Harald PS: Thanks, Ethan, for enhancing rgb-color specification to labels! -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-02-05 18:51:24
|
On Saturday 05 February 2005 09:09 am, Ethan Merritt wrote:
> Unfortunately you cannot currently set a line style to have a
> different dot/dash pattern than it has by default, but for a totally
> unintended feature that's not such a severe limitation.
Assuming that we would like to clean this up and document it properly,
there are a few things that should be decided.
- The current (unintended) mechanism only works with line styles,
not with in-line specifications like "plot <foo> lt <bar>".
Is that sufficient?
- The obvious extension is to add a keyword "{dt|dashtype} <n>".
In the context of setting a line style, the command would be
set style line <tag> dt <N> lt rgb "#aabbcc"
This would be exactly equivalent to the current behaviour of
set style line <N> lt rgb "#aabbcc"
except that you could have (<tag> != <N>)
- A surprising number of terminal types already support dashed lines:
apollo be cgm dxf eepic emf epslatex fig gnugraph gpic gpr
hpgl iris4d metafont metapost next openstep post pslatex
pstricks tgif tpic unixplot win x11
But I suspect that other than the ones piggybacking on post.trm
they all disagree about specific dot/dash patterns.
Is this worth addressing?
- Another alternative is to create a small number of new linetypes.
I suppose these would internally be LT_DOTTED, LT_DASHED,
LT_DOTDASH, ..., and have negative index values (similar to -1
for the current LT_BORDER line type). Support for this would
have to be gradually added to terminal drivers individually.
This would produce a consistent set of patterns for all drivers.
But it has a big disadvantage compared to the current accidental
method. The current method is so harmless that I didn't even
know it existed; individual terminal drivers don't know anything
about it, it "just works" for those that support dash patterns.
By contrast, commands using special new line types would generate
various errors on terminals that had not yet been modified to
accept them.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742
|
|
From: Harald H. <h.h...@tu...> - 2005-02-05 20:24:08
|
On Sat, 5 Feb 2005, Ethan Merritt wrote:
> On Saturday 05 February 2005 09:09 am, Ethan Merritt wrote:
> > Unfortunately you cannot currently set a line style to have a
> > different dot/dash pattern than it has by default, but for a totally
> > unintended feature that's not such a severe limitation.
>
> Assuming that we would like to clean this up and document it properly,
> there are a few things that should be decided.
>
> - The current (unintended) mechanism only works with line styles,
> not with in-line specifications like "plot <foo> lt <bar>".
> Is that sufficient?
I think not. Maybe it would be worth to seperate choosing the dashtype and
the color (for example using 'dashtype' as suggested by you and 'color').
Linetype could then be preserved as it is for compatibility reasons.
> - The obvious extension is to add a keyword "{dt|dashtype} <n>".
> In the context of setting a line style, the command would be
> set style line <tag> dt <N> lt rgb "#aabbcc"
> This would be exactly equivalent to the current behaviour of
> set style line <N> lt rgb "#aabbcc"
> except that you could have (<tag> != <N>)
I think this is the best approach. But I would prefer to use the keyword
'colour' or 'color' for the colour. E.g.:
Set dashtype to <N> and color to RGB value of aa, bb, cc:
set style line <tag> dashtype <N> color rgb "#aabbcc"
Set dashtype to <N> and color to the <M>th color in automatic color order:
set style line <tag> dashtype <N> color <M>
Set dashtype to <N> and color to named color:
set style line <tag> dashtype <N> color named "name"
Set dashtype to <N> and color to CMYK value of aa, bb, cc, dd:
set style line <tag> dashtype <N> color cmyk "#aabbccdd"
Set dashtype to <N> and color to the <N>th color in automatic color order:
set style line <tag> dashtype <N> color <M>
set style line <tag> linetype <N>
I think the keyword 'colour' is more clear because it tells what it
changes. And at the moment, linetype changes both color and dashtype in
many cases which should be preserved for compatibility.
Escpecially for postscript there is a difference between cmyk and rgb (and
hsb) colours depending on the output device. Of course, for pixel
terminals the colours have to be converted into the output colour model.
> - A surprising number of terminal types already support dashed lines:
> apollo be cgm dxf eepic emf epslatex fig gnugraph gpic gpr
> hpgl iris4d metafont metapost next openstep post pslatex
> pstricks tgif tpic unixplot win x11
> But I suspect that other than the ones piggybacking on post.trm
> they all disagree about specific dot/dash patterns.
> Is this worth addressing?
Yes, I think, all terminals should be harmonized.
> - Another alternative is to create a small number of new linetypes.
> I suppose these would internally be LT_DOTTED, LT_DASHED,
> LT_DOTDASH, ..., and have negative index values (similar to -1
> for the current LT_BORDER line type).
I don't really like this idea. In my opinion, the other approach is more
flexible and makes future work easier. Indeed it looks like more work for
the moment.
Regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-02-05 21:32:10
|
On Saturday 05 February 2005 12:25 pm, Harald Harders wrote:
> On Sat, 5 Feb 2005, Ethan Merritt wrote:
>
> > - The obvious extension is to add a keyword "{dt|dashtype} <n>".
> > In the context of setting a line style, the command would be
> > set style line <tag> dt <N> lt rgb "#aabbcc"
> I think the keyword 'colour' is more clear because it tells what it
> changes. And at the moment, linetype changes both color and dashtype in
> many cases which should be preserved for compatibility.
> Set dashtype to <N> and color to RGB value of aa, bb, cc:
> set style line <tag> dashtype <N> color rgb "#aabbcc"
But is it really more clear? Remember that currently the
"line style" also includes the point type and point size.
Is "colour" to apply to both the line and the points, or is
it specifically the line colour?
And I think there are compatibility issues. Consider the command
plot "foo" with linespoints dashtype <n> color rgb "red"
What exactly do you expect to happen to the points?
And what should happen on a terminal that cannot set rgb colors?
> Escpecially for postscript there is a difference between cmyk and rgb
> (and hsb) colours depending on the output device.
So? That's a totally orthogonal issue. Anything that depends on the
eventual PostScript output device is clearly out of gnuplot's control.
If you are concerned to have an hsv option, this could either be created
as a parallel option to rgb, or else we could define a user-accessible
string-valued function hsv2rgb(H,S,V) that returns "#RRGGBB". E.g.
set style line 1 lt rgb hsv2rgb(H,S,V)
Hmmm. Actually, I think you could do that anyhow right now just by
loading a script that defined such a funciton.
> > - A surprising number of terminal types already support dashed lines:
> > But I suspect that other than the ones piggybacking on post.trm
> > they all disagree about specific dot/dash patterns.
>
> Yes, I think, all terminals should be harmonized.
Good luck. There is no guarantee that any particular terminal device
is capable of a particular dash style. We haven't even reached a
point where all terminals agree on colors! (Nor do I necessarily
think they should - what looks good on the screen may not look good
on paper).
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2005-02-05 21:44:34
|
Ethan Merritt wrote: > >Good luck. There is no guarantee that any particular terminal device >is capable of a particular dash style. We haven't even reached a >point where all terminals agree on colors! (Nor do I necessarily >think they should - what looks good on the screen may not look good >on paper). > > Speaking of which, I've been using octave's color scheme for gnuplot. Some of the colors in X11 are too bright to contrast against a gray or white background. In particular, green and cyan are difficult to see. Whereas in the PDF terminal the colors come out a much darker green and cyan. (Cyan is still a bit bright in PDF, but OK.) I'd say it isn't so much the terminal that is the issue as it is the ultimate plotting background color. Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-02-05 22:06:00
|
Ethan Merritt wrote: >On Saturday 05 February 2005 01:45 pm, you wrote: > > >>Some of the colors in X11 are too bright to contrast against a gray or >>white background. In particular, green and cyan are difficult to see. >> >> > >You do realize that you can redefine the X11 colors in your >.Xdefaults file? > > Oh yeah, I keep forgetting about that .Xdefaults file. >After all, the appearance also depends on your local >monitor gamma setting, and the default background color, and so on. > > You're right. I'd say though that trying to retain color schemes across terminals is a good thing. If someone wants to modify the scheme, he or she can. It's quite disorienting when the color scheme changes across terminals. (Yellow becoming brown seems the most egregious example I can think of. Magenta to purple isn't too bad... I know, megenta and purple are close enough that adjusting the screen might change one to another.) Dan |
|
From: Harald H. <h.h...@tu...> - 2005-02-05 22:52:54
|
On Sat, 5 Feb 2005, Ethan Merritt wrote:
> On Saturday 05 February 2005 12:25 pm, Harald Harders wrote:
> > On Sat, 5 Feb 2005, Ethan Merritt wrote:
> >
> > > - The obvious extension is to add a keyword "{dt|dashtype} <n>".
> > > In the context of setting a line style, the command would be
> > > set style line <tag> dt <N> lt rgb "#aabbcc"
>
> > I think the keyword 'colour' is more clear because it tells what it
> > changes. And at the moment, linetype changes both color and dashtype in
> > many cases which should be preserved for compatibility.
> > Set dashtype to <N> and color to RGB value of aa, bb, cc:
> > set style line <tag> dashtype <N> color rgb "#aabbcc"
>
> But is it really more clear? Remember that currently the
> "line style" also includes the point type and point size.
> Is "colour" to apply to both the line and the points, or is
> it specifically the line colour?
>
> And I think there are compatibility issues. Consider the command
> plot "foo" with linespoints dashtype <n> color rgb "red"
>
> What exactly do you expect to happen to the points?
You are right that we also have to consider the points. I think the
keywords 'linecolour' and 'pointcolour' as well 'pointlinewidth' could
serve as start. Then, the user can set the colours of the line and the
points independently.
In general, I think the user should be able to determine the linewidth,
dashtype, color of the line as well as linewidth, size, and type of the
symbol independently. I do not like a misleading name as 'linetype' for
one of these switches. In addition, linetype is used for a different
purpose in the current version. This should be preserved.
> And what should happen on a terminal that cannot set rgb colors?
What happens with a terminal that cannot set rgb colors in the current
version? Where is the difference in adding a new keyword that only changes
the colour instead of doing multiple things including changing the colour?
The fact that some terminals may not be able to use a new feature should
not prevent us from adding this new feature. For example text rotation at
arbitrary angles has been invented even though there are terminals that
are not capable of this.
> > Escpecially for postscript there is a difference between cmyk and rgb
> > (and hsb) colours depending on the output device.
>
> So? That's a totally orthogonal issue. Anything that depends on the
> eventual PostScript output device is clearly out of gnuplot's control.
> If you are concerned to have an hsv option, this could either be created
> as a parallel option to rgb, or else we could define a user-accessible
> string-valued function hsv2rgb(H,S,V) that returns "#RRGGBB". E.g.
> set style line 1 lt rgb hsv2rgb(H,S,V)
> Hmmm. Actually, I think you could do that anyhow right now just by
> loading a script that defined such a funciton.
That is not correct. The colorspaces RGB and CMYK are different in praxis.
The user always should use the color model that is used by the final
output device (just speak to people doing desktop publishing). For
example, to produce a presentation for a projector you should use RGB. If
you want to print on a Laser or Ink Jet printer you should use CMYK from
the start on.
Have a look at this example:
%!PS-Adobe-2.0 EPSF-2.0
%%BoundingBox: 0 0 201 100
%%EndComments
/Box { 100 0 rlineto 0 100 rlineto -100 0 rlineto closepath fill } def
newpath 0 0 1 setrgbcolor 0 0 moveto Box
newpath 1 1 0 0 setcmykcolor 101 0 moveto Box
showpage
%%Trailer
If I convert it to pdf using ghostscript 8.50 and view it with Acrobat
Reader 5.0, the nominally equal colours RGB 0,0,1 and CMYK 1,1,0,0 look
rather different.
If a users wants to reach a colour that fits to the rest of his document
he may be forced to use a different colour model then RGB.
If the output file format does not support a mixture of RGB and CMYK data
(for example pixel formats), a conversion of these colour models is
necessary, of course.
> > > - A surprising number of terminal types already support dashed lines:
> > > But I suspect that other than the ones piggybacking on post.trm
> > > they all disagree about specific dot/dash patterns.
> >
> > Yes, I think, all terminals should be harmonized.
>
> Good luck. There is no guarantee that any particular terminal device
> is capable of a particular dash style. We haven't even reached a
> point where all terminals agree on colors!
I think we will never reach a more or less satisfactury state if we start
like that. If we start to harmonize some of the terminals it is better
than doing nothing.
> (Nor do I necessarily
> think they should - what looks good on the screen may not look good
> on paper).
This is an important issue. For many terminals you don't know which output
device will be used. Of course, x11 is merely for screen. But I am using
Postscript for both screen (projector presentations) and paper. Same
applies to png and jpg. And much is individual taste of the user. Thus,
the user should be able to select the colours and dash types as he wants
to use them, independently.
Regards
Harald
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Petr M. <mi...@ph...> - 2005-02-07 10:56:53
|
> - The obvious extension is to add a keyword "{dt|dashtype} <n>".
OK
> - A surprising number of terminal types already support dashed lines:
> apollo be cgm dxf eepic emf epslatex fig gnugraph gpic gpr
> hpgl iris4d metafont metapost next openstep post pslatex
> pstricks tgif tpic unixplot win x11
> But I suspect that other than the ones piggybacking on post.trm
> they all disagree about specific dot/dash patterns.
> Is this worth addressing?
Same linetype should produce the same pattern. And all terminals should
support "solid|dashed" option.
> - Another alternative is to create a small number of new linetypes.
> I suppose these would internally be LT_DOTTED, LT_DASHED,
> LT_DOTDASH, ..., and have negative index values (similar to -1
> for the current LT_BORDER line type). Support for this would
Good idea.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-02-05 17:09:43
|
On Saturday 05 February 2005 08:21 am, Harald Harders wrote:
> A view days ago, Ethan has told me that it is possible to give the line
> color by specifying the rgb value. This is a great thing but I have not
> found out how to specify the line type (i.e., dash style), too.
> Do I miss something in the
> documentation or is that not possible yet?
It turns out that it is possible, although it was an unplanned feature.
Here is what I posted to the newsgroup yesterday:
In thinking about how this would have to work, I came to the unexpected
realization that it is already possible in the current CVS version of
gnuplot. This was not intentional; it's just a happy accident.
The key is that there is a recent feature that you can specify the color
of a line type, or line style, as an explicit RGB triple. Certain
well-known colors can be referenced by name. See "help colorspec".
The happy accident is that this is applied *on top of* whatever
characteristics the line already had. For most terminals that is
effectively just a replacement of one color by another. But for
a terminal that support dot/dash/solid line types, it is another story.
So what you can do right now with the CVS code is the following:
set term post color dash
set style line 1 lt rgb "red"
set style line 2 lt rgb "purple"
set style line 3 lt rgb "#FF00AA"
and so on. Each line style keeps its default dot/dash/solid pattern
from the default sequence, but you can assign any color you like to it.
Unfortunately you cannot currently set a line style to have a
different dot/dash pattern than it has by default, but for a totally
unintended feature that's not such a severe limitation.
Since the dot/dash pattern cycles every 9 style types, the following
demo give two sets of lines, one in red, the other in blue.
The red and blue sets contain matching solid and dashed types.
#
# Demonstrate forcing a fixed color onto dot/dash lines in postscript
#
set title "Forced combinations of color and dot/dash/solid\n(PostScript
terminals only)"
#
set term post eps color dash dl 3.0
set output 'dash.eps'
#
set style line 1 lt rgb 'red' lw 2
set style line 2 lt rgb 'red'
set style line 4 lt rgb 'red'
set style line 5 lt rgb 'red' lw 3
#
set style line 10 lt rgb 'blue' lw 2
set style line 11 lt rgb 'blue'
set style line 13 lt rgb 'blue'
set style line 14 lt rgb 'blue' lw 3
#
unset colorbox
set xrange [-1.8:1.8]
set yrange [0:1.1]
set key left
#
plot sin(x) ls 1 ti "ls 1", 0.8*sin(x) ls 2 ti "ls 2", \
0.6*sin(x) ls 4 ti "ls 4", 0.4*sin(x) ls 5 ti "ls 5", \
cos(x) ls 10 ti "ls 10", 0.8*cos(x) ls 11 ti "ls 11", \
0.6*cos(x) ls 13 ti "ls 13", 0.4*cos(x) ls 14 ti "ls 14"
> Another thing:
> Why does gnuplot switch on the color palette when using an rgb-defined
> color?
That's a bug, obviously. The problem is that the program is currently
only tracking the use of pm3d colors as TRUE or FALSE. It doesn't
separately track *why* they are being used. A similar problem exists
for surfaces. "splot sin(x) with lines lt rgb 'gold'" doesn't work,
because the flag for palette coloring causes it to color the whole
surface by Z value rather than recognizing that a single, uniform
color was requested.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742
|
|
From: Petr M. <mi...@ph...> - 2005-02-09 11:14:57
Attachments:
rgb_no_colorbox.diff
|
> Another thing:
> Why does gnuplot switch on the color palette when using an rgb-defined
> color? I think it should not do that, automatically. In this code,
I have removed this untentional behaviour by the enclosed patch. Do you like
it? Try to play with (un)commenting lines below:
#set label 1 "ahoj" at 0,1 tc palette frac 1
set label 1 "ahoj" at 0,-1 tc rgbcolor "#0000FF"
#set style line 2 lt palette frac 1
set style line 2 lt rgb "#0000FF"
plot x w l ls 2
Note:
splot x w l # ls 2
does not work due to a bug described below.
***
There seem to be one bug and one "inconsistency" in the current explicit
"rgb" functionality:
1. The splot acts as "with line palette" instead of a plot with blue lines:
set style line 1 lt rgb "#0000FF"
plot x*x with l ls 1
pause -1
splot x with l ls 1
2. I think that the rgb command should be the same for both label and
linetype, i.e. "rgb$color":
plot sin(x) lt rgbcolor "#FF00FF"
currently reports an error.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-02-10 19:31:06
|
Your simple patch for the colorbox looks fine. Do you see a way to construct a similar fix for the 3D bug? > 2. I think that the rgb command should be the same for both label and > linetype, i.e. "rgb$color": > plot sin(x) lt rgbcolor "#FF00FF" Sure. Added to cvs. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-02-11 11:40:09
|
> Your simple patch for the colorbox looks fine. > Do you see a way to construct a similar fix for the 3D bug? It's in cvs. However, can you please fix that the "with l ls 1" works also for splots, not only for plots? set style line 1 lt rgb "#0000FF" plot x*x with l ls 1 pause -1 splot x with l ls 1 --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-02-12 05:52:21
|
On Friday 11 February 2005 03:40 am, Petr Mikulik wrote: > > However, can you please fix that the "with l ls 1" works also for > splots, not only for plots? In cvs. -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X