> 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.
I originally suggested allowing LIGHT to use the Adobe hinter because the results were so close to the autohinter already. If we want to tie LIGHT/NORMAL to the style of hinting used (y vs x+y), I wonder if it would make sense to use the autohinter in full x+y mode for NORMAL, so the table becomes:
LIGHT NORMAL
TrueType Auto Bytecode
CFF Adobe Auto
Type 1 Adobe Auto