On Wed, Nov 28, 2007 at 04:59:21PM -0800, Alan Irwin wrote: > > 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.
Alan, This is a difference from my Ubuntu gutsy setup. I do not see these errors at all. (gv 3.6.3, gs 8.61, libpango1.0-dev 1.18.3-0ubuntu1, libcairo2-dev 1.4.10-1ubuntu). > > 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. My postscript does containt this /CairoFont-3-0 command for these 3 examples (and only these 3 examples). It renders correctly, and without warnings, on my gs which is newer than yours. This one we might be able to put down to ghostscript errors. Do you see this on both you debian testing and debian oldstable systems? 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
