freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft] otf autohint/nohint problem


From: Werner LEMBERG
Subject: Re: [ft] otf autohint/nohint problem
Date: Sun, 20 Nov 2005 11:17:57 +0100 (CET)

> 1. My understanding of hints is that they are needed when the font
> is small to help the appearance.  Is there some threshold above
> which they can be ignored?  Could this lead to performance
> improvements (because the hints can be trivially skipped or the
> module can avoid loading)?

This is the job of the `gasp' table, at least in SFNT based fonts.
FreeType doesn't handle this.  Regarding Type 1 fonts I'm not aware of
any dictionary entry which equals the functionality of the `gasp'
table.  The application must control whether at which font size hints
shall be applied.

> 2. Are there any tests showing that fonts at a large point size are
> identical regardless of the hint module used?

Please explain in more detail, given that the scaling bug is now
fixed.

> 3. I was thinking about the error from the hint modules and how to
> measure and reduce it.  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.

> If we calculate the number of transitions possible on a pixel row,
> and then compare to what a hinter produces, we can get a rating for
> each row of the character.  Rotate for the vertical dimension.
> Apply to all characters.  Now we have an automatic test for how well
> a hinter is working.  Look at the worst characters and improve them.
> Make sure none of the other characters go down, over time.  You
> could confirm that adding a hint reduced the hint error.  You could
> check at which point sizes a hint reduces error (maybe the hint
> isn't implemented correctly).  There are obviously complications
> (what is the result for a one pixel tall capital 'H') but even a
> simple version would probably reveal a lot.

Hmm, without understanding the basics I can't discuss this.  Honestly,
I don't think that an automated routine can measure the improvements
done by a hinter.  Only the eye can do that IMHO.  I really would be
glad if you can prove the opposite, perhaps demonstrating your idea
with a particular font.

> 4. I was thinking about trying to figure out which hinter to use.
> The answer seems to vary depending on which fonts are installed,
> meaning you can't predict at compile time.  If we had a hint error
> measurer we could automatically select the best hinter for the font
> at runtime.  We could probably guess well with a trick.  For
> instance, we probably don't need to measure every single character.
> There might be two or three characters that give us the right
> decision 90% of the time.

The operating system's font manager should provide the possibility to
select the hinter on a per-font basis.  I think this is already
possible with Xft, at least in the configuration file.  I don't know
whether graphical interfaces exist to do that.


    Werner




reply via email to

[Prev in Thread] Current Thread [Next in Thread]