PS or TT? (aka cubic vs quadratic Bézier curves, or *.otf vs *.ttf)

Adam JagoszAdam Jagosz Posts: 603
edited December 2019 in Font Technology
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


  • 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).
    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 could see how using delta hints would be more useful when there are more nodes available to shift).

    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.
  • Adam JagoszAdam Jagosz Posts: 603
    edited December 2019
    (The timestamp gets shifted in the embedded player for some reason, go to 35:28 instead).
    Due to the video resolution I can't see clearly to which nodes the final delta hints are connected, but I assume that these would be the intermediate nodes which would be most likely absent in PS curves.
    As for the file extensions, I remembered reading somewhere the distinction you brought up, but I couldn’t find it written down officially. Here it is though. But I changed an PS font’s extension to .ttf and it still worked (under Windows). I guess the keyword here is the word should?
    > A file containing a single font resource with only CFF outline data (no TrueType outlines) should have an .OTF extension.
    So I suppose the reason for a TTF-based font to have an .otf extension would be compatibility with some older systems? (But which, I wonder).
  • Mark SimonsonMark Simonson Posts: 1,202
    edited December 2019
    One big reason for the different types of curves was related to the fact that TrueType fonts were meant to be rendered on-screen on computers that ran as slow as 8 MHz. Quadratic Bézier curves required less processing. The difference is trivial on modern computers, but back in the early nineties, it made big difference.
  • Georg SeifertGeorg Seifert Posts: 610
    edited December 2019
    Depending on your workflow, you don't need to decide what format your ship your fonts. with. In Glyphs, you can draw cubic curves and add manual PostScript and TrueType hints to them. On export the outlines are converted and the appropriate hints are exported. So from the same source, you get CFF ad TrueType based fonts. 
  • Hinting "conversion" is not a problem in any modern font editor (with the exception of delta-hints applied to off-curve TT points which you should avoid anyway, but that's another story), while using combination of 2 curve types in the same outline may have some benefits, especially in cases of limited "space" to position points. 

    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).
  • Adam JagoszAdam Jagosz Posts: 603
    edited December 2019
    On Mac, I presume, TT and PS fonts render more similarly. As on hi-res screens on Windows or Android as well.
    The reason I started this thread was that as much as high-resolution displays are more and more prevalent, low resolution screens are still the reality for at least a couple more years. And rendering of CFF and TTF fonts is drastically different on a Windows machine @ 118ppi. I am a newbie to hinting, but my intuition is that I would hint a TTF and a CFF font differently. I don't know exactly differently how, but still. Maybe let’s start with the fact that I'd design the weights lighter for a CFF font than TTF (maybe that’s wrong though).
  • On Mac, I presume, TT and PS fonts render more similarly. As on hi-res screens on Windows or Android as well.
    The reason I started this thread was that as much as high-resolution displays are more and more prevalent, low resolution screens are still the reality for at least a couple more years. And rendering of CFF and TTF fonts is drastically different on a Windows machine @ 118ppi. I am a newbie to hinting, but my intuition is that I would hint a TTF and a CFF font differently. I don't know exactly differently how, but still. Maybe let’s start with the fact that I'd design the weights lighter for a CFF font than TTF (maybe that’s wrong though).
    You find the problem. CFF hinting behavior is not well defined, which is really bad. It only gives you ability to point out "this is a stroke", but gives zero control on how the rasterizer process them. In the other hand, TT is much more clear, though some parts like the "Compatible Width" is still a mess.
    ps. @Georg Seifert Maybe Glyphs should include a pixel preview when you editing CFF hints too? 
  • Maybe let’s start with the fact that I'd design the weights lighter for a CFF font than TTF (maybe that’s wrong though).
    You may have some control over CFF/PS hints if you play with standard stem values. 

    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).
  • @Yury Yarmola Do you suggest setting stems smaller than actual outlines?
  • I don't remember how exactly it works, but you may want to play with values of 2 basic settings (stems named "Hstem" and "Vstem") and/or standard stems set.

    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.
  • ps. @Georg Seifert Maybe Glyphs should include a pixel preview when you editing CFF hints too? 
    The different renderers produce too different output that it would be misleading to have any one preview and to difficult to implement all different rasterisers/system versions. 
  • Adam JagoszAdam Jagosz Posts: 603
    edited January 4
    Hinting "conversion" is not a problem in any modern font editor
    It is for FontLab.
    PS font exported from FontLab 7 as TTF with autohinting:

    PS font converted to TTF, exported from FontLab 7 with autohinting:
    I've had this kind of problems with any PS font I tried to convert and hint on the fly in FontLab. I can’t believe this hasn’t been spotted yet.
  • Adam JagoszAdam Jagosz Posts: 603
    edited January 4
    You find the problem. CFF hinting behavior is not well defined, which is really bad. It only gives you ability to point out "this is a stroke", but gives zero control on how the rasterizer process them.
     @Belleve Invis I’m not too familiar with all rasterizers, but PS hinting has evolved since its conception. Adding manual hints is possible, and as far as I can tell, all glyphs are getting automatic glyph-level hints when exporting from FontLab with autohinting enabled. (Or if this always has been the case, then I don’t understand the always repeated “truth” that PS hinting is all in the rasterizer — while it mostly is on Mac, on Windows the rasterizers are just inconsistent but the hinting is still in the font). You are able to control hint size, which does yield differences in at least some rasterizers.

    Technically you are correct though, the automatic hint in the F on the left does say “this is a stroke (including serif)” and the level of control of PS hints and consistency across renderers leave a lot to desire.
    Since Mac ignores this hinting information, and most type designers are on Mac, I’m not surprised there’s misconception about PS hinting because not many people bite into it.
    Also: I’m not sure whether this should be done, but it could: you could manipulate the hint size misaligning it with the stem for further control (minute grayscale differences here).
    (Windows, Firefox; Chrome looks similarly).
    Also, I was able to affect the rendering quite a bit by modifying the standard stems values.
    Perhaps the worst thing about PS hinting is that something can end up lower than the alignment zone when the outlines reach higher than the alignment zone.
  • Thomas PhinneyThomas Phinney Posts: 1,856
    It's not that “PS hinting is all in the rasterizer.” It is that the information in the font is a bit sketchy and general. PS hinting is informational: the rasterizer then decides what to do with it.

    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.  <3
  • Adam JagoszAdam Jagosz Posts: 603
    edited January 4
    To recap: I was mainly curious what is the practice among TypeDrawers. How about a micro-survey? Do you ship TTF or CFF fonts, or both?
  • Ray LarabieRay Larabie Posts: 972
    I usually provide both but there are rare cases where In only provide one format. I made a typeface called Remissis which contains lots of near horizontals, intended for high resolution output. When displaying the unhinted TTF in Windows the near horizontals appear distorted while the unhinted CFF version looks smooth. In some very detailed texture display typefaces, the unhinted TTF version will hang/crash the Windows preview while the unhinted CFF version only causes a slight pause. In the past I would generate a reduced detail TTF version but now I just release CFF.
  • Mark SimonsonMark Simonson Posts: 1,202
    I distribute both (together) as far as possible, but a couple of my distributors provide only CFF by default and TTF only if the customer asks.
  • I've had this kind of problems with any PS font I tried to convert and hint on the fly in FontLab. I can’t believe this hasn’t been spotted yet.
    Very interesting ;)
    Could you please fill the support ticket (and attach some sample font)?
  • Adam JagoszAdam Jagosz Posts: 603
    I already did, see #3263. In general, is there even a reason for having alignment zones defined separately for PS and TT?
  • Viktor RubenkoViktor Rubenko Posts: 76
    edited January 14
    In general, is there even a reason for having alignment zones defined separately for PS and TT?
    PS zones are limited: 7 for BlueValues and 5 for OtherBlues, while you are unlikely to ever reach the limit for TT zones.  
  • Just for the record :)
    The CVT table can store 65535 values. So you could add 32767 "zones" to a TrueType font.
  • Adam JagoszAdam Jagosz Posts: 603
    edited January 16
    Would you need UPM of at least 98304 to do so? :D Or can zones in TT overlap?
  • Or can zones in TT overlap?
    Of course they can, and there is nothing shameful about it!
  • Would you need UPM of at least 98304 to do so? :D Or can zones in TT overlap?
    TT doesn't have any concept like blue zone. The only “zone” existed are Twiligth vs Non-twilight, which represents two “namespaces” of points.
    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.
Sign In or Register to comment.