[gs-bugs] [Bug 691588] New: Oversized glyphs with FAPI and antialiasing

[bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=691588

           Summary: Oversized glyphs with FAPI and antialiasing
           Product: Ghostscript
           Version: HEAD
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P4
         Component: Text
        AssignedTo: ken.sharp at artifex.com
        ReportedBy: sags5495 at hotmail.com
         QAContact: gs-bugs at ghostscript.com
   Estimated Hours: 0.0


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.)

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.