freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] Horizontal Stem Snapping in Autohinter


From: Werner LEMBERG
Subject: Re: [ft-devel] Horizontal Stem Snapping in Autohinter
Date: Thu, 14 Jun 2012 07:51:47 +0200 (CEST)

> What are your thoughts on implementing horizontal stem snapping in
> the autohinter?

It's certainly worth an option.  BTW, if you say `make devel', the
option AF_CONFIG_OPTION_USE_WARPER is in use which goes into a similar
direction but trying to minimize the glyph shape distortion.  Have you
tried that?  Do you like it?

> To me, this provides a substantially cleaner look to 99.5% of
> glyphs, particularly when the stems are between 1 and 3 pixels
> thick.  I think this is largely the issue when people complain about
> Freetype font rendering.

OK.  However, this must be controllable at run time, I think.  We
urgently need an API to control the auto-hinter!  Currently, we are
abusing `load_flags' for that (which I've massively extended for my
ttfautohint project, BTW), but this is not a solution because we would
be running out of bits.  Additionally, it's ugly.

A first, partial implementation of auto-hinter properties can be found
in the `autohinter-properties' git branch.  I've implemented global
settings which are inherited by all new faces, and local settings to
adjust a particular face.  It's a very simple start, I think.

What we also need are functions like

  FT_Error
  FT_Library_SetAutohinterProperty( FT_Library  library,
                                    FT_Int32    property,
                                    void*       data );
  FT_Error
  FT_Face_SetAutohinterProperty( FT_Face   face,
                                 FT_Int32  property,
                                 void*     data );

to fine-tune a certain property (on the global and local scope);
`data' is a generic pointer which contents depends on the property.
For example, take the `increase x height for the range 5 < ppem < 15'
property in the Infinality patches: The above functions could be used
to manipulate the lower and upper bound (5 and 15, respectively).

In our private discussion in February you replied that the Infinality
stem-alignment stuff is not tied to the autohinter, so it might be
worth to move my first implementation attempt to the modules
interface, something which I haven't investigated yet.  Volunteers
welcome!


    Werner



reply via email to

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