Re: [ft-devel] merged CFF and Type1 hinting code now in master

[Nikolaus Waxweiler]

> Is this the scheme that you are proposing?
> 
>               LIGHT        NORMAL
> TrueType      Auto         v40
> CFF           Adobe        Adobe
> Type 1        Adobe        Adobe

Yup. My proposal makes the scheme more consistent, as Type1 and CFF get
the same treatment. The CFF hinting engine does not even support x-axis
changes as Dave explained some time ago, so LIGHT and NORMAL is already
meaningless for Type1/CFF fonts. It may gain meaning if someone
implements x-axis-hinting.

> You are one step away from ditching NORMAL or LIGHT altogether. Is this
> you intent?

I wish.

As a connoisseur of beautiful type, I'm a true believer of the Adobe CFF
 hinting engine school of thought that changes as little as possible to
strike a balance between low DPI clarity and the type's design. That's
the spirit of LIGHT. The autohinter is LIGHT, too, but has a guessing
element to it that is not there with the "native CFF hints", which is
why I prefer to see the native engine in LIGHT mode.

Given that the hinting strategy used for a TrueType font (light,
x-and-y-changes, bludgeoning the shapes into monochrome bitmaps) is up
to the designer, it's very hard to make FT output harmonious and
consistent looking text regardless of source (a standard Linux distro
ships stuff in all three scalable font formats). This is why I'd love to
have the bytecode engine out of the picture, but I understand it has
its' place.

Remember: When I started this crusade, I first tried to implement
hinting engine selection in fontconfig. Hardcoded and inconsistent
assumptions in fontconfig-using GUI toolkits made that impossible
however, so I opted for changing FreeType.