Howdy, Stranger!
Categories
- All Categories
- 34 Introductions
- 3.5K Typeface Design
- 736 Font Technology
- 1K Technique and Theory
- 557 Type Business
- 423 Type Design Critiques
- 518 Type Design Software
- 29 Punchcutting
- 126 Lettering and Calligraphy
- 74 Technique and Theory
- 52 Lettering Critiques
- 439 Typography
- 277 History of Typography
- 107 Education
- 55 Resources
- 465 Announcements
- 69 Events
- 101 Job Postings
- 145 Type Releases
- 149 Miscellaneous News
- 255 About TypeDrawers
- 51 TypeDrawers Announcements
- 109 Suggestions and Bug Reports
TrueType hinting in 2020
Kazunari Tsuboi
Posts: 15
I would like to ask about the “modern” TrueType hinting workflow.
Over the last few years I have been using ttfautohint --control-file.
However, manual hinting must be introduced to meet the detailed requirements of my customers.
The information I want is the following points
・Tool options
・Handling of TrueType hint when updating fonts. How can I set the TrueType instruction in the previous version of font to the next version of font?
I have no knowledge of Hinting export/import.
Are there any teaching materials to learn about the recent Hintig workflow?
I would be happy if you could give me any information.
0
Comments
And if our export as variable font, the hints work there, too.
https://www.microsoft.com/en-us/download/details.aspx?id=100438
VTT has a built in Autohinter. Depending on your hinting requirements, this will get you some way. The output from the Autohinter does require touchup, and VTT has quite a steep learning curve. When I worked at MS, I wrote a number of posts on using VTT to hint, unfortunately the blog has not been maintained. This post might be useful. There is also some built in help in VTT that may be useful to you.
https://docs.microsoft.com/en-us/archive/blogs/fontblog/a-graphical-guide-to-vtt-6-10-light-latin-autohinting
if VTT is something you think you might want to use, I may be able to give you some basic pointers and or help on that, although I am not in a position to give any extensive training or technical support.
1. If your source has multiple masters, you can hint the main master, and FontLab will distribute the hints to instances.
2. You can attach TTH commands to PostScript or TrueType contours, with overlaps. FontLab will retain the hints after you remove the overlaps.
3. When you create TTH commands in FontLab, the app adds names to nodes, and attaches the commands to the names. In FontLab Studio 5, TTH was based on node numbers, so it was very fragile. In FontLab 7, it’s more independent.
4. You can hint some key glyphs, then copy a glyph layer e.g. in "O" and then use Paste Special > TrueType hinting on "Q" or other similar glyphs, and FontLab will "magically" paste the TTH commands on the "correct" nodes. Even more — you can copy from one FontLab TTH-hinted font, and then Paste Special > TrueType hinting on glyphs from a different font, as long as the node structure is fairly similar. The same goes for copying TTH from, say, uppercase to small caps or to lowercase.
5. The videos by Monika Bartels
6. Of course, FontLab 7 has a powerful TT autohinter. It can use existing PostScript hints, or build TTH commands from scratch, and in Preferences you can control which types of commands it should generate. You may want to turn off middle delta generation.
https://www.dropbox.com/s/esib0lemtebko8g/fl7-pastespecial-truetypehinting.mp4?dl=0
It’s important that both glyphs have the same basic contour structure and the same contour direction — but they don’t need to be point compatible.
https://www.dropbox.com/s/9l5wqcb40xdz622/fl7-pastespecial-truetypehinting2.mp4?dl=0
When one glyph has no overlaps and the other does, then it does not work (since matching of the topology fails), but when the topology roughly matches, then it works.
TrueType hinting involves writing a list of cvt values. Example (for DMCA Sans Serif 10.0 Bold in development that I'm hinting right now)
The InstructionsOn is what range the hinting are enabled, and in this case is set
to the maximum. However it is also possible to specify sizes for hinting (as well as anti-aliasing) in the gasp table.
The DropOutControlOff specifies at what size and up the dropout control (forces rasterization of lines that would otherwise go right past the pixel centers) turns off. In my case I have it disabled all the way because it can also restrict possibilities of hinting geometrical glyphs or something.
The CvtCutIn specifies how far the snapping to cvt can go (otherwise it resets to default rounding) starting at each size.
The ClearTypeCtrl makes various deltas also apply to ClearType rendering that would otherwise get disabled by ClearType hacks. However, as I'm doing full hinting with the deltas optimized for fully hinted rendering, the ClearType hacks are necessary so I have ClearTypeCtrl disabled.
The LinearAdvanceWidths makes it possible to use fractional ppem sizes in some renderers or something, however as it is impossible to separate deltas of multiple sizes that round to the same ppem I find no use for it in full hinting.
So I set the first eight cvts to zero because for some reason any attempt to use them glitches the hinting. The 255 is also set to zero because otherwise there would be out of range errors.
The cvts are for specifying feature sizes that should remain consistent throughout the font. In my case:
• 8 for the baseline
• 9 for the x-height
• 10 for the overshoot baseline
• 11 for the overshoot x-height
• 12 for the stem height
• 13 for the stem width
• 14 for the cap-height
• 15 for the ascender-height
• 16 for the overshoot cap-height
• 17 for the overshoot ascender-height
• 18 for the descender-height
• 19 for the overshoot descender-height
• 20 for the comma stem width
• 21 for the dot width and height
As the character set goes beyond ASCII, more cvts would be necessary. The font top and font bottom for box drawing characters as well as their stem weights come to mind immediately.
Font hinting instructions include the link, the interpolate and the delta.
The link: For creating a direct dependence on vertical or horizontal distance from one point to another. It is usually rounded to integer, and may be snapped to a cvt. It may for instance be used for linking from the origin to the baseline or x-height, etc. or for linking one side of a stem to the other. Horizontally it may be used to link from one vertical stem to another.
The interpolate: For creating a dependence on positioning of a point horizontally or vertically between two points. It may be rounded to integer, but does not use cvt. Example uses are for positioning of a middle horizontal stem in 3569BEGae{} for instance. I've seen examples of interpolating from the bottom and the top but instead I find it the best to interpolate from the tops of two stems to the top of the middle stem, or the bottoms of two stems to the bottom of the middle stem. In case of FPR in place of the bottom of the bottom stem it is possible to use the bottom of the letterform due to the same vertical position, and in H it is possible to create a point within a vertical edge to simulate a top or bottom horizontal stem. @g require multiple interpolations due to multiple middle stems, and $&08Ss involve diagonal middle stems that I find the best to interpolate both ways for top and bottom side with no rounding (similarly the diagonal in the middle of ~ horizontally).
The delta: There are multiple types of delta available, what they do is at a specific point size they move a single point horizontally or vertically. The types are: the inline delta, which moves the point after the instruction linking to it but before the next instructions depending on it, the pre-IUP delta, which moves the point after the linking and interpolate instructions but before the final interpolation of untouched points (IUP), and the post-IUP delta, which moves the point after the links, interpolates and IUP meaning the delta would not affect any other point whatsoever. The inline delta is generally used to position font features at a different pixel, while the post-IUP delta is generally used to correct pixel patterns.
There are also other instructions like Shift, Align, Stroke, Move but I haven't used them in hinting, they might be of some use to some hinters out there.
It's the information I need and treasures. It seems that the timing of using each tool will differ depending on the work environment and the desired quality. I'm learning while working.
I think you overestimate the number of type designers interested in touching hinting tools.
It’s 2023 and HiDPI screens seem to be almost the norm. Most type designers design on a Mac and have no conception of how their fonts render on Windows. Every now and then I’m contacted by a panicking designer, having received screenshots of a client on Windows or Linux, that do not look great.
To my question: does anyone have an estimate about the ratio of screens with device pixel ratios 1, that are still in use worldwide? (72 or 96 dpi)
I’m able to find percentages of OS use and screen resolutions, but not on device pixel ratios.
I’m all pro TT-hinting and I’m putting in a lot of effort and time in doing the best I can. Even on HiDPI screens, hinting is still improving the rendering of most fonts.
The kinds of lighter, y-direction hinting that we use most often now are well-suited to automation, which is just as well because hinting budgets have disappeared from most projects that we work on now.
Hi John, thanks for your elaborate answer. I do agree, that autohinting can often be enough, if one understands the tools and prepares the fonts well before running the autohinter.
Unfortunately I observed that the claim “autohinting is good enough” leads to some designers not preparing, nor controlling their fonts and just checking the autohint box during export. Which can lead to worse results than unhinted fonts.