Ghostscript 8.x's X11 antialiasing produces bad artefacts at small font sizes with many fonts. With ESP Ghostscript 8.15.0 (rc1) it makes the result absolutely illegible. With AFPL Ghostscript 8.53 (2005-10-20) it is much better, but still not good. With ESP Ghostscript 7.07.1 (2003-07-12) there simply wasn't any problem. It mighn't have been the same as acroread, but it was very good with no artefacts. Rendering with -sDEVICE=x11alpha. Although antialiasing may have a component of personal preference, the output of gs 8.x is bad, and the problem is *not* fixed. Examples using two different fonts are here: https://bugzilla.novell.com/show_bug.cgi?id=140100 I happened to start the bug reporting there, please let me know if you'd like me to transfer everything to bugs.ghostscript.com. (Also at http://www.cups.org/str.php?L1363) There is no difference in X11 rendering between AFPL and ESP ghostscript (easysw wouldn't be interested in screen rendering). Examples: Font: LucidaBright from Y&Y, dvips-generated postscript, type1 font: gs 8.15 SUSE 10.0 - illegible (note header artefacts): https://bugzilla.novell.com/attachment.cgi?id=61331&action=view as above, gs 7 - no problems: https://bugzilla.novell.com/attachment.cgi?id=61330&action=view AFPL gs 8.53 - note header artefacts: https://bugzilla.novell.com/attachment.cgi?id=61332&action=view Font: Courier, pdf created with ps2pdf13, embedded: pdf: https://bugzilla.novell.com/attachment.cgi?id=61776&action=view esp gs 8.15 - illegible: https://bugzilla.novell.com/attachment.cgi?id=61774&action=view afpl gs 8.53 - still not much use: https://bugzilla.novell.com/attachment.cgi?id=61775&action=view gs 7 - no problems: https://bugzilla.novell.com/attachment.cgi?id=61773&action=view
Please attach here a copy of the font.
Please clarify - do you mean a copy of the png's, or the font pfb's? If the latter, which one(s)?
I mean pfb of both fonts.
The LucidaBright font set is now available from http://www.tug.org/store/lucida/index.html As they're a commercial font I am not at liberty to attach a copy. If you ask, perhaps they would consider sending you one of the pfb for debugging. I can prepare a pdf sample page for you of course. The "Courier" is tricky for me. How do I find out which pfb went into the pdf? The alphabet.ps only calls "Courier" - which file is actually inserted by ghostscript (ps2pdf13 -dPDFSETTINGS=/printer, to force embedding) into the pdf? This is on a very recent Linux system. Ok it's probably this: > strace -ff -eopen ps2pdf13 -dPDFSETTINGS=/printer alphabet.ps 815.pdf | & grep font | grep -v ' -1 ENOENT' PrivoxyWindowOpen("/usr/share/ghostscript/8.15/lib/gs_fonts.ps", O_RDONLY) = 4 PrivoxyWindowOpen("/usr/share/ghostscript/8.15/lib/pdf_font.ps", O_RDONLY) = 4 PrivoxyWindowOpen("/usr/share/ghostscript/fonts/n022003l.pfb", O_RDONLY) = 9 PrivoxyWindowOpen("/usr/share/ghostscript/fonts/n022003l.pfb", O_RDONLY) = 9 96263 2002-12-26 09:39:34 /usr/share/ghostscript/fonts/n022003l.pfb Which would be NimbusMonL-Regu. There isn't much point in attaching that.
Well, as I know, font vendors allow to embed font subsets into documents and then copy the documents to other people. So please run Ghostscript converting your samples into PDFs and then attach PDFs to here. After that you may make the attachment "private" (with clicking "edit' in the attachment table) so as nobody besides Artifex can copy it. Here is command line : gs -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite - sOutputFile=alphabet.pdf -c mark /EmbedAllFonts true /NeverEmbed [false /Courier] .dicttomark setdistillerparams -f alphabet.ps gs -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite -sOutputFile=815f.pdf -c mark /EmbedAllFonts true /NeverEmbed [false /Courier] .dicttomark setdistillerparams -f 815.pdf Please don't mix both cases in a single document, run Ghostscript 2 times.
Here's the alphabet.ps I have used: --- /usr/share/ghostscript/8.15/examples/alphabet.ps 2005-09-13 11:25:14.0000 00000 +1200 +++ alphabet.ps 2005-12-23 09:41:54.000000000 +1300 @@ -4,8 +4,12 @@ /alphabetsave save def % prevent left over effects +%/FontName (Courier-Italic) def +/FontName (Courier) def +%/FontName (Times) def + /FontName where { pop } { /FontName (Palatino-Italic) def } ifelse -/FirstSize where { pop } { /FirstSize 15 def } ifelse +/FirstSize where { pop } { /FirstSize 10 def } ifelse /Ratio where { pop } { /Ratio 1.6 def } ifelse /NumSizes where { pop } { /NumSizes 3 def } ifelse /UseOutline where { pop } { /UseOutline false def } ifelse @@ -36,6 +40,7 @@ ifelse grestore } def +0 10 translate FontName findfont FirstSize scalefont setfont clippath pathbbox /top exch def pop pop pop newpath
The .pdf with the Courier font was already attached in the original bug description. Here again: > gs -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite -sOutputFile=alphabet-espgs8.15.pdf -c mark /EmbedAllFonts true /NeverEmbed '[false /Courier]' .dicttomark setdistillerparams -f ../alphabet.ps ESP Ghostscript 8.15 (2004-09-22) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Loading NimbusMonL-Regu font from /usr/share/ghostscript/fonts/n022003l.pfb... 3777600 2025520 1525176 228851 1 done. I checked again just now that this alphabet-espgs8.15.pdf shows the problems.
Created attachment 1959 [details] alphabet.ps -> PDF, ESP gs 8.15
> gs8 gs -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite -sOutputFile=alphabet-gs8.53.pdf -c mark /EmbedAllFonts true /NeverEmbed '[false /Courier]' .dicttomark setdistillerparams -f ../alphabet.ps AFPL Ghostscript 8.53 (2005-10-20) Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading NimbusMonL-Regu font from /usr/share/ghostscript/fonts/n022003l.pfb... 3690680 1912470 1517904 223096 1 done.
Created attachment 1960 [details] alphabet.ps -> PDF, AFPL gs 8.53
Not sure what the 2nd gs command in comment #5 is all about, but you're the expert. > gs -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite -sOutputFile=alphabet-espgs8.15f.pdf -c mark /EmbedAllFonts true /NeverEmbed '[false /Courier]' .dicttomark setdistillerparams -f alphabet-espgs8.15.pdf ESP Ghostscript 8.15 (2004-09-22) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Processing pages 1 through 1. Page 1
Created attachment 1961 [details] alphabet-espgs8.pdf -> PDF, ESP gs 8.15
The Y&Y LucidaBright fonts allow distribution of PDFs containing them if fonts are subsetted, so no problem. > gs -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite -sOutputFile=lucidabright-espgs8.15.pdf -c mark /EmbedAllFonts true /NeverEmbed '[false /Courier]' .dicttomark setdistillerparams -f lucidabright.ps ESP Ghostscript 8.15 (2004-09-22) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. > gs8 gs -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite -sOutputFile=lucidabright-gs8.53.pdf -c mark /EmbedAllFonts true /NeverEmbed '[false /Courier]' .dicttomark setdistillerparams -f lucidabright.ps AFPL Ghostscript 8.53 (2005-10-20) Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details.
Created attachment 1962 [details] dvips -> PDF, ESP gs 8.15
Created attachment 1963 [details] dvips -> PDF, AFPL gs 8.53
Created attachment 1964 [details] a hinter patch (not for this problem) Thanks for test data. I'll work on them soon. In the meantime please try the patch I attach here. This patch is for another problem, but it changes the rendering in many cases. If your problem is occasionally gone, it would be a pleasure.
The patch doesn't apply on unix platforms (can't find file to patch), but I knocked it into shape. With AFPL gs 8.53 and the hinter patch applied, I can see no difference in rendering of the LucidaBright fonts when compared with the same gs without this patch. Perhaps I didn't look hard enough?
Created attachment 1998 [details] patch.txt The last patch has problems, attaching an improved one.
Dear Volker Kuhlmann, At last I've got some time to work on your problem. Sorry for delay. First I should state that I can't reproduce your raster exactly. The main problem is that it depends on your display resolution and on the window placement. With some measurements I guess your display resolution is 82 dpi, but I would very appreciate if you check it for sure. To exclude any unreproducible noize plese run a command like this : gs -r82 -dTextAlphaBits=4 -dNOPAUSE -dNOOUTERSAVE -dBATCH -sDEVICE=ppmraw - sOutputFile=cur.raw "alphabet-ps2pdf13-gs8[1].15rc1.pdf" You may use a different Ghostscript device, which writes the image to file with no distorsions. Then view it (again with no distorsions) and check whether it reproduces your problem, and attach to here. Second, I assume that uoy use an LCD display. If you use CRT, I'm in doubts wthether we should spend a time for it, because CRTs are almost gone. They usually have a hexagonal pitch, which gives a different view. Third, comparing your rasters "pdfgs8-courier-gs7[1].07.1-x11alpha.png" "pdfgs8-courier-gs8[1].53-x11alpha.png", I can't make an obvious conclusion why do you consider one worse and another one better. For example, characters 'l', 'L' look worse in the gs7 raster : they're less contrast than others, and the contrast appears varying. 'D' Appears more curve with gs8, and so forth. IMO a guessing won't give us an useful result, so please explain detailedly, why do you think 8.53 is worse. Besides that, please note that I attached a new patch, which will go to production soon. gs8.53 and the current HEAD contains a hinter bug, which is important with anisitropic rendering. Speaking correctly, gs8.53 gives an wrong raster on anisotropic devices. If your display has different dot per inch values by X and Y, the patched code will give a very different raster.
The Type 1 hinter has been significantly changed with the patch http://ghostscript.com/pipermail/gs-cvs/2006-February/006347.html The new revision is 6585. We're not planning any improvement to older revisions. Please update Ghostscript and check whether the problem persists in the new revision. Please provide reproducible test data how explained in Comment # 19.
We committed a big improvement to Type 1 hinter for bug 688552 and bug 688553 : http://ghostscript.com/pipermail/gs-cvs/2006-February/006347.html http://ghostscript.com/pipermail/gs-cvs/2006-February/006358.html Now we considfer the old hinter an obsolete product. We close this bug with 'wontfix' due to several reasons : 1. It relates to an obsolete Ghostscript revision; 2. It doesn't provide enough data for reproduction. 3. It doesn't explain the problem clearly. Dear Volker Kuhlmann, If you can reproduce the problem with new revision, please open a new bug and provide a better explanation and full test data to allow us to reproduce the effect. See comment #19 for more information.
Many apologies for not yet replying to #19 and #20, but perhaps just as well. I will try out gs 8.53 with the two patches you mention and open a new bug if the problem persists. Many thanks for looking at this!