Bug 140100

Created attachment 61329 [details]
gs 7 on SuSE 9.2 - ok

Created attachment 61330 [details]
gs 7 on SUSE 10.0 - ok

Created attachment 61331 [details]
gs 8.15 on SUSE 10.0 - YUCK

Created attachment 61332 [details]
gs 8.53 on SUSE 10.0 - better, but not ok

Note the vertically squashed "22" in the header, and the artefacts on the "P" and "R".

The problem also exists in vanilla GPL ghostscript 8.15, so it's not caused by ESP ghostscript additions or whatever SUSE did to it.

Hi Volker!
Thanks for reporting this. This might have to do with bug #132624. I'll reassign this. Werner: Please comment about this.

I will NOT switch to a NON-GPL version of ghostscript.
You may provide a patch to the espgs project at www.cups.org,
because this is the version which will be used for the
next update.

I realise it's not a SUSE problem and that SUSE can't ship non-GPL gs. I only reported because Marcus Meissner asked me to.

My examples were also prepared with LaTeX, using the LucidaBright font set from Y&Y. Fonts are embedded in the dvips-generated postscript file. Converting the ps to pdf with gs, also embedding fonts, makes no difference to gs -dDEVICE=x11alpha screen rendering. Likewise when creating the pdf with pdflatex.

Question: does gs use some external library for rendering fonts when using the x11 output device? Neither gs 7.07.1 nor 8.15 appear to be linked with freetype. The fontconfig suggestions in #132624 comment #9 have no effect.

AFAIK gs use its own type of freetype (e.g. see espgs-8.15.2rc1/src/fapi_ft.c).
You may have also a look into the code base of openSuSE, the base for the
next release.

Created attachment 61440 [details]
acroread 7 on SUSE 10.0 - very good

For comparison. PDF created with ghostscript (as from SUSE 10.0) from the PS.

The ghostscript-library-8.15.2rc1-2.x86_64.rpm of openSUSE 10.1 is as bad as the one shipped with 10.0.

Hmmm ... the best readable output is IMHO attachment (id=61331)
followed by attachment (id=61440).

Ok so subsample rendering is in the eye of the beholder. However, if you want things to look like attachment (id=61331) gs 8.51, the trivial solution at any time is to turn antialias off in gv/etc., because that's exactly the same. Obviously the vanilla ghostscript people have recognised this problem, because antialias has an effect again in gs 8.53. Unfortunately, we can't see 8.53 in ESP or SUSE for at least another year, so the hole situation is very diabolical, not made easier by the fact that distros need espgs instead of gs, and espgs would have no interest in screen rendering. In short, it all sucks. :(

I've put a report with ESP at http://www.cups.org/str.php?L1363

Please try out

    gs /usr/share/ghostscript/8.15/examples/alphabet.ps

and

    gs -sDEVICE=x11alpha /usr/share/ghostscript/8.15/examples/alphabet.ps

it seems at least there here the last example shows anti-aliased
fonts even for esp gs 8.15.  If you've an short example which does
not show anti-aliasing, please attach this.

I'm now build ghostscript 8.15 with freetype library support
which may help to make the TrueType font work better.  With
this now we have the -dGridFitTT= option available.  Beside
this the
 <file:///usr/share/ghostscript/8.15/doc/Use.htm#Rendering_parameters>
explains that -dAlignToPixels=0 may help for bad hinted fonts,
IMHO TeX fonts are bad hinted fonts, but make well hinted fonts
more worse.

That library won't do anything for type1 fonts, which is what has been used so far. I don't see any use in truetype, qt can't even create a postscript file with them - it turns the font into a junkyard of curves, which in turn gets turned into type3 = bitmap fonts in a pdf when you convert the ps to pdf. This happens from KDE apps as well as from OpenOffice's print to pdf. OO's export to pdf is less than useful, as its output makes every second viewer barf.

If a set of expensive type1 fonts, as well as every second other font, display well in gs7 and acroread, but shockingly in gs8, then I put the fault with gs8.

The -dAlignToPixels=0 does indeed help a lot with gs 8.15rc1, but doesn't really improve gs 8.53 (commercial Lucida font). In either case, the artefacts on the P and R are still there. It's usable, but not as good as gs 7, mainly because the output from gs 7 is a little heavier.

Testing with alphabet.ps yields the information that the rendering quality is font dependent. I reduced its start font size from 15 to 10, we know everything works at huge sizes. Palatino works fine in gs 8.15, Courier is shocking. The result of viewing a pdf created by ps2pdf13(gs7) and ps2pdf13(gs8) are not the same, font embedded both times, same viewer. Viewing the alphabet.ps or a pdf of it which doesn't have the Courier embedded gives a rubbish result, which suggests that the font used by the viewer isn't the same as the one embedded in the pdf? I had before renamed my directory with local fonts and re-run SuSEconfig and fonts-config -f (the claim that SuSEconfig includes fonts-config when necessary isn't true, at least not always), so only SuSE-shipped fonts should be available. None of it really looks any better than my previous examples, but I can upload similar screenshots as before if someone would find them useful.

I know that the freetype library is usefull for TrueType's only ;)

I'll attach some screenshots using Courier. See last paragraph of #17 for details. I had to go via pdf to ensure font embedding for reproducible results. The embedded Courier is either whatever comes with gs8.x, or what Y&Y shipped in the ATM (Adobe type manager) part of their Lucida fonts.

The acroread and gs 7 results are fine. The gs 8.15 is plain shocking and illegible. The gs 8.53 is better but still not much use.

Created attachment 61772 [details]
Courier - acroread 7 - good

Created attachment 61773 [details]
Courier - gs 7.07.1 - good

Created attachment 61774 [details]
Courier - esp gs 8.15 - illegible

Created attachment 61775 [details]
Courier - vanilla gs 8.53 - still not much use

Created attachment 61776 [details]
Courier - the file viewed for the previous 4 attachments

At large enough magnification this file views ok, but not at smaller ones.