On Wed, Nov 28, 2007 at 10:44:07AM -0800, Alan Irwin wrote:
> 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!
My (semi) working older configuration is gv 3.6.1 and gs 8.50. The newer
(not working) version is gv 3.6.3 and gs 8.61.
This massively narrows down the range of ghostscript versions which
might be causing the trouble.
> 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, I'll investigate this further.
Andrew
-------------------------------------------------------------------------
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
