Historical question about gnuplot's PostScript terminal

[Ethan A M. <me...@uw...>]

The PostScript terminal implements palette colors in a complicated way.
Or at least it seems complicated to me in retrospect.
I'm wondering if there was a reason it was done the way it was.

The way it was (and still is)
=============================

If the palette mode is "rgbformulae"
   - PostScript implementations of the 3 formulae are written in the output
   - the function \g is defined to convert gray->rgb using them analytically
If the palette mode is "functions"
   - The terminal writes out an approximation table for each function
   - the function \g is defined to convert gray->rgb using interpolation
     between table entries
If the palette mode is "defined"
   - The terminal writes the gradient definitions
   - the function \g is defined to convert gray->rgb using interpolation

In all cases the actual "change color" command in the PostScript output
ends up looking like this
      .1234 g
where ".1234" is the gray value for conversion, and the \g function
converts this into the native PostScript command
      .rrr .ggg. .bbb  setrgbcolor

As I understand it, the original idea was that ".1234 g" uses only
5 characters for the gray value rather than approximately 15-18 characters
if the driver were to write out the .rrr .ggg .bbb values separately.
So it saves some space in the output file.

On the other hand, the interpolation tables take up a lot of space too.
And the burden of converting every single gray value into RGB was borne
by the printer, which I imagine was pretty slow back in the day...

Also, the four digit precision of the gray value means that the driver
cannot skip writing a "change color" sequence to the output even if it
turns out that successive similar gray values will all map to the same RGB.

Why wasn't it this instead?
===========================

The driver always writes a 24bit hex-encoded RGB color:
    0xAABBCC g
As before, the function \g is defined to unpack this into 
    .rrr .ggg .bbb setrgbcolor

That's 8 characters for the color rather than 5, so slightly worse.
But not much worse.

Since the conversion from gray->RGB is done by gnuplot rather than
by a PostScript interpreter running in a printer, it's much faster.

Bonus 1: The terminal driver knows exactly what the RGB value will be,
and can choose not to write it if it duplicates the previous value.

Bonus 2: No need to write out analytical functions or interpolation
tables that are specific to a single pm3d plot.  The gray->RGB
conversion has already been done at the time of file creation.

	just curious

		Ethan