On 2007-11-28 22:05-0000 Andrew Ross wrote:
> On Wed, Nov 28, 2007 at 10:44:07AM -0800, Alan Irwin wrote:
>>
>> 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
>>[...]
> Alan,
>
> You are correct the the xyshow command is the cause of the problem.
>
> The syntax is
> string numarray xyshow
>
> For each glyph in the string there needs to be a pair of numbers which
> define the x and y displacement of the glyph. The array is ended with a
> 0. If the end of the array is reached before all the glpyhs are plotted
> a rangecheck error occurs. This is precisely what happens here.
> [...]
> So, it looks like this is a cairo issue since it seems valid for gs to
> generate a rangecheck error in this case. This issue only manifests
> itself with newer versions of ghostscript though.
Thanks for that clear explanation of the inconsistency between the
string length compared to the array length (always one x,y pair short
of what it should be).
Here are the complete list of postscript problems which I discovered by
using the --no-quiet gv option for every page of every *.pscairo result.
All errors occurred on the first page except for example 21.
/rangecheck in xyshow (examples 3 [just discussed], 4, 8, 9, 11, 18, 20,
21 [3rd page], 26, and 28)
grep confirms this problem occurs if and only if xyS is used.
[EMAIL PROTECTED]> grep -l ' xyS' *.pscairo
x03c.pscairo
x04c.pscairo
x08c.pscairo
x09c.pscairo
x11c.pscairo
x18c.pscairo
x20c.pscairo
x21c.pscairo
x26c.pscairo
x28c.pscairo
I looked in detail up through most of x08c (before I got tired), and
in every xyS case the array is missing one x,y pair. So at least the
xyS issue is consistent. :-)
My tests showed there was an additional kind of error:
/typecheck in definefont (examples 7, 23, and 24)
Here is the typical gv error message:
Error: /typecheckGPL Ghostscript 8.56: Unrecoverable error, exit code 1
in definefont
Operand stack:
CairoFont-3-0 --dict:8/10(L)-- Font
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-- 1765
2 3 %oparray_pop
Dictionary stack:
--dict:1086/1123(ro)(G)-- --dict:0/20(G)-- --dict:80/200(L)--
Current allocation mode is local
Last OS error: 2
All examples with text use the definefont operator.
The normal form that appears in every working example seems to be of this
pattern:
11 dict begin
/FontType 42 def
/FontName /CairoFont-2-0 def
.... more defs concluding with
/sfnts [<..............>] def
FontName currentdict end definefont pop
where <..............> is a large hexadecimal string.
This pattern seems to be consistent with the pattern mentioned in the
PostScript Language Reference of
key font definefont font
In the above case my guess is the "11" is the key, and everything from
"dict begin" to "currentdict end" defines the font object, and "pop" supplies
the font again???
Examples 7, 23, and 24 have this normal pattern for the use of definefont,
and also a completely different pattern consisting of a key "/CairoFont-3-0"
and explicit use of the "<<" and ">>" operators to set up the dictionary
followed by (as per the normal pattern) "definefont pop". I think this
different pattern may be associated with the special handling (the rendering
of the box with unicode number inside) of missing glyphs that appears in
those examples, and there may be some cairo PostScript back-end screw-up
with the types used for the dictionary items of this special definefont
pattern.
I have looked over the text-handling code in cairo.c, and it is completely
common between pdfcairo and pngcairo (both working), and pscairo. Thus, I
ascribe this problem to the PostScript back-end for libcairo, and I
will be reporting both issues to the cairo list after some googling and
checking of older messages.
My impression from previous lurking on the cairo list is there is only one
guy working on the PostScript back end. Hopefully, he will spot the causes
of the two above issues and come up with a quick fix.
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
__________________________
-------------------------------------------------------------------------
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
