> 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. _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
