From: Alan W. I. <ir...@be...> - 2007-11-28 08:23:35
|
Here is the score now: pango 1.14.5 and cairo 1.2.4 are fine except for tiny text (Andrew). pango 1.15.5 and cairo 1.2.6 are fine (Hazen PPC/64). *pango 1.16.4 and cairo 1.4.6 are fine (Alan Intel/32). *pango 1.16.4 and cairo 1.4.6 have major issues (Alan Intel/64). pango 1.16.5 and cairo 1.4.10 are fine (Hazen, Intel/32). pango 1.18.3 and cairo 1.4.10 have major issues (both Alan Intel/64 and Andrew) Andrew, what platforms did you do your tests on? Those first two (asterisked) results for me were done with identical source code for the complete stack of pango-related libraries (about 15 of them). The stack for the first good result was built with jhbuild on my Debian sarge Intel 32-bit system some time ago. The stack for the second bad result was built today with jhbuild on my Debian testing Intel 64-bit system. (jhbuild is a GNOME build system that organizes autotools builds for all GNOME library components). For today's jhbuild results with Intel/64, most one-page plots were fine, but some were bad, In particular x03c.pscairo is incomplete and x24c.pscairo is seriously incomplete (just a smooth white background). (Most multipage plots were bad, but I want to focus on the bad single-page results since that is a simpler situation.) I don't think these bad single-page results are due to some problem with the gv viewer. I have converted x03c.pscairo to EPS form with the perl script ps2eps (which does not depend on gs/gv except to calculate the bounding box), and the EPS form is still missing the same pieces. I have also tried using the ImageMagick convert programme, but that uses gs, and it errors out (which is what I think is happening with gv as well which is just a GUI front-end to gs). Andrew, do you confirm those same bad results for x03c.pscairo and x24c.pscairo for pango 1.18.3...? Hazen, do you confirm good viewing results for those same plots? Your PPC/64 result above is the only 64-bit result that appears to have worked so far which is why I am asking for a specific confirmation. Also, are you viewing with gv or some other viewer? Orion, I understand you also have access to a 64-bit platform so I am most interested in your x03c.pscairo and x24c.pscairo viewing results for that case. 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 Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2007-11-28 18:48:43
|
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. software@raven> 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: software@raven> 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 Plp...@li... 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 Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Andrew R. <and...@us...> - 2007-11-28 21:28:43
|
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. > > software@raven> 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: > > software@raven> 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 |
From: Andrew R. <and...@us...> - 2007-11-28 22:06:18
|
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. > > software@raven> 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: > > software@raven> 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, 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. In the cairo postscript code the string appears on the previous line. Note that in each case the string is one glyph longer than the number of (x,y) pairs in the numarray. This operator only seems to be generated for slanted text. In example 3 the first two shorter commands plot 30 and 60. The longer ones are for 120, 150 etc. Fix this by hand (i.e. adding an extra pair of displacements in) and the postscript will work fine. From the examples it looks like all of the "broken" ones use this xyshow operator. 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. Incidently my older version of cairo produces postscript which does not use the xyshow command, and so the problem does not arise. The old pscairo plots display fine with the new gv/ghostscript. The problems with the old ghostscript are that the old ghostscript does not scale the text correctly, both with old and new pscairo plots. It doesn't complain about the xyshow rangecheck though. Andrew |
From: Alan W. I. <ir...@be...> - 2007-11-29 00:59:37
|
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. >> >> software@raven> 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: >> >> software@raven> 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. software@raven> 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 __________________________ |
From: Andrew R. <and...@us...> - 2007-11-29 16:58:44
|
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 |
From: Alan W. I. <ir...@be...> - 2007-11-30 00:05:23
|
On 2007-11-29 16:33-0000 Andrew Ross wrote: > 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? The "special" definefont pattern contains the line >> definefont pop where the >> is the end of the special dictionary (font) definition. For debian oldstable, this special pattern occurs in examples 6, 7, and 23. For debian testing, this special pattern occurs in examples 7, 23, and 24. >From these differences I think the occurence of this special definefont pattern just depends on what glyphs are missing from the installed fonts on each system. There are some tremendously exotic glyphs demanded by both examples 7 and 23 so it is no surprise those examples occur in both lists. With some work on installing fonts, examples 6 and 24 can be eliminated from the list, but I obviously have not done that perfectly on either system. The special definefont pattern causes no problems for my oldstable gv/gs. It does cause problems (whether I look at sarge results or testing results) for the gs 8.56 on Debian testing. It is interesting that for your later gs, the viewing problems for the special definefont pattern disappear again. I actually could install ghostscript version 8.61.dfsg.1~svn8187-2.1 from Debian unstable, but that has some dependencies (libc6) that are currently incompatible with my mostly Debian testing environment so I will wait to try that out until the libc6 version currently in unstable gets promoted to testing. Meanwhile, I will only bring up the xyshow issue on the cairo 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 __________________________ |
From: Andrew R. <and...@us...> - 2007-11-30 15:17:40
|
On Thu, Nov 29, 2007 at 04:04:37PM -0800, Alan Irwin wrote: > On 2007-11-29 16:33-0000 Andrew Ross wrote: > > > 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? > > The "special" definefont pattern contains the line > > >> definefont pop > > where the >> is the end of the special dictionary (font) definition. > > For debian oldstable, this special pattern occurs in examples 6, 7, and 23. > For debian testing, this special pattern occurs in examples 7, 23, and 24. > Following a recommendation on list I've now got virtualbox installed on a machine so I can run Debian testing without risking upsetting real work. If you haven't tried it - I'd recommend it. It was very easy to set up, seems to work well so far and is really useful for this kind of thing. Anyway, I've installed just the basic desktop setup plus whatever dependencies are required to build the plplot debian packages. I don't see this definefont issue with any of the tests. I think you are right that it must be font related. The only truetype fonts I have are the FreeFonts, dejavu and the openoffice symbol font. Unfortunately from the cairo postscript output it is not possible to see which fonts are acually being used. Andrew |
From: Andrew R. <and...@us...> - 2007-11-30 08:43:54
|
On Thu, Nov 29, 2007 at 04:04:37PM -0800, Alan Irwin wrote: > On 2007-11-29 16:33-0000 Andrew Ross wrote: > > >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? > > The "special" definefont pattern contains the line > > >>definefont pop > > where the >> is the end of the special dictionary (font) definition. > > For debian oldstable, this special pattern occurs in examples 6, 7, and 23. > For debian testing, this special pattern occurs in examples 7, 23, and 24. > > >From these differences I think the occurence of this special definefont > pattern just depends on what glyphs are missing from the installed fonts on > each system. There are some tremendously exotic glyphs demanded by > both examples 7 and 23 so it is no surprise those examples occur in > both lists. With some work on installing fonts, examples 6 and 24 can > be eliminated from the list, but I obviously have not done that perfectly > on either system. > > The special definefont pattern causes no problems for my oldstable gv/gs. > It does cause problems (whether I look at sarge results or testing results) > for the gs 8.56 on Debian testing. > > It is interesting that for your later gs, the viewing problems for the > special definefont pattern disappear again. I actually could install > ghostscript version 8.61.dfsg.1~svn8187-2.1 from Debian unstable, but that > has some dependencies (libc6) that are currently incompatible with my mostly > Debian testing environment so I will wait to try that out until the libc6 > version currently in unstable gets promoted to testing. > > Meanwhile, I will only bring up the xyshow issue on the cairo list. Alan, for now could you send me (off list) on of the images that is producing the problems with definefont. I'll check it out on my recent gs to see if it is gs that has fixed it, or merely down to different cairo versions. Thanks Andrew |
From: Andrew R. <and...@us...> - 2007-11-30 19:47:22
|
On Fri, Nov 30, 2007 at 08:18:17AM +0000, Andrew Ross wrote: > > Alan, for now could you send me (off list) on of the images that is > producing the problems with definefont. I'll check it out on my recent > gs to see if it is gs that has fixed it, or merely down to different > cairo versions. I have now received this from Alan. With Alan's .pscairo file I also get the typecheck error, so as we suspected it is not a ghostscript issue, but a cairo / fonts issue. My experiments with Debian testing worked fine so I conclude it must be a cairo issue which depends on which fonts are installed. Whether it is missing or bad fonts is hard to tell. Andrew |
From: Alan W. I. <ir...@be...> - 2007-11-30 17:02:48
|
On 2007-11-30 14:53-0000 Andrew Ross wrote: > On Thu, Nov 29, 2007 at 04:04:37PM -0800, Alan Irwin wrote: >> The "special" definefont pattern contains the line >> >>>> definefont pop >> >> where the >> is the end of the special dictionary (font) definition. >> >> For debian oldstable, this special pattern occurs in examples 6, 7, and 23. >> For debian testing, this special pattern occurs in examples 7, 23, and 24. >> > > Following a recommendation on list I've now got virtualbox installed on > a machine so I can run Debian testing without risking upsetting real > work. If you haven't tried it - I'd recommend it. It was very easy to > set up, seems to work well so far and is really useful for this kind of > thing. Your comment struck a nerve. My problem is I bought the latest hardware for my new computer to reduce office noise and power costs. That part really worked well, and I am amazed at the power and speed of the new box compared to what I had. However, my new hardware (ASUS P5K-V with Intel g33 chipset) is too close to the cutting edge _at the moment_ to have a comfortable Linux experience. For example, I just finished a successful two-week struggle with keeping X alive on it for my Intel g33 chipset. (The Intel engineers upstream needed to apply a patch that they thought "might" work, but I was their first real tester so they have held off until now.) I have really had to stretch my Linux expertise just to keep this box alive. So I had to smile when you mentioned "without upsetting real work". I will definitely keep the virtualbox idea in mind for the future when I will finally be able to run Debian stable for real work while also running testing and unstable for test purposes. But I suspect that will be more than a year in the future. > > Anyway, I've installed just the basic desktop setup plus whatever > dependencies are required to build the plplot debian packages. I don't > see this definefont issue with any of the tests. Could you clarify some points? Do none of the examples have the special definefont pattern or is the special pattern in one or more of examples 6, 7, 23, and/or 24, but ghostscript accepts it? What version of ghostscript? Are you really running just Debian testing (in which case your experience does not jibe with mine) or is it actually Debian unstable (which has a new version of ghostscript which I cannot install yet on my mostly Debian testing box)? 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2007-12-01 01:35:38
|
On 2007-11-29 16:04-0800 Alan W. Irwin wrote: > Meanwhile, I will only bring up the xyshow issue on the cairo list. When I did more thorough homework on this xyshow issue including looking at the libcairo code, it eventually boiled down to a one-line cairo patch which I submitted to the cairo list. It turned out their PostScript backend guy Adrian Johnson had independently come up with exactly the same one-liner and committed it just a few hours before my post! (See http://lists.cairographics.org/archives/cairo/2007-November/012152.html). It should take a while to propagate this patch to distro releases, but I have tried to speed up this process for Debian (and eventually Ubuntu) with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453718 . Anyhow, except for those propagation delays, this resolves the xyshow issue. That leaves the remaining "/typecheck error for definefont" issue. All my recent PLplot pscairo results have been for the pango-1.16.4/cairo-1.4.6 stack that I built to mimic as closely as possible the results I had for my debian oldstable=sarge system. I have now rebuilt PLplot and pscairo using the much later pango-1.18.3/cairo-1.4.10 that you get by default for Debian testing. For that latest version of PLplot, I get the "special" definefont pattern as follows: software@raven> grep '>> definefont' test/*.pscairo test/x07c.pscairo:>> definefont pop test/x23c.pscairo:>> definefont pop test/x23c.pscairo:>> definefont pop test/x24c.pscairo:>> definefont pop where ">>" is the end of the dictionary (font) definition. For all those examples, I also get the "/typecheck error for definefont" when I use the gv --noquiet command. If I copy those examples to my oldstable box, the gv application plots them without any showstopper errors. However, when looking at the 24th "peace-flag" example, the Korean version of "peace" is replaced by blank. Meanwhile, on the debian testing side c/x24c -dev xcairo produces a good peace flag except for the Korean version of "peace" which is about 1/tenth size. This "Korean" problem also shows up for -dev pngcairo So my mental model of what is going on here is there is some issue with the Korean fonts on my Debian testing system. For -dev xcairo and pngcairo the issue shows up as a "peace" word which is much too small. -dev pscairo tries to handle the problem with the special definefont pattern which has the above signature, but makes some type error in the structure that is set up. Modern gv/ghostscript errors out with a /typecheck error while older gv/ghostscript just produces a blank for this case. Andrew, you have already confirmed part of this mental model when you showed that results generated on my system with the above definefont signature generated the "/typecheck error for definefont" error message for your gutsy version of gv/ghostscript. I can well believe that Ubuntu has been a little more careful about font issues than Debian so it makes sense that Andrew never sees the problem for results generated by him on Ubuntu. However, Andrew, could you specifically confirm that conclusion by looking for the special signature for definefont that I found above? It should not be there for your Ubuntu results, but it should be there for your Debian testing platform results, but I want to be sure this is the case. 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 __________________________ |
From: Andrew R. <and...@us...> - 2007-12-01 08:58:50
|
On Fri, Nov 30, 2007 at 05:35:06PM -0800, Alan Irwin wrote: > On 2007-11-29 16:04-0800 Alan W. Irwin wrote: > > >Meanwhile, I will only bring up the xyshow issue on the cairo list. > > When I did more thorough homework on this xyshow issue including looking at > the libcairo code, it eventually boiled down to a one-line cairo patch which > I submitted to the cairo list. It turned out their PostScript backend guy > Adrian Johnson had independently come up with exactly the same one-liner and > committed it just a few hours before my post! (See > http://lists.cairographics.org/archives/cairo/2007-November/012152.html). > > It should take a while to propagate this patch to distro releases, but I > have > tried to speed up this process for Debian (and eventually Ubuntu) with > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453718 . Anyhow, except > for those propagation delays, this resolves the xyshow issue. Good news. > That leaves the remaining "/typecheck error for definefont" issue. All my > recent PLplot pscairo results have been for the pango-1.16.4/cairo-1.4.6 > stack that I built to mimic as closely as possible the results I had for my > debian oldstable=sarge system. I have now rebuilt PLplot and pscairo using > the much later pango-1.18.3/cairo-1.4.10 that you get by default for Debian > testing. > > For that latest version of PLplot, I get the "special" definefont pattern > as follows: > > software@raven> grep '>> definefont' test/*.pscairo > test/x07c.pscairo:>> definefont pop > test/x23c.pscairo:>> definefont pop > test/x23c.pscairo:>> definefont pop > test/x24c.pscairo:>> definefont pop > > where ">>" is the end of the dictionary (font) definition. For all those > examples, I also get the "/typecheck error for definefont" when I use the gv > --noquiet command. If I copy those examples to my oldstable box, the gv > application plots them without any showstopper errors. However, when > looking > at the 24th "peace-flag" example, the Korean version of "peace" is replaced > by blank. Meanwhile, on the debian testing side c/x24c -dev xcairo produces > a good peace flag except for the Korean version of "peace" which is about > 1/tenth size. This "Korean" problem also shows up for -dev pngcairo > > So my mental model of what is going on here is there is some issue with the > Korean fonts on my Debian testing system. For -dev xcairo and pngcairo the > issue shows up as a "peace" word which is much too small. -dev pscairo tries > to handle the problem with the special definefont pattern which has the > above signature, but makes some type error in the structure that is set up. > Modern gv/ghostscript errors out with a /typecheck error while older > gv/ghostscript just produces a blank for this case. > > Andrew, you have already confirmed part of this mental model when you showed > that results generated on my system with the above definefont signature > generated the "/typecheck error for definefont" error message for your > gutsy version of gv/ghostscript. > > I can well believe that Ubuntu has been a little more careful about font > issues than Debian so it makes sense that Andrew never sees the problem for > results generated by him on Ubuntu. However, Andrew, could you specifically > confirm that conclusion by looking for the special signature for definefont > that I found above? It should not be there for your Ubuntu results, but it > should be there for your Debian testing platform results, but I want to be > sure this is the case. Alan, I can confirm that the special definefont line ">> definefont" does not appear in my Ubuntu generated plots. I do not have access to the debian testing plots here at home to check them I'm afraid. I can confirm that I did not see any errors with gv --noquiet on these plots though. Since the cairo version we are using should be the same, then the only difference I can see is the installed fonts. Andrew |
From: Alan W. I. <ir...@be...> - 2007-12-01 17:01:56
|
On 2007-12-01 08:58-0000 Andrew Ross wrote: > Alan, I can confirm that the special definefont line ">> definefont" > does not appear in my Ubuntu generated plots. I do not have access to the > debian testing plots here at home to check them I'm afraid. > > I can confirm that I did not see any errors with gv --noquiet on these > plots though. Since the cairo version we are using should be the same, > then the only difference I can see is the installed fonts. Thanks for that confirmation of no special definefont for Ubuntu, and I agree with your conclusion about some Debian (but not Ubuntu) problem in installed fonts (or maybe even fontconfig) being the primary source of the trouble, but with the PostScript backend to cairo not responding properly to the font error. In sum, the Debian font problems are giving us an unprecedented opportunity to test little-used paths in the libcairo source code. I have now discovered the source code in libcairo where the special definefont pattern was used. That whole area has just been reworked in git due to some Type 3 font issue. I don't think I have any Type 3 fonts installed, but nevertheless, the code section is now a new special style, and the problem with the old special style may have inadvertently been fixed. My plan is to build a special libcairo with the latest git innovations in PostScript support to see if all the libcairo problems dealing with the bad font issues on Debian go away. If I get success, then this should further motivate the cairo developers to do a quick stable release this month (which they are already tentatively planning because of the xyshow one-liner). If I get failure with the new style, then perhaps Adrian Johnson can figure out a quick fix to that new special style, but we will see. Hazen, do not be discouraged by these issues with libcairo. I will do my best to make sure they are all fixed by doing cairo bug reports, agitating on the cairo list, etc. In my opinion the extremely high quality of the cairo device results make this sort of extra debugging effort worthwhile. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2007-12-02 00:56:07
|
On 2007-12-01 09:01-0800 Alan W. Irwin wrote: > My plan is to build a special libcairo with the latest git innovations in > PostScript support to see if all the libcairo problems dealing with the bad > font issues on Debian go away. If I get success, then this should further > motivate the cairo developers to do a quick stable release this month (which > they are already tentatively planning because of the xyshow one-liner). I got success! See http://lists.cairographics.org/archives/cairo/2007-December/012187.html . I now get good results for all pscairo examples by applying three patches (that are expected to be in the forthcoming cairo-1.4.14) to cairo-1.4.12. So the problem is solved other than the expected delay in propagating these fixes to Linux distributions and elsewhere. Big personal sigh of relief here since I am using pscairo extensively in my research work. 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 __________________________ |