#326 RGB color support for latex terminal

[Ethan Merritt]

Following lots of discussion, but no clear decision, on the mailing list, I decided to code up color support for the latex terminal.

set term latex color ....

For some reason, dashed lines do not get colored. I don't know why.

Notes on the latex terminal, now that I've had a look at it:

- The curve-drawing is just awful. Surely there's a vector special somewhere that we could user?

- It really needs a fill-box entry

- It also seems to need a closepath() operation. See, for example, how the boxes are not closed properly in candlesticks.dem

[Petr Mikulik]

Logged In: YES
user_id=31505
Originator: NO

Yes, there are such things. Please try "texcad" or "xtexcad" to draw them and see the resulting code.

[Ethan Merritt]

set term latex color

[Ethan Merritt]

Logged In: YES
user_id=235620
Originator: YES

Updated to follow Mojca's advice about placing color initialization after \begin{picture} , and to optimize out repetitive set_color operations.
File Added: latex_color_12feb2007.patch

[Mojca Miklavec]

Logged In: YES
user_id=1411306
Originator: NO

Note that the picture environment supoprt bezier curves, but not lines under arbitrary direction!!!

\line(x slope,y slope){length}
The \line command draws a line of the specified length and slope.
Note that LaTeX can only draw lines with slope = x/y, where x and y have integer values from -6 through 6.

Perhaps one could misuse bezier curves to draw arbitrary lines ;)

But I agree that it should be improved. (I've always been aware of how ugly that is, but I also gave up using picture very soon after realizing that not all line directions are possible.)

The next problem is that picture only supports two line weights: thin and thick. Perhaps the author used \rule to be able to make arbitrary line widths. Ugly (LaTeX) in any case.

Another trick would be to misuse rotatebox (only if user specifies the option to do that). I guess that both pdfTeX and dvips support rotating boxes.

Some useful links for picture drawing:
- http://www.ursoswald.ch/LaTeXGraphics/picture/picture.html
- http://cs.wlu.edu/~necaise/refs/latex2e/env-picture.4.html

Filled rectangles are doable, for filled polygons ... take epslatex.

But I still don't think that trying to implement support for things like this is worth the effort:

set title "gray map"
set pm3d map
set palette gray
set samples 100; set isosamples 100

I've implemented it for ConTeXt, but it results in 100x100x3=30.000 lines of code just to draw the contents of the map. TeX runs out of memmory at that size.

The gnuplot core code needs a patch which could optimize such situations, just as there is a separate postscript routine which improves palette drawing.

[Mojca Miklavec]

Logged In: YES
user_id=1411306
Originator: NO

Your patch seems to work OK. However, some remarks and proposals:

1.) [simple patch] I would write this at the top of the output file (after begin{figure}):
\definecolor{gnuplot lt 1}{rgb}{1,0,0} % perhaps only {lt 1} would suffice
\definecolor{gnuplot lt 2}{rgb}{0,1,0}
...
\definecolor{gnuplot lt 7}{rgb}{1,1,0} % not sure which colors to use

and then switch to \color{gnuplot lt 1} instead of \color[rgb]{1,0,0}.

Also, it might make sense to \definecolor{gnuplot background}{rgb}{0,0,0}

2.) you've put the color switching after \begin{picture}, but you removed switching to black, which is not the wisest thing to do. Imagine that now one uses red before the plot. Then half of the "black/background" colors will turn out red and the other half will turn out black (in a pseudo-random way). I'l talking about this because I already experienced such problems (but in my case it turned out to be a "bug" in metapost - which doesn't set the color to black explicitely, but sets it to black again later, if it setted it to some other color before).

I'm not sure if users need such fancy things (different background color), but either
a) use scopes for color
b) define background color explicitely

For a) one could say "\bgroup" right after \begin{picture} and before any color switching from background color to non-background color and "\egroup" instead of the switch to black and before \end{picture}. This is probably more elegant/straightforward to do.

b) \definecolor{gnuplot background}{rgb}{0,0,0} and use that one, so that the user may potentially redefine that color - there is a solution, but nothing clever comes to my mind at the moment how to do that elegantly without manually editing the resulting file.

At first I didn't really realize how ugly the lines indeed are (I knew that they were composed out of dozens sections, but I imagined that in another way).
YES, lines realy need to be improved. They look horrible (although somewhat acceptable on paper).

Mojca

[Mojca Miklavec]

Logged In: YES
user_id=1411306
Originator: NO

http://en.wikibooks.org/wiki/LaTeX/Packages/Color

[Bastian Märkisch]

Only after committing color support for latex/emtex [ddadfa] I reallized that this had already been done by Ethan more than a decade ago. The version now in CVS uses explicit color names for linetypes instead of RGB values and can also be used with eepic/tpic/emtex terminals. But in gerneral it is very similar.