RE: [Devel] Hinter changes

[Turner David]

Hi Keith,

> Xft's LCD mode hasn't changed, so non-integer stem widths 
> will still look horrible.  It might be nice to have an option 
> that made the auto-hinter bail on shape consistency and keep stems 
> snapped to integer pixels like the instructed TT hinter usually does.  

The option already exist, it's called FT_LOAD_TARGET_LCD for horizontal
decimation, and FT_LOAD_TARGET_LCD_V for vertical one. These flags must
be used when calling FT_Load_Glyph and are passed to the hinters which
are free to process them adequately. 

By the way, ftview already supports the display of LCD-optimized
rendering (use the 'l' key to switch between rendering modes), though
it doesn't filter the output (i.e. you'll see color fringes)

Currently, both the automatic and Postscript hinters try to stem
stem edges to integer positions when it makes sense (i.e. the edge
isn't too small)

They are still experimental for now, but I'd appreciate if you could
experiment with them in Xft. It should be a relatively trivial change
to the sources.

Note that these flags are only "hints" to the hinters, they do not
guarantee that the stems will always be snapped to integer pixels
(though that's what the auto-hinter currently does).

I believe that further experimentation with decimation filters could
improve the appearance of the current situation, but who has the time
to do that currently ? :-)

> Is it possible for the autohinter to adjust diagonal and curved elements 
> of the glyph to match the snapped stems?
> 
What do you mean exactly ?

Regards,

- 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.