I sent the following in December, referring to 8.11. However, it's still the case with 8.14. Nobody has any ideas? -- start included message -- I just looked at upgrading to ghostscript 8.11, but have been put off by the much poorer display on screen (using either gv, or plain gs with the x11alpha device). My test document is set in Palatino, which gets rendered with PalladioL; under 7.04, the anti-aliased rendering is fairly smooth and evenly weighted, but in 8.11 it appears uneven, and there are severe differences in the heights of letters: for example, in the small caps word PHONOLOGY, in 8.11 the O's are a whole screen pixel shorter than the other letters, although they should if anything be taller. But this is just an example; the general appearance is much worse. -- end included message --
We've (Igor) recently made some improvements/fixes in the gs8.1x code and are getting ready to do an 8.15 release (once we are sure we have a good set of fixes). Please try the GS_8_1X branch of the cvs.ghostscript.com:/cvs/ghostscript root to see if that fixes your issue, and if so, please post a follow-up to the bug. The bug tracker entry is at: http://bugs.ghostscript.com/show_bug.cgi?id=687419 The list of other similar bugs is: 686858 Wrong overshoots with -dTextAlphaBits=4 -dAlignToPixels=0 686940 AlignToPixels=0 is ignored with -dNOCACHE 687318 A poor TT grid fitting with TextAlphaBits>1 687332 An StdHW, StdVW reconstruction is necesseary for TT grid ... 687376 text rendering in 8.14 poorer than in 7.x in small sizes Note that I observed much better quality with -dAlignToPixels=0 which is the default with -dTextAlphaBits>1 after 8.14. Also, if this issue is not closed by the GS_8_1X patches, you will have to post a test file, a command line and the results from executing the following: gs -c matrix currentmatrix == quit This will tell us the actual effective resolution of your X display.
Created attachment 618 [details] Page demonstrating problem reported in the bug This page (copyright, but hopefully reproducible under fair use for this purpose) demonstrates the problem reported. If gs is invoked with gs -sDEVICE=x11alpha be56.ps on the X display detailed below, the rendition is poor. For example, the small caps word PHONOLOGY in the fourth line of text. Adding options such as -dTextAlphaBits=4 or -dAlignToPixels=0 does not solve the problem. The output of gs -c matrix currentmatrix == quit is AFPL Ghostscript 8.14 (2004-02-20) Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. [1.04049635 0.0 0.0 -1.04049635 0.0 824.0] The screen is dimensions: 1400x1050 pixels (474x356 millimeters) resolution: 75x75 dots per inch at depth 16.
This problem can be reproduced on Windows. With gs8.00, the characters are much better (heights are more consistent). With gs8.14 and with HEAD, the heights of characters are not consistent. The command line I used was: gswin32c -r74.91573 -sOutputFile=o.png -sDEVICE=pnggray -dTextAlphaBits=4 -dAlignToPixels=0 -dNOPAUSE -dBATCH 687419.ps I am assigning this to Igor Melichev since he has made most of the changes to the font rendering. I've also attached the output from gs8.00 (gs800.png) and gs8.14 (gs814.png).
Created attachment 672 [details] Output from gs 8.00 that looks fairly good
Created attachment 673 [details] Output from gs 8.14 that shows bad character appearance
Well, I analized what happens in there. With AlignToPixels 0 the baseline isn't aligned to pixels. Due to that, since the upper and lower horizontal stems are being aligned independently, the glyph height may vary in +- 1 pixel. This is what we observe. This effect is a strong consequence of the attempt to render a raster image maximaly close to the vector image coordinates. Actually there exist 2 requirements, which contradict each another : 1. A maximal precision of coordinates 2. An uniform glyph size. Likely (some) users want to drop (1) when it appears inconsistent with (2), at least by the Y axis. Since (1) comes from Raph, I'd like to know his opinion first.
Ray and I spent some time looking at this issue. The core problem is that the p052003l.pfb font file has a serious problem with overlapping hints. For example, the 'L' has an HStem at -3/42 (the main horizontal stroke), and another hint at 0/20 (the coordinates of the serif at the lower left corner). In this particular font, the majority of letters seem to have an overlapping hints. Ray also tested with the Adobe Palatino, and the problem of the bouncing baseline and x-height line went away. Any file will show this problem, with any output device and TextAlphaBits=4 set. For example: /Palatino findfont 12 scalefont setfont 36 36 moveto (THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG'S BACK) show showpage I think there are three courses of action to resolve the problem. First, deal with overlapping hints better. However, this may not be trivial, as I'm not sure there's an easy, reliable way to determine which set of hints to discard in the case of overlap. Second, I think it makes sense to have an option that just applies the grid fitting at the supersample resolution, and no additional logic (this is what many users would expect AlignToPixels=0 to do, given the name). With this option, results would be comparable to earlier versions of GS, but with improved subpixel positioning. Given that I think there will always be some fonts with broken hints and/or poor hinted rendering, I think this would be a useful feature even if this file got broken. Lastly, we should fix the URW fonts. While it may be hard to automatically determine which overlapping hint to discard, it is quite reasonable to do so manually.
Raph, Please know that the new hinter includes an algorithm for resolving overlaping hints. It works fine with L from p052003l.pfb . However the new hinter doesn't apply the hint 0/20 to the pole 21 due to inacceptable tangents : the incoming tangent 0.516 appears too big. If this hint to be applied, the threshold in t1_hinter__is_small_angle to be increased to 0.6 or bigger (but not greater than 1). (When I said "the hinter works fine", I assumed the increased threshold). As to your "second", what do you think about rounding the baseline to pixels ? It would fix the glyph height problem pretty simple. The interval betveen text lines won't be perfect, but it can't be perfect in any case. Please note that a grid fitting to any supersamples without rounding the origin can't resolve the size problem. The thinner raster the smaller probability of the problem, but the probability isn't zero for any finite resolution. Really I can prove the theorem : with no origin rounding, for any untrivial unifont text with >=2 lines, for any supersampling (i.e. for any TextAlphaBits > 1), there exists a resolution (a real value for -r switch), which displays the glyph size problem (i.e. the 2 lines look of a different height). Thus what you propose is to decrease the probability of the problem. Rounding the origin, the problem resolves complitely. I suggest to round by Y and don't round by X - it should be a pretty useful compromise.
Created attachment 712 [details] A suggested patch The suggested patch fixes the problem. A minor glyph height variation still persist in the header line of the test document due to the font doesn't define an upper alignment zone for lowercase.
Created attachment 713 [details] A suggested patch (improved) The suggested patch fixes the problem. A minor glyph height variation still persist in the header line of the test document due to the font doesn't define an upper alignment zone for lowercase.
Patches http://www.ghostscript.com/pipermail/gs-cvs/2004-June/004544.html http://www.ghostscript.com/pipermail/gs-cvs/2004-June/004545.html
Patch to GS_8_1X : http://www.ghostscript.com/pipermail/gs-cvs/2004-June/004563.html