Re: postscript terminal bug?

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Friday 09 June 2006 01:31 am, Daniel J Sebald wrote:
> 
>>The last demo of 'pm3d.dem', the one showing the grid point options,
>>doesn't appear to work correctly with the postscript terminal.  The
>>demo works fine in PDF.  
> 
> 
> Confirmed.
> 
> There is a missing "gsave" in the output, at the location where
> there used to be a palette reload sequence.  This makes me suspect
> the change from 2006-03-18 that removed this reload sequence
> if the palette was unchanged.
> 
> ...yup.
> This one line reversion makes the problem go away.
> That doesn't mean it is the correct fix, of course, but it 
> confirms the origin of the problem:
> 
> Can you look into this, Dan?
> I think you were the one who suggested that optimization originally.

Good memory...  Well, I've confirmed a solution.  There are extra grestore's in the PostScript code.  Attached is a patch showing which code simply need be deleted from graph3d.c.  Reading the message that was left there, it sounds as though this code isn't necessary, at least in the current set up.  (If it isn't needed, one wonders if the terminal entry can be removed altogether.)

I say "current set up" because there is still a significant problem.  I think our logic for not writing the palette so often is correct.  However, this is still the element of these workings in which the terminal should retain the palette in case it personally needs it again.

Here's the problem.  I'm paging through the output of 'pm3d.dem', call it 'pm3d.ps', for the postscript terminal.  If I linearly step from page 1 through page 41 the palette is correct.  However, if I jump about, the palette is not correct.  Say I go to the page with the bowl shaped gray scale, then start stepping backward.  The pages that had a color palette now have a gray palette until a page is reached where the palette has changed.

Now, PDF output, call it 'pm3d.dem' works fine.  I suspect that internally, the PDF driver keeps a record of the palette the programmer last sent it and knows to put a copy of the palette in for each page.  (Or somehow define the palettes up front and put a reference in for each page so that the palette can be saught.)

So what would be your strategy for this?  My suggestion is for the PostScript terminal driver to keep a record of the palette sent to it whenever the core code sends a new palette.  (I think all of the code is present for easily making a copy.)  Then for each new page, the terminal code puts a copy of the palette in place *without the core code telling it to do so*.  Or somehow we creatively reference a palette somewhere else in the document.  Not sure how to do that... maybe write a little PostScript routine to "search for page #X and use its palette".

Dan