Re: [ft-devel] Rendering artifacts

[malc]

On Mon, 26 Jul 2010, Werner LEMBERG wrote:

> 
> > Not sure whether this is a bug, known limitation or something else
> > entirely,
> 
> It's something completely different...
> 
> > but here goes:
> > 
> > ftview 14 LiberationSerif-Regular.ttf [1]
> > 
> > Toggling anti-aliasing ('a' key) makes it obvious that it
> > significantly degrades the quality of some glyphs (the leg of 'k'
> > the slashes in rationals become almost invisible)
> 
> Looking into the font's `gasp' table you can see that the font expects
> anti-aliasing starting with a font size of 18ppem.  In the range
> 9-17ppem, you have to use B/W rendering.  ftview ignores the `gasp'
> table completely ? it's just a diagnosing tool, not a real user
> application, thus it allows switching between AA and B/W rendering for
> comparison purposes.  However, `fontconfig' or similar libraries
> *must* respect this table, otherwise you get bad rendering results.
> 
> In other words: Your bug report is invalid :-)
> 

FWIW other fonts are also affected at certain point sizes
Liberation Mono (Regulr) diagonals making the 'v' are very thin,
Liberation Sans Italic the leg of 'y' is completely invisible,

I have stumbled upon [1] and it looks as if Times New Roman's 'z'
suffers from the same problem and the author gives a clue as to why.
The way i understand it - Windows's rasterizer (with or without ClearType)
processes the bytecode (or output of the BCI) differently so that the
problem never manifests itself.

-- 
mailto:address@hidden