Re: [Devel] autohinter extension for manual hinting

[Rogier van Dalen]

Hi David,

> It seems that the if following manually determined data is provided, this is  
> sufficient to remedy the problems described above.  In my proposed system,  
> each size of each face has this associated information:
>
> FT_Fixed x_factor;   /* size-wide x_scale scale  */
> FT_Fixed y_factor;   /* size-wide y_scale scale */
> FT_Int   kern_pre;   /* size-wide before-the-glyph kerning adjustment */  
> FT_Int   kern_post;  /* size-wide after-the-glyph kerning adjustment */
>
> In addition, each glyph optionally has this associated information:
>
> FT_Fixed x_factor;   /* char-wide x_scale scale */
> FT_Int   kern_pre;   /* char-wide before-the-glyph kerning adjustment */  
> FT_Int   kern_post;  /* char-wide after-the-glyph kerning adjustment */
>
> [...]
I do like this idea because it seems to me there's nothing better than a 
human being when it comes to making  decisions about how a font should 
look (despite FT's great autohinter).

> Should scale values actually be the x_scales and y_scales to be used by the  
> hinter, or should they be either deltas, or scale factors?  I have them  
> working has factors now (e.g. 0.92 for an x_factor would make a glyph  
> narrower).  This seems not to be the best idea because the autohinter is a  
> fluid piece of code, and with an algorithm change here or there, these values  
> may become meaningless.
As the autohinter's behaviour may change, it might be best to specify 
the values as absolute values rather than relative values. Something I 
have been thinking of (for use in a hinting system) is calculating 
values by specifying values for some sizes explicitly and (linearly?) 
interpolating for the rest of them. IMHO, specifying values only for 
certain point sizes is a solution whose usefulness decreases as the 
autohinter changes.

> For a file structure, the way I have it working now is that a CSV (comma  
> separated values) file (padded, and so implicitly indexed--access is O(1)),  
> holds the values described above for a range of sizes and characters.  At 
> what point should data be retrieved from the file, and how many 
> sizes/characters at a time?  Into which structures should this data go? By 
> what means could files be associated with faces?  Or could this be one huge 
> optionally compiled table in Freetype itself?  Etc, etc.
>  
For fonts distributed by Microsoft (Arial, Times New Roman) I don't 
think it is legally possible to add tables to them. Padded values, I 
think, are prone to typing errors that are difficult to find. Couldn't a 
CSV file by read and stored in memory so that access in O(1) anyway?

Regards,

Rogier