On 2004-09-06 18:57+0100 Jo=E3o Cardoso wrote:
> I coulnd't reproduce (in the build tree) the reported problem. The GIF
> device works fine for me with any of the x??c Octave demos.
Actually, that was everybody else's experience as well. Gif seems fine wit=
the low-level (x example) interface.
> I had to download, compile and install gd-2.0.28 in order to have GIF
> support. Perhaps the problem is the gd library version?
My tests have always been for that version (Debian testing version,
> I had however some other problems to compile plplot_octave --- strange
> that nobody else reported it. I had to change the matwrap options in
> order to have no errors, as the other attached patch shows.
I don't understand why this patch (just committed by Rafael) is now
required. (It wasn't the last time I ran a complete check which I think was
sometime in the last week or so.) The only change is you replace
$(srcdir)/plplot_octave_rej.h by plplot_octave_rej.h. On my system, with a
build in the source tree, $(srcdir) reduces to ".", but somehow that is now
confusing the local bindings/octave/matwrap/matwrap perl script. Could we
fix that script instead? If we do it that way, we don't break
the separate build tree case.
> cd plplot/bindings/octave
octave:1> fig(1,"gif","foo.gif"); plSetOpt("fam","1"); p7; closefig
> This generates two GIF files/images. The p7 demo changes the colormap,=20
> so one should be able to see different colormap in each of the
> generated files. However, this does not happens, both figures have the
> same (last set) colormap, but that is is a problem of the GIF driver
> and not of octave.
I confirm that there appears to be a colour map problem with p7 both in the
gif and png devices when compared to the psc device results. However, the
octave logic for that plot is still problematic; if you look at the results
of the first page (even in postscript) there seems to be two different sets
of labels superimposed on each other. I would like to see those p7.m logic
problems straightened out before we come to any conclusions about how gif
and png handle colour maps. For example, those devices do just fine for the
python/xw08.py example where the colour map is reset several times.
> [out of order]
> With the p?? Octave demos there is also no problem, if we apply the
> attached patch.
This figure.m patch (just committed to cvs by Rafael) works for me.
plplot-test.sh now goes through without any problems with the gif device.
The "p" example results (for all devices including postscript) are now much
better. Also, valgrind results (within the noise created by memory
management problems in octave itself) seem okay for this simple test that
did not work before:
valgrind --num-callers=3D10 octave -f -q -p $octavedir
figure (1, "psc", "foo.ps");
colormap (ones (10, 3));
Thanks Joao, for finding the fix to this subtle problem!
In sum, the principal problem seems to have been addressed by Joao's
figure.m change, but there remain some other issues.
* I believe to avoid breaking the separate build tree case for octave,
Rafael's recent commit for Makefile.am should be reverted. Instead, I
believe the fix should be made in the bindings/octave/matwrap/matwrap perl
script to recognize forms like dirname/filename to access the
* the problems with the p7 logic need to be addressed.
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project