Re: Fwd: [Gnuplot-developers] [ gnuplot-Patches-1651015 ] Cairo-based PDF terminal

[Ethan M. <merritt@u.washington.edu>]

On Monday 12 March 2007 00:19, you wrote:
> >> > In particular, what happens to palette settings (for example)
> >> > when you jump from one page of the document to another?
> 
> Anyway, we really don't allocate palettes for cairopdf:
> So if gnuplot asks for the right colors in term->set_color, it will get
> them for sure.
Code quoted from cairopdf driver:
[snip]
> 	} else if (colorspec->type == TC_FRAC)
> 		rgb1_from_gray( colorspec->value, &rgb1 );
[snip]
> 	gp_cairo_set_color(&plot, rgb1);


Got it.  So you rely on the gnuplot utility routine rgb1_from_gray
to  do the color mapping.   That is different from post.trm, which
does essentially this:

   /* map [0;1] to gray/colors */
     fprintf(gppsfile, "%.4g g ", colorspec->value);

where the operator "g" is defined in the page header based on
the current palette.  In other words, the color mapping is done
by the postscript interpreter, not by gnuplot.  I believe the
reason for this was simply to make the output file shorter.
Given defintions in the prolog
  \g {complicated color mapping code} def
  \C {setrgbcolor} def

then
  ".123 g"
is shorter than
  "rrr ggg bbb C"

But not very much shorter. So it is a weakly justified optimization.

I'm cc'ing this to Petr, who may want to comment on whether
there are cases where weak optimization (factor of 2 at best)
is still useful. 

So there are two questions:

1) Is this really worth doing in PostScript?
2) If it is worth it for PostScript, does that mean it is also
   worth doing for pdf?

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742