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 |