RE: [ft] otf autohint/nohint problem

[Roger Flores]

> Note that this isn't a TrueType font but a CFF, this 
> is, there are no bytecode instructions at all, and the 
> TrueType module isn't used.  If you don't force the 
> autohinter, the PS hinter is used instead.

Ah!  That is the crucial clue.  Our configuration was stripped for use
in an embedded environment.  Specifically, I noticed that the pshinter
module was removed when I did the update to 2.1.10.  I have confirmed
that if I remove FT_RENDER_FORCE_AUTOHINT but enable the pshinter
module, then the font renders nicely.

Thanks for help in getting this working.  Based on this experience, I
have some suggestions.  I putting the less related ones in a separate
email for separate discussion.


1. Diagnosing the freetype configuration problem by code inspection and
email to the freetype list is too costly.  I think that use of a font
that needs a module that has been removed should result in an error
code.  That way a developer trying to write good code (that checks error
codes) will get notified of the problem.  Or if they try and duplicate
the problem in ftview like I did, they could also see the problem.

2. I was/am confused about hinting in ft.  I was under the impression
that I had configured the code to run in a no hinting mode, and that
that was not working.  But apparently the code was using the pshinter
and not finding it.  I wonder if the attributes could be clearer?  Maybe
a FT_RENDER_USE_NO_HINTS, USE_AUTOHINT, USE_FONT_HINTS,
USE_FONT_PLUS_PATENTED_HINTS?  They should all be exclusive, right?

3. I think the font size should have been rendered closer to what the
other hinters produced.  Specifically, if no hinter is found (because
all of their modules were removed), I think the size produced should be
comparable.  It may not look as well defined, but I'd expect its size to
be OK.  In fact, I picked a large point size for a test case to try and
eliminate the effects of hinting.


Thanks,
-Roger Flores