In the course of doing a lot of research on this problem, I just made a most
interesting discovery. The problem has nothing to do with gcc version,
pango/cairo stack, or whether the system is Intel or PPC or 32-bit or
64-bit. Instead, it is all about gv/gs version!
If I use gv version 3.6.3/gs version 8.56 from my Debian testing system to
view pscairo results from _either_ my Debian oldstable system or Debian
testing system I get the bad viewing results that have been described
previously.
If I use gv version 3.6.1/gs version 7.07.1 from my Debian oldstable system to
view pscairo results from _either_ my Debian oldstable system or Debian
testing system I get good-looking plots for every page of every example!
So it appears that the PostScript backend to Cairo produces PostScript
results that the older gv/gs combination can understand, but the newer gv/gs
combination cannot.
Andrew and Hazen, could you please give the results of both
"gv --version" and "gs --version"?
I have no idea whether the fault lies with the newer gv/gs or the cairo
PostScript back end not following PostScript standards exactly. But this
discovery greatly narrows the huge range of possibilities I was considering
before.
Andrew, to pursue this further I think we need to find out exactly what in
x03.pscairo is causing modern gv/gs to choke. For Debian testing, here is
the current ghostscript error message (which you get by using the --noquiet
option for gv):
Error: /rangecheckGPL Ghostscript 8.56: Unrecoverable error, exit code 1
in --xyshow--
Operand stack:
(\002\001) --nostringval--
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval--
--nostringval-- 2 %stopped_push --nostringval-- --nostringval--
--nostringval-- false 1 %stopped_push 1797 1 3 %oparray_pop
1796 1 3 %oparray_pop 1792 1 3 %oparray_pop 1675 1 3
%oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval--
--nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
--dict:1086/1123(ro)(G)-- --dict:0/20(G)-- --dict:80/200(L)--
Current allocation mode is local
The ghostscript error message above says the error occurs for the xyshow
command, but that command appears only in the prolog of the file.
[EMAIL PROTECTED]> grep -n xyshow x03c.pscairo
20:/xyS{xyshow}bind def
I don't really understand the PostScript language, but that prolog line
appears to associate xyS with xyshow. The good news is that xyS appears
quite rarely within the file:
[EMAIL PROTECTED]> grep -n xyS x03c.pscairo
20:/xyS{xyshow}bind def
2519:[-4.670898 -8.090233 0 ] xyS
2537:[-8.090233 -4.670898 0 ] xyS
2573:[8.090233 -4.670898 8.090233 -4.670898 0 ] xyS
2591:[4.670898 -8.090233 4.670898 -8.090233 0 ] xyS
2627:[-4.670898 -8.090233 -4.670898 -8.090233 0 ] xyS
2645:[-8.090233 -4.670898 -8.090233 -4.670898 0 ] xyS
2681:[8.090233 -4.670898 8.090233 -4.670898 0 ] xyS
2699:[4.670898 -8.090233 4.670898 -8.090233 0 ] xyS
Those same lines also appear in the x03c.pscairo version that was generated
on the Debian oldstable system.
Could the problem be the first (and second) xyS calls which appear to
have the wrong number of arguments? It is quite possible that the newer
gv/gs combination has tests for issues like that, while the older version
does not and somehow muddles through. This is just speculation though, since
I don't really understand PostScript.
Andrew, you have a lot more understanding of the PostScript language than I
do so I am looking forward to your comments on the above results and the
results of your further investigations to pinpoint what the exact problem
is. If it does turn out to be some issue with the Cairo backend being
sloppy with the PostScript language, then I will need your backup to present
this issue properly to the cairo mailing list.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
