Bug 691588 - Oversized glyphs with FAPI and antialiasing
Summary: Oversized glyphs with FAPI and antialiasing
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Text (show other bugs)
Version: master
Hardware: PC Windows XP
: P4 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-02 13:35 UTC by SaGS
Modified: 2010-09-09 12:07 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
Screenshots. (129.86 KB, image/png)
2010-09-02 13:39 UTC, SaGS
Details
The PS file used to generate the screenshots above. (152.46 KB, application/postscript)
2010-09-02 13:41 UTC, SaGS
Details
A patch I tried. (1.28 KB, patch)
2010-09-02 13:42 UTC, SaGS
Details | Diff
Screenshot from TRUNK rev 11640. (34.57 KB, image/png)
2010-09-08 06:11 UTC, SaGS
Details

Note You need to log in before you can comment on or make changes to this bug.
Description SaGS 2010-09-02 13:35:51 UTC
Large enough glyphs are displayed much too large if TextAlphaBits > 1 
and Ghostscript is compiled with FT_BRIDGE=1 (the default). Also, even 
larger glyphs are the correct size, but are not antialiased.

The effect depends on output resolution, the larger the resolution the 
smaller the point size that is affected. The screenshots below are made 
at 72dpi; at 96dpi the 36pt glyphs (not unusual for a drop cap) are 
already affected. It appears the affected glyphs are those that don’t fit 
into the font cache, see the 4th screen capture. Passing ‘-dDisableFAPI’ 
everything is OK - antialiased and correctly sized glyphs (5th screenshot).

The 1st time I saw this bug I searched the past svn versions to see 
where does it come from. That file was OK in rev 11633 but not in 11634.
However, I think this happened then and not before because of the 
char_bbox increase (see ‘/* We must use the FontBBox ...’), reducing 
the point size where glyphs don’t fit the cache anymore. With 
‘Cambria Math’ I saw the 2x glyph sizes for 12pt @ 96dpi, possibly 
caused by this font having a large font bbox (math chars are big...).

I did not have such problems with the previous Ghostscript release.

However, I don’t think it’s rev 11634 that introduced the regression. 
The code in psi\zfapi.c::fapi_image_uncached_glyph() under 
‘if (gs_color_writes_pure(pgs)) { ... }’ is inherited from ancient 
code, and from what I can tell this code receives 2x and maybe 4x 
rasters but does not look at ‘penum->fapi_log2_scale’ to scale them 
down. I think this never worked properly, but it’s seen now because of 
the switch to FreeType and some other factors that reduced the point 
size/ resolution that trigger the bug. (But, maybe the old code did 
never receive 2x or 4x rasters, I cannot tell for sure.)
Comment 1 SaGS 2010-09-02 13:39:55 UTC
Created attachment 6693 [details]
Screenshots.

Command options are written in red for each of them. Notice the 1st 
(without antialiasing) and last (FAPI disabled) are OK. The 72pt chars 
in screenshots #2..#4 are the correct size but not antialiased, while 
they are with FAPI disabled (#5).
Comment 2 SaGS 2010-09-02 13:41:26 UTC
Created attachment 6694 [details]
The PS file used to generate the screenshots above.

I attach it here just in case. However, a simple ‘/Times-Roman <n> 
selectfont (@) show’ with -dTextAlptaBits=2 or 4 will show the problem, 
depending on resolution and point size (for example 180pt @ 48dpi, 
96pt @ 96dpi, 72pt @ 120dpi, 32pt @ 300dpi are all 2x; strange, I never 
saw a 4x).
Comment 3 SaGS 2010-09-02 13:42:47 UTC
Created attachment 6695 [details]
A patch I tried.

This cures the oversized glyphs. It’s better than nothing, but I don’t 
like it because (a) glyphs are still not antialised, (b) they look ugly 
when downscaled and (c) I feel it merely treats a symptom than fix the 
real cause.
Comment 4 Chris Liddell (chrisl) 2010-09-07 21:52:06 UTC
I opted for a solution which sorted out the anti-aliasing. This is fixed in revision 11690 (it did cause a build issue which gave rise to revisions 11691 and 11692).
Comment 5 SaGS 2010-09-08 06:11:26 UTC
Created attachment 6704 [details]
Screenshot from TRUNK rev 11640.

With current TRUNK the file does not look right either. Attached screenshot 
is from rev 11640 with FT_BRIDGE=1; commandline options are just 
"-r72 -dTextAlphaBits=4" using the sample from comment #2.

- Most glyphs are severely distorted.
- The 72pt ones are OK, but still not antialiased (this is a minor issue 
  compared to the other one).

I tried similarly-created files for all latin fonts that come with 
WinXP-SP3 plus Symbol/ Wingdings/ Webdings (list fpr WinXP-SP2 found at 
<http://www.microsoft.com/typography/fonts/product.aspx?PID=145>, exclude 
non-latin fonts, I do not have those installed), and I got those 
severely distorted glyphs in all cases. Reopening the bug (or maybe I 
should open another one?).
Comment 6 Chris Liddell (chrisl) 2010-09-08 08:35:34 UTC
It seems to be to do with the order of calculation/assignment/promotion operations differing on gcc vs MSVC. It appears that gcc promotes the variable type early, before any calculations, whilst MSVC does the calculation before the promotion. In this case, it's promotion of a 32 to a 64 bit variable, with a left shift to raise the variable to a 32.32 fixed point form - MSVC was losing the most significant bits.

Fix is in: r11695 - but given what happened the last time, I'm going to leave the bug open until SaGS has a chance to test this.
Comment 7 SaGS 2010-09-08 12:14:49 UTC
In general there are still issues with FreeType versus internal GS font scaler (antialiased text is much worse with FreeType at small point sizes due to bad glyph shapes, and advance widths vary up to the point that we have 1 char more or less on a line depending on the resolution), but I don’t consider these belong here. From what I see glyphs are not 2x anymore, and they are smoothed, so I’m going to close this bug. For the other issues, maybe another time, in another bug report.
Comment 8 Chris Liddell (chrisl) 2010-09-09 12:07:26 UTC
(In reply to comment #7)
> In general there are still issues with FreeType versus internal GS font scaler
> (antialiased text is much worse with FreeType at small point sizes due to bad
> glyph shapes, and advance widths vary up to the point that we have 1 char more
> or less on a line depending on the resolution), but I don’t consider these
> belong here. From what I see glyphs are not 2x anymore, and they are smoothed,
> so I’m going to close this bug. For the other issues, maybe another time, in
> another bug report.

If you want to try the current head revision, it might be closer to the kind of output you expect.

If there are still spacing problems, can you raise a bug and put a sample file and command line to recreate - I've got an idea how to improve the accuracy of metrics we get from Freetype which might help, and a bug report will make sure I remember to test the anti-alias case.

Thanks!