Bugzilla – Bug 132624
Fonts in TeX output look ugly in ghostview
Last modified: 2005-12-21 20:13:00 UTC
Self-compiled TeX files look ugly on the screen (in gv/ghostview/kghostview) when using the standard CM fonts (with the standard ghostscript-, gv-, and dvips-installation under SuSE 10.0). Printed copies (on postscript printers, and dvi files on the screen) look way better, anti-aliasing is turned on. The entries in /usr/share/ghostscript/8.15/lib/Fontmap.GS seem to be correct; for testing purposes, I added /CMR8 (cm/cmr8.pfb) ; /CMR12 (cm/cmr12.pfb) ; /CMEX10 (cm/cmex10.pfb) ; to this file (these are fonts which are used in most self-compiled TeX files) and linked /usr/share/ghostscript/8.15/fonts/cm/ to /usr/share/texmf/fonts/type1/bluesky/cm/ , where the type 1 cm-fonts are located; but still no improvement. The installed font packages are: > rpm -qa | grep fonts ghostscript-fonts-other-8.15rc1-29 xorg-x11-fonts-scalable-6.8.2-100 agfa-fonts-2003.03.19-15 fonts-config-20041001-9 ec-fonts-mftraced-1.0.12-2 ghostscript-fonts-std-8.15rc1-29 xorg-x11-fonts-75dpi-6.8.2-100 dejavu-fonts-ttf-1.15-1.guru.suse100 The command used to convert dvi to ps is dvips -o output.ps input.dvi. The result used to be much better with SuSE 9.2.
Hello! I've compiled a TeX-document of my own and tried to verify what you wrote. The result can be seen on the two attached screenshots. At first, I compiled the dvi, then converted it to PostScript using `dvips', also I converted it into a pdf using `pdfm'. I could not verify what you said, all the fonts are scaling fine. The ciphers to not look 100% perfect in kghostview, this is probably because this software uses some own anti-aliasing-algorithm. Check if it is switched on. You could also attach screenshots here, this makes comparison way easier. Thanks.
Created attachment 56679 [details] PS viewed with kghostview (anti-aliasing enabled).
Created attachment 56680 [details] Converted into a PDF with dvipdfm, viewed with Acroread.
Created attachment 56685 [details] PS viewed with gv (kghostview looks similar), anti-aliasing enabled It seems that with a scaling factor of 2.0 and higher, the output is acceptable, but I tend to read files at a lower scaling (here 1.0). The output of dvipdfm looks way better.
Created attachment 56686 [details] Converted into a PDF with dvipdfm, viewed with Acroread, much better
I'm taking some people into CC. In my opinion, it looks quite acceptable. Anti-aliasing always tends to do bad things with small fonts... Werner: Please comment this.
I know that anti-aliasing can cause problems on small fonts and also there are fonts which are worse with anti-aliasing enabled. But I agree it looks acceptable. Btw: There is _no_ way to fix this. It is a systematical problem with anti-aliasing and/or monitors with a low resolution. And it goes worse with the LCD out there because most of the LCD's have lower resolution as CTR's. And if Acroread is better then a) the anti-aliasing is disabled and/or b) Acroread uses other fonts.
Created attachment 56694 [details] PS viewed with gv (kghostview looks similar), anti-aliasing disabled My screen resolution is 1400x1050 (104x98 dpi). Somehow, the same files looked much better with SuSE 9.2 (might this be due to ghostscript 7.07 => 8.15?). So, if this is impossible with 10.0, is there a way to change the ghostscript configuration such that it uses the same fonts as acroread? With antialiasing turned off, the result looks even worse.
This has nothing todo with the ghostscript version. What have changed is the freetype version aka package freetype2. Btw: you should always try to get the same screen resolution in horicontal and vertical direction. This can be done by using the `DisplaySize' option in /etc/X11/xorg.conf. Maybe this is the reason why we do not see this here around. Beside this an entry like <match target="font"> <edit name="autohint" mode="assign"> <const>false</const> </edit> </match> <match target="font"> <test name="pixelsize" compare="more_eq"> <double>10</double> </test> <edit name="antialias" mode="assign"> <bool>true</bool> </edit> </match> <match target="font"> <edit name="hintstyle" mode="assign"> <const>hintfull</const> </edit> </match> in your personal ~/.fonts.conf may help. This disables the autohinter and uses the standard hinter for anti-aliasing. More and other possiblities can be found in /usr/share/doc/packages/fontconfig/fontconfig-user.txt
Re comment #7: This is not a systematic problem with anti-aliasing. It was fine on gs 7. I have recompiled the gs 7 from SUSE 9.2 on SUSE 10.0, and the problem magically disappears. Re comment #9: Unless ghostscript is linked with freetype, which it doesn't appear to be in either SUSE 9.2 or 10.0, this has everything to do with the gs version! Also see #140100
Thanks for testing this! Is it perhaps possible that you make the recompiled gs 7 rpms available publicly (since many dependencies have to be met and I was having problems to find SuSE 10 versions of all packages - in principle I could resort to older ones)? And perhaps ghostscript 7 could be distributed with SuSE 10.1 (as an alternative choice for users who don't need ghostscript 8)?
There will be no ghostscript 7. Sorry, but two huge packages with all patches and fixes reqiured are to much effort and to much amount of disk space. Beside this the cusp and most modern printers requires ESP Ghostscript 8.15. anyway the anti-aliased method seems to be very user specific, we had also reports on ghostscript 7 of users which do not like the grey borders around the characters as seen in attachment (id=61329) but prefere clear and black characters as seen in attachment (id=61331).
I would nevertheless be interested in the 7.07 rpms (also the version you compiled, Volker) if that is possible. BTW, I asked several (about a dozen) people here at work, and _all_ prefer the ghostscript 7 rendering (at least on my display), but I agree that this is a matter of taste and whom you ask.
It is a right PITA to need 2 gs versions! Let's fall back on "third party suppliers"... I've put my first attempt of a spec file at http://volker.dnsalias.net/soft/rpm/suse10.0/ no rpms, but the software goes. The plan is to finish it later. Also see bug #140100 comment #13.