| Summary: | Oversized glyphs with FAPI and antialiasing | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | SaGS <sags5495> |
| Component: | Text | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chris.liddell |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Customer: | Word Size: | --- | |
| Attachments: |
Screenshots.
The PS file used to generate the screenshots above. A patch I tried. Screenshot from TRUNK rev 11640. |
||
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).
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).
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.
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). 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?). 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. 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. (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! |
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.)