Re: [Devel] Some food for thought (Might be?)

[Rogier van Dalen]

(Just my 2c.)

> which has a few comments on font design and hinting. I don't know if
autohinter has
> addressed his points but there's a link to John Hobby's research paper on
related
> topic:
>
> http://cm.bell-labs.com/who/hobby/pubs.html

The method described in this paper has two problems if it is to be used for
autohinting, IMO:

1. Preparing the matrices is done before the font is published, because the
LLL algorithm takes (if I remember correctly) at most N^5 operations. I'm
not sure it would be feasible to do this real-time on current computers,
which would be necessary for auto-hinting.

2. If the matrix is included in the fonts, the display type (e.g., b/w,
anti-aliased, subpixel) would have to be determined by the font.
Anti-aliased display needs twice as many integer constraints on the stems as
monochrome display if one of the two sides is to be snapped to the pixel
grid. This will, by the way, increase the complexity to (2*N)^5 = 32 * N^5.

Note that the "simple" floating-point least-squares solution may be
simplified in the auto-hinter because only key points have to be encoded as
functions: the other points may be found by interpolation. This may speed up
things. Also, if the method is followed exactly, however, there is no need
to recalculate the matrix for every point size. Rendering at different sizes
would thus be relatively fast.

I'm not saying Hobby's method would be impossible to implement in an
auto-hinter, but the algorithm will probably take a relatively large amount
of time to run.
However, from the tests I've done (that is, without understanding the math
involved in the LLL algorithm) it seems that lowest-cost solutions found are
relatively good solutions. My guess is that the output would be great.

I wonder whether a hinting method (as opposed to auto-hinting) could be made
from the Hobby approach...?

Regards,
Rogier