When designing a new typeface, how early on do you decide what format will be the target? I suppose providing only one format is more efficient, since you can focus on one type of hinting only and provide the best results. Despite some opinions that OTF* is the future and the fact that PostScript hinting is allegedly easier, I suppose when you want to achieve the best results on all platforms, you still go for TrueType?
If so, do you perform a manual conversion at some point in the designing cycle, and you take it from there, applying any new improvements to the TT version? (I would not be inclined to go that way....)
When designing a textured typeface, I presume you would use PostScript so that the conversion doesn't result in any quirks and to cut down on file size (since hinting is negligible in that case). But if you have a family consisting of solid and textured styles, then you'd likely use one format for all of them, right?
I have ambiguous feelings regarding the whole schism between the formats. I suppose the only reason for so many differences between them (not just curve type but also how renderers treat them, their hinting mechanisms, etc.) is simply the available technology, the already developed software? Or are the hinting differences directly and inherently related to the curve types? (I could see how using delta hints would be more useful when there are more nodes available to shift).
________________
* Technically fonts with both TrueType (quadratic Bézier) and PostScript (cubic Bézier) curves can have either the .otf or .ttf extension. Why would they though?
Comments
I would assume the main reason for the difference in hinting is simply the fact that PostScript fonts were not originally designed with on-screen rendering in mind, whereas TrueType fonts were. More sophisticated hinting was required for decent rendering on (then common) 72 dpi screens than on 300 dpi LaserPrinters.
I don't see how that matters at all, actually. The curve type and the hinting models are entirely unrelated, as far as I can tell.
> Technically fonts with both TrueType (quadratic Bézier) and PostScript (cubic Bézier) curves can have either the .otf or .ttf extension. Why would they though?
No. Fonts with PS outlines can only have the .otf extension. Fonts with TT outlines can technically have either.
Unfortunately, that only really works if TTF is your target. If you eventually plan to export to CFF (PS-flavored OT), your curves will be converted to 3rd-order and you may see some rounding errors (or increase of the file size if exporting non-integer point coordinates).
ps. @Georg Seifert Maybe Glyphs should include a pixel preview when you editing CFF hints too?
PS hinting is somewhat similar to how power guides work in FL: we actually use similar approach when doing post-interpolation rounding (or fixing irregular/uncommon stems).
Unfortunately there is no native PS hinting preview in FL7, but I made some experiments in FLS5 and it seems that bigger values provide thicker renders while smaller values make font lighter. That it with Freetype renderer. System-native and Adobe rendering may do it differently.
The native value for the main V stem in this font is 79.
At least as originally conceived, TT hinting is instructions: the hints tell the rasterizer what to do, and the person creating those instructions was (at least originally) in control of every pixel at every ppem size.
Of course, with the increasing diversity of rendering schemes under TrueType, maintaining that sort of control has become more tricky. That is without even considering rendering environments like macOS/iOS that ignore the built-in hinting. But there is still much of this difference. That’s how we get things like the option in TTFautohint to increase x-height below certain ppem sizes.
Could you please fill the support ticket (and attach some sample font)?
The CVT table can store 65535 values. So you could add 32767 "zones" to a TrueType font.
TT hints are programs -- you can literally do anything you want on the outlines. CVT? It is just a number array and usually stores coordinates.