Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2006-06-09 08:22:28
|
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. Known bug? (I know there were some emails on the list recently about postscript.) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-09 18:10:27
|
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.
--- gnuplot/src/color.c 2006-06-09 11:04:52.000000000 -0700
+++ gnuplot-cvs/src/color.c 2006-06-09 11:05:07.000000000 -0700
@@ -120,7 +120,7 @@
passed there to create the header or force its initialization
*/
- if (memcmp(&prev_palette, &sm_palette, sizeof(t_sm_palette))) {
+ if (1) {
term->make_palette(&sm_palette);
prev_palette = sm_palette;
FPRINTF(("make_palette: calling term->make_palette for term with ncolors == 0\n"));
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Daniel J S. <dan...@ie...> - 2006-06-09 19:21:53
Attachments:
pspalbug-djs-9jun2006.patch
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2006-06-09 19:27:57
|
Daniel J Sebald wrote: > 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". On second thought, this might be dodgy because if the file is sent to a printer, the palette on page 1 may be long gone when page 41 roles around. So page 41 referencing page 1 would be dodgy. The most surefire way to protect against devices with limited memory capacity would be to put the palette on each page. Bloated file, but... What does PDF do? That seems to work and quite often is a compact file. (Perhaps it is the compression that does that.) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-09 23:11:28
|
On Friday 09 June 2006 12:36 pm, Daniel J Sebald wrote: > > 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. Got it. OK, so the optimization cannot work for PostScript. We'll have to revert the special-case PostScript code. The bug in gsave/grestore that this code reveals may still be there, but it probably won't bite anyone. The mismatch is revealed because the gsave is triggered by code that was made conditional, whereas the corresponding grestore (wherever it is) is unconditional. > What does PDF do? PostScript is the odd man out because post.trm is the only driver that pushes the task of assigning palette colors into the output file itself. For all other terminals, including PDF, the core code keeps track of what colors to use in rendering the current plot. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
