Re: [ft] Bytecode hinter producing bad results, seems to be a regression

[Werner LEMBERG]

From: Vinnie <address@hidden>
Subject: Re: [ft] Bytecode hinter producing bad results, seems to be a 
regression
Date: Sat, 1 Jan 2011 12:20:06 -0800 (PST)

>> The function FT_Get_Gasp tells you, for a given ppem, whether you
>> should render a glyph as monochrome (i.e., black-white) or with
>> anti-aliasing.
>
> ppem? Pixels per EM unit?

Yes.

> By monochrome I assume you mean, two intensity levels (on or
> off). As in, an old school bitmap font (like Apple II+).

Yes.

> All of my font-drawing is anti-aliased, I'm the middle man passing
> the grid-fitted control points over to another third party library
> that I'm using.
>
> Why would I ever want to render a glyph as monochrome (two-color)
> only?

Here is the problem: For a certain ppem range, as specified in the
gasp table, the particular Helvetica font *expects* B/W rendering!  If
you do anti-aliasing instead, you get bad results.  On the other hand,
some B/W rendering results of Helvetica are really bad and I wonder
whether this is due to a bug in FreeType or whether this font has
simply bad hinting instructions.

>>> I'm not using FreeType to render...just to extract outlines.
>>
>> This is tricky...
>
> Can you elaborate?  Or tell me anything I should know about that is
> non-obvious or non-intuitive?

The trickyness is that you are trying to separate hinting from
rasterizing.  As explained already, the TrueType bytecode interpreter
and the rasterizer do interact.  It's not intended to be handled
separately.

> I'm actually getting really good results with the auto hinter.  I
> can see very clearly that it is working, and I painstakingly
> analyzed the output of each glyph to make sure that things are
> right.

Yes, because the autohinter works completely differently.  In
particular, it always expects anti-aliased rendering.

>>> And by the way, the autohinting module works pretty damn good!
>>
>> Then use it!
>
> Okay well just to make sure I did things right, I loaded up Adobe
> Kaiti Std Regular (a thin serif font) and performed the
> comparisons.  First thing I noticed, is the Adobe font is a hefty
> 16.5 megabytes, while my Neue Helvetica is a wimpy 127 kilobytes.

Kaiti is a font for Chinese.  Do you need this?

> I tried bytecode hinting with the Adobe font and WHOA! amazing
> outlines!  So I guess that my problem is not that FreeType wasn't
> using my bytecodes, its just that my Helvetica didn't have them.

No, no, no!  The Kaiti font is *not* a TrueType font (this is,
second-order Bezier curves).  It's an *OpenType font* using CFF
outlines (this is, third-order Bezier curves), and there aren't any
bytecode instructions but PS-like hints.  Basically, it's a completely
different font format; it just happens that both TTFs and OTFs use the
SFNT container format, thus they look similar at a first glance.

> My intuition and eyesight tells me that a font with hints is going
> to look better with the bytecode hinting than with the
> auto-hinter. This is definitely the case with this beefy Adobe font.

I'm not sure.  FreeType's native hinter for third-order Bezier
outlines is quite buggy and problematic.

> I wish there was a flag to FT_Open_Face that says "hey use the
> bytecode hinter if the font has those hints, or else use the
> auto-hinter."

This is impossible to decide by FreeType.  On the operating system
level, such decisions are controlled by a higher-level library.  On
Linux, this is done by fontconfig, for example.

> So now I am going to trying grasping for the Gasp / Grasp
> whateveritis table and see if I can get some mileage.

Note that `gasp' makes only sense for TTFs, not OTFs.

> My goal is to use bytecodes if they are there, else use the
> autohinter.

I can only repeat that this won't work automatically but needs a user
decision.


    Werner