Re: [Devel] autohinter extension for manual hinting

[David Turner]

Hello David,

David Chester wrote:
> Hello,
>
> I am starting to work on an extension to the autohinter that would allow for 
> externally-provieded manual hints to override the automatically derived ones. 
> There are a few reasons why I think this is a good idea.  
>  [ details snipped ]
>
> I have a few questions.  First, would something like this be welcome in  
> Freetype?  If so, how should it be implemented?
Well, well, there are several things I'd like to say about this:

  - don't hack the auto-hinter. instead create a new module
    where you'd copy the current sources and apply all kinds
    of experimentation to it. the auto-hinter is going to change
    quite a bit in the near future, so be certain to have a solid
    foundation to work on.

  - use a simple binary format for the external hint files. Preferrably
    one that can be directly parsed in memory by the "augmented hinter"
    (as well as trivially validated). You don't want to spend your
    time parsing CSV files during the hinting, and you don't want
    to allocate tons of memory to load the file either.

    that doesn't prevent you to use any text scheme to write the files
    by hand, as long as you've got a handy converter; and this can be
    written in Python or Perl...

  - the hint file should be attached to the relevant FT_Face through
    the FT_Attach_XXX functions. The really hard part is ensuring that
    you're using a hint file that really correspond to the FT_Face
    being used. This can be left to higher layers, like fontconfig,
    but is a *tricky* question.

  - this will probably require a few internal changes to allow the
    font engine to deal with several "auto hinters", but I'm ready
    to help there in case you need it.

For your information, FreeType is going to change to allow several
script-specific "classes" of hinting to be applied to glyphs,
depending on their Unicode position. More on this later..


> 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.
I believe that these questions can only be answered by experimentation.

> 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.
Again, associate files with FT_Attach_Stream, and use a simple binary format
that is directly parsable, this will get you the best possible speed. and
you'll dearly need it to make things not too slow..

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)


--
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender.
Any use not in accordance with its purpose, any dissemination or disclosure,
either whole or partial, is prohibited except formal approval.
The E-Mail transmission can not guarantee the integrity of this message.
CANAL+TECHNOLOGIES will not therefore be liable for the message if modified.