From: <jc...@fe...> - 2002-07-10 15:43:50
|
On Saturday 06 July 2002 01:47, Alan W. Irwin wrote: | Try the following experiment: | | Make a special copy of x01c (or xw01.py, which is what I used) which | calls plscol0(1,255,255,255) between the first and second calls to | plot1. The plscol0 call sets index 1 of cmap0 to white rather than | the default red. | | If you use interactive devices such as xwin, tk, ntk, etc. you get | the expected result; the first subplot of example 1 continues to have | a red box, red scales, etc., and the remaing sub-plots have white | boxes and scales. | | For the psc (colour postgrip) device the same result also occurs; | the first sub-plot has red box and scales, and the remaining subplots | have white box and scales. | | However, for the xfig and png devices *all* the subplots unexpectedly | have white box and scales. So if you change color indices part way | through a plot, the earlier part of the plot is retroactively changed | for those drivers! | | The simple example I gave was for the discrete colours (cmap0), but I | am getting the same result for example 8 for the png driver with the | continuous colours (cmap1), and the results look quite bad. At the | end of that example (which uses a gray-scale cmap1), I set cmap1 back | to the default before going on with plotting other plots for the tcl | and python front ends. (If I don't do this, example 16 becomes gray | scale rather than the desired default colours since python and tcl | run all examples under a common plinit.) This procedure of resetting | to default cmap1 works well for the psc device, but for the xfig and | png devices, resetting cmap1 to the default at the end retroactively | changes the whole continuous color map of example 8 back to default | (rather than leaving it at the desired gray scale). | | So for both the xfig and png devices (and presumbably jpeg as well) | we have a nasty "retroactivity" problem with any attempt to change | either cmap0 or cmap1 part way through a plot. | | Joao and Andrew, would you be willing to have a look at this problem | for your drivers (xfig.c for Joao and gd.c for Andrew) and fix it? the xfig file format stores colors at a fixed position (variable length)=20 in the begining of the file; latter changes in the colors will thus=20 overwrite the previous color setting, thus the observed results. I think the same happens for any file based format, and can't be fixed. Jo=E3o | | Alan | | email: ir...@be... | phone: 250-727-2902=09FAX: 250-721-7715 | snail-mail: | Dr. Alan W. Irwin | Department of Physics and Astronomy, | University of Victoria, P.O. Box 3055, | Victoria, British Columbia, Canada, V8W 3P6 | __________________________ | | Linux-powered astrophysics | __________________________ | | | | ------------------------------------------------------- | This sf.net email is sponsored by:ThinkGeek | Bringing you mounds of caffeinated joy. | http://thinkgeek.com/sf | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |