/* While the current increase of computing power would allow for better algorithms to handle B/W auto-hinting, it becomes moot at the same time because the increase of today's screen resolution even for the cheapest displays makes hinting unnecessary, more or less. */ Seeing the community think like this is cringe. This only delays the development of ttfautohint even further, even though bilevel optimized hinting is of course a very important feature. On my laptop display, (1366×768, 101×101dpi, which is about 96dpi) bilevel-optimized hinting is the best hinting. And it remains so even in displays of five fourths times the dpi (120dpi) and six fourths times the dpi (144dpi). Even in double the dpi (192dpi) bilevel optimized hinting is clearly the sharpest text rendering. For hinting to be "unnecessary" you would have to approach Infinity dpi exponentially, that is, work on 384dpi, 768dpi, 1536dpi displays, etc. . And that would be really expensive. All because of the mindset that blurry text is ever so slightly, but not really, better on higher resolutions than on lower resolutions. That's desirable for a commercial company like Microsoft (it can get away with selling systems that default to incorrect gamma anti-aliasing, which looks awful regardless of resolution), but certainly undesirable for free software. I suggest ttfautohint developers to immediately think of ways to achieve bilevel-optimized hinting. /* // ====== // // Width control: In proportional fonts, horizontal hinting may change // widths. Not with FreeType's auto-hinter that gets used by ttfautohint! The widths are always identical to the original ones. */ Uh, what? Isn't it a redundant statement, as ttfautohint currently uses no horizontal hinting? The reason I mentioned this, is that the FontForge autohinter, which appears to hint both horizontally and vertically, changes widths, which of course completely breaks fonts whose design is dependent on spacing. /* It's not clear to me why you are concentrating so much on hinting at such small sizes. As the old MS core fonts (Times, Arial, Palatino) have demonstrated, it is an incredible amount of work to do this correctly. Note also that MS abandoned B/W hinting for characters that have been added later to the core fonts. This means that today only a small fraction of the glyphs in those fonts actually do work correctly with B/W hinting. */ The reason hinting the Microsoft fonts was painful is because that was the only job the hinters could find. On the other hand, the true hinting of some free fonts is made by the free software community. The Microsoft fonts are completely irrelevant to this as they are of no use towards developing free fonts. The removal of horizontal hinting to later glyphs is irrelevant as well: I think they did this to speed up the initial development of the character set, while retaining full hinting for many characters (this includes the WGL4 set, which is what most of the Latin, Greek and Cyrillic content consists of). It is not impressive at all, and a closer look can reveal imperfections of hinting in all fonts, whether it be stem weights diverging at larger sizes, or an imperfect letterform for a particular size. /* For such small sizes, a cheaper, probably better, and definitely much easier solution is to create embedded bitmaps and/or pixmaps, the latter using a low number of gray values. A few years ago I visited the famous Morisawa company in Japan, which produces probably the best Japanese fonts. In one department there were a bunch of people who created such pixmaps of CJK characters. In other words, this *is* used, at least for CJK glyphs, and I don't see why this can't be used for non-CJK scripts, too. */ I don't think most environments support this. Microsoft Calibri has embed bitmaps, but they don't appear to be used, ever, at all. Instead, GDI uses its broken hinting. I've heard Microsoft Windows has to detect for several Japanese characters in the font before using embed bitmaps. /* You would be able to use such hinted fonts for screen-display only, for example, to display menus. If you want to have something similar to WYSIWYG, such hints are completely useless. */ Uh. Isn't that true for pretty much all fully hinted fonts? "You would be able to use Arial for screen-display only, for example, to display menus." "If you want to have something similar to WYSIWYG, such hints are completely useless." "You would be able to use Courier New for screen-display only, for example, to display menus." "If you want to have something similar to WYSIWYG, such hints are completely useless." "You would be able to use Times New Roman for screen-display only, for example, to display menus." "If you want to have something similar to WYSIWYG, such hints are completely useless." Horizontal hinting is fundamentally dependent on the layout being reflowable. Don't let that distract the developers from implementing horizontal hinting. /* // Unify the blue zones for ascenders and descenders if possible by the // font design. Because some fonts have them the same, or within 1 // unit, etc. it makes for consistent hinting. This I don't understand. Please elaborate and give an example. */ DMCA Sans Serif: x-height: 1004 ascender-height: 1413 descender-height: -410 difference between x-height and ascender-height: -409 However, in ttfautohint, the difference between x-height and ascender-height is independent of the descender height. So they end up with different values! /* // Width delta: The monospaced width becomes a cvt rounded to an // integer, and the user can choose to delta it. By default, this // feature is not used. No idea what you are talking about. What feature do you mean? */ If the width cvt is delta'd, the width changes for every glyph in that size. /* // Those are hinted horizontally. But watch out. Keep in mind that // they are at a different angle, so with calculations (relative to the // horizontal and vertical stem weights) the points that terminate the // diagonal stems need to be at a specific horizontal distance. It // should be consistent with the horizontal and vertical stem weights — // especially when those are 1 pixel, where an unhinted stem stands // out. You could have various diagonal cvts that would determine the // horizontal distances for diagonal stems at various angles. You mean precomputed values? */ So, for example the vertical stem weight goes 1, 1, 1, 2, 2, 2, 3, 3, 3, 3, 3, 3, 4, 4, 4 and the horizontal stem weight goes 1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 4, 5, 5, 5 so, for example, a diagonal stem weight might go 1, 1, 1, 2, 2, 2, 4, 4, 4, 5, 5, 5, 6, 6, 6 and it is used at the ends of diagonal stems. /* // ====== // // First of all, handling diagonal stems on the S/s characters. I've // actually figured out a way to do it: https://i.imgur.com/2S3prC2.png // . It involves there being an interpolate instruction from the top // of the top and bottom stems to a control point of the top of the // diagonal stem, and so with the bottoms of stems, and this // interpolation automatically makes the middle stem hinted to the // proper weight. Looks good. Could you transform this image to some (mathematically based) algorithm? Or reformulate it using bytecode instructions? */ The interpolate instruction is an interpolation. Suppose there are points a, b, c, having coordinates in one dimension. After hinting, a and b move to locations A and B. So, when c is interpolated between a and b, its coordinate C becomes (((c-a)/(b-a))*(B-A))+A. I don't think you should really use this raw equation, as it leads to rounding errors.