Re: [ft] otf autohint/nohint problem

[Werner LEMBERG]

> Suppose you ran a program like ftview to render the whole font to a
> bitmap with each hint option, at a large point size like 64.  Would
> they be the same?  This would have caught the bug/regression you
> fixed.  Or maybe I should rephrase the question.  This could be a
> test tool the calculates the smallest point size that the bitmap for
> a font is the same for all hint options.  Maybe it's just overkill
> for a problem you've already fixed,

Yes, I think so.

> or maybe you'd want to know if suddenly hinting is making a
> difference at 100 points for times new roman. :)

Well, there are TrueType fonts (e.g. mingli) where the results with
and without bytecode interpreter are totally different, regardless of
the size.  Additionally, under normal circumstances there will
*always* be a difference between hinted and unhinted glyphs if you
consider anti-aliased rasterization, regardless of the hinter.

> > > We obviously can't have an ideal hinter, but I was wondering if
> > > we could still calculate an ideal hinter even if we can't make
> > > one?  For instance, one view of a perfect hinter could be that
> > > it shows all the edge transitions.
> >
> > Uh, oh, I don't follow.  I don't understand what you mean with
> > `edge transition'.  Please give an example.
>
> I'll try, but I lack proper verbiage.  I'm thinking about detecting
> cases where parts of a character touch other places, making them
> harder to see.  Hinting, imo, often moves character edges slightly
> to improve such separation.  Take the 'o' and render it three pixels
> wide.  Look at the horizontal strip through the center.  It should
> transition from high to low to high.  Some fonts though might have a
> hole that is smaller than the middle pixel, or have it offcenter,
> resulting, in anti-aliased rendering, in lots of grey.  A good and
> working hinter would move/resize the hole so that the middle pixel
> contrasts highly with the left and right.  And when I say high and
> low, it could be fully black and white, but practical values might
> be less.  So the transition count for the middle horizontal row
> through a 'o' is three.

I see.

> [...]
>
> If the ideal transition count for the horizontal strip through a 'o'
> is three, but the rendering measures at two, then something might be
> considered wrong.  The error for the row is (3-2)/3.  You could test
> all characters in a font and see which characters have the most
> errors.  You could test the effects of just one hint.  You could
> compare over time to insure improvement versus regression.  You
> could combine measurements for all characters in a font to make a
> rating that could indicate the performance of a hinter.

Well, what you describe could only work for the PS and autohinter --
the TrueType bytecode interpreter is expected to always yield the same
result, regardless of the hinting engine.  As we all know this is
theory only since some fonts rely on rouding bugs in the Windows
hinting engine to display properly.

> The basic idea is to calculate ideal values from large sizes where
> hinting doesn't matter, and then compare at smaller sizes where
> hinting does matter.  Transitions is just my example, but hinter
> people might know of other quantities.  Perhaps line widths or
> kerning or something is more important or easy to check.

I must admit that I lack the background and knowledge of those issues
which partially belongs to statistical analysis and computer graphics.

> > Honestly, I don't think that an automated routine can measure the
> > improvements done by a hinter.
>
> I expect this routine to report better numbers for a font rendered
> with a hinter at small sizes than a font rendered without one.  I
> also expect that a hinter with a bug in transitions will also get
> reported as having worse performance.

I invite you to provide some code to test that :-) Maybe a project for
a student...


     Werner