Bug 687419 - poor font rendering on X11 with gs 8.14
Summary: poor font rendering on X11 with gs 8.14
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: 8.14
Hardware: All All
: P2 major
Assignee: Igor Melichev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-12 11:26 UTC by Ray Johnston
Modified: 2008-12-19 08:31 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Page demonstrating problem reported in the bug (179.33 KB, application/postscript)
2004-04-12 13:36 UTC, Julian Bradfield
Details
Output from gs 8.00 that looks fairly good (25.80 KB, image/png)
2004-05-18 21:16 UTC, Ray Johnston
Details
Output from gs 8.14 that shows bad character appearance (38.42 KB, image/png)
2004-05-18 21:17 UTC, Ray Johnston
Details
A suggested patch (12.57 KB, patch)
2004-06-08 11:16 UTC, Igor Melichev
Details | Diff
A suggested patch (improved) (13.59 KB, patch)
2004-06-08 12:26 UTC, Igor Melichev
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ray Johnston 2004-04-12 11:26:35 UTC
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 --
Comment 1 Ray Johnston 2004-04-12 11:45:25 UTC
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.
Comment 2 Julian Bradfield 2004-04-12 13:36:52 UTC
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.
Comment 3 Ray Johnston 2004-05-18 21:15:10 UTC
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).
Comment 4 Ray Johnston 2004-05-18 21:16:33 UTC
Created attachment 672 [details]
Output from gs 8.00 that looks fairly good
Comment 5 Ray Johnston 2004-05-18 21:17:43 UTC
Created attachment 673 [details]
Output from gs 8.14 that shows bad character appearance
Comment 6 Igor Melichev 2004-05-24 12:37:34 UTC
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.


Comment 7 Raph Levien 2004-05-24 17:44:45 UTC
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.
Comment 8 Igor Melichev 2004-05-25 02:04:04 UTC
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.



Comment 9 Igor Melichev 2004-06-08 11:16:59 UTC
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.
Comment 10 Igor Melichev 2004-06-08 12:26:10 UTC
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.
Comment 12 Igor Melichev 2004-06-23 01:41:19 UTC
Patch to GS_8_1X :
http://www.ghostscript.com/pipermail/gs-cvs/2004-June/004563.html