Only one font format

Olli Meier
Olli Meier Posts: 8
in Font Technology
Hello everyone,

wouldn't it be time to clean up the font format we all know and have only one font format at the end?
Technology has changed. Software is running in browsers (like Google docs). More and more people are using their phones to surf in the WWW. Screen resolution is increasing dramatically (a couple hundred ppi for phones).

We have TTF, CFF, woff (TTF based), woff (CFF based), woff2 (TTF based), woff2 (CFF based), ...

When I look into TTF and CFF – we have three places to store the vertical metrics values, two places for the width of a glyph (CFF: in CFF table and hmtx) and the name table is just a mess.

I know, that we keep all the old stuff to be always backward compatible. But does this really make sense? 
I know, that we make more money when we sell different font formats. But is this really user friendly?

Wouldn't it be great to have only eg. woff3 (CFF based), which would work for desktop applications the same way like in browsers?

I am not long enough in the type business, but this question is in my mind form the beginning.

What do you think?

Many thanks for your thoughts,
Olli

Tagged:

Comments

  • Theunis de Jong
    Theunis de Jong Posts: 112
    edited December 2018
    I don't believe the purpose of having different font formats was to make money by selling the same font several times to the same user.

    Font formats, as virtually all "standard" basic file types, evolve with increasing technological capabilites and end user demands. Some of these new demands can be added to existing formats without breaking them; others cannot.

    OpenType, for example, can digest many more features than currently available; as long as these features can be described in the current rendering model. The most recent major addition, Variable Fonts, cannot – and so there is a new internal format called "CFF2", which is intrinsically incompatible with older rendering engines.

    Another difference is the description of font outlines. The entire paradigm of TrueType "instructions" is so different from CFF that they cannot be combined into a single encompassing model that supports both. If there is reason to develop a new format again, say, to make color font handling easier, or there is a more practical model to describe font outlines, it would essentially be an entirely new third font format.

    If one chooses to adopt only this hypothetical new format, it would require that users need to update all of their fonts. And again when a fourth "even better" format surfaces. And so on.
  • Olli Meier
    Olli Meier Posts: 8
    @Theunis de Jong I know about the different outlines of PostScript and TrueType and I also know about the development/introduction of CFF2. But all developments of new variable font tables or CFF2 improvements are just extra information to the old font formats to keep backward compatibility.
    But I would like to think more in the future and talking more in general. So, wouldn't it be great to have only one font format for everything?

    When a customer is asking you what font format they should use, TTF or CFF, what is your answer? My answer is, it depends on what applications the customer is using in what environment.  

    It's more about a vision. Theoretically a web font is the same like a desktop font. It has the same character set, the same OT features, the same hinting, etc. It's just more compressed. So, why not having a new web font format, which can be used also for desktop? 
    Of cause it wouldn't be backward compatible with older software. But what the heck, why not?!
    To be honest, I am waiting for the first desktop application, what uses web fonts. We have desktop applications to design websites, based on desktop fonts. What makes no sense to me. These apps should use the web fonts which will be used in the website later.

    However, thank you very much for your thoughts.
  • Olli Meier
    Olli Meier Posts: 8
    Mark Simonson Just because it was meant for something different does not mean that it shouldn't be used for something else. PostScript outlines were never meant to be used for screens. It was used for printers. And nowadays CFF fonts are used in basically everything. 

    As mentioned in the comment before. This is more a about thinking in general. So,     wouldn't it be great to have only one font format for everything?
  • Cory Maylett
    Cory Maylett Posts: 248
    edited December 2018
    I think in theory, simple is better, but that's not how things evolve. Let's say everyone did agree on that one, single universal font format. What would happen a year or two down the road when someone different came up with an even newer and better font format? 
    It's not as though there's any one person or company in charge of this kind of thing that can say, "We know what you want and what's best. From now on, everyone will need to switch and conform." Despite the inefficiency, choice and market competition are good; it provides an impetus for improvement.
  • Thomas Phinney
    Thomas Phinney Posts: 2,896
    edited December 2018
    Olli Meier said:
    @Theunis de Jong I know about the different outlines of PostScript and TrueType and I also know about the development/introduction of CFF2. But all developments of new variable font tables or CFF2 improvements are just extra information to the old font formats to keep backward compatibility.
    That is false.

    CFF was originally designed as a standalone font format, a compact version of PostScript Type 1. In OpenType, CFF was repurposed as a means to package that data compactly in the sfnt wrapper used by TrueType. But this created redundant data between the CFF table and other parts of the font. CFF2 deliberately gets rid of the redundancies. Here are the second and third sentences of the CFF2 spec (https://docs.microsoft.com/en-us/typography/opentype/spec/cff2, emphasis added):

    The CFF2 format differs from CFF version 1.0 in that it cannot be used as a stand-alone font program: it is intended for use only in the context of an OpenType font as an 'sfnt' table with the tag CFF2, and depends on data in other OpenType tables. All the data from the 1.0 format that is duplicated by data in other tables, or which is not used in the context of an OpenType font, is removed.
    Now, at the same time, the CFF2 spec was slow to be finalized, and has not been adopted as quickly or widely as one might hope. Almost all variable fonts other than Adobe’s have been done with TTF outlines. I think this evidence that while sometimes desirable in the abstract, a stronger break with the past can also hinder adoption of new technologies.
  • Ray Larabie
    Ray Larabie Posts: 1,435
    Font formats fall into disuse gradually. When I started selling fonts I was expected to provide then in Mac TT, Mac PS, Win TT, Win PS.
  • Khaled Hosny
    Khaled Hosny Posts: 289
    WOFF and WOFF2 are packaging formats, they do not change the underlying font in any functional way, you can see them as more elaborate font compression schemes, and once WOFF2 is widely supported enough WOFF will gradually disappear.
  • Olli Meier
    Olli Meier Posts: 8
    @Khaled Hosny I totally agree. This let's me think about the fact, that browsers don't care about CFF or TTF. A woff or woff2 can be TT based or CFF based.
    Most of the current desktop applications do support both font formats (TTF and CFF), which makes live much easier. But again, why not get rid of the one format and have only one. I know that this thinking is radical and I know that both formats have their benefits. But wouldn't it make live easier? 

    For me TTF makes more sense, when you have low resolution screens and you need a special hinting for small sizes. But the fact is, that this is changing already. We have more and more high res screens.
    Of cause TTF can also have composites, which would make the file size smaller. Also a good argument especially for CJK fonts. But CFF2 will have this feature, too, right?
    TTF fonts can be embedded into MS Word and PowerPoint, but not CFF fonts.

    But nobody wants to draw in TrueType outlines. PostScript hinting is much easier and in many cases totally fine. PostScript hinting is also much more simple and therefor it does not need so much bits and bits.

    Mmmhhh, having said that, it's not that easy. But I still have the feeling that it would be possible to have only one font format – and clean it up.
    When we take a look into the name table for example. Theoretically we have four different platforms, but in fact only one is used (mostly). Even apps on the Mac are using the MS platform and not the Mac. 
  • John Savard
    John Savard Posts: 1,135
    edited December 2018
    Theunis de Jong said:
    OpenType, for example, can digest many more features than currently available; as long as these features can be described in the current rendering model. The most recent major addition, Variable Fonts, cannot
    This is an interesting statement. OpenType was intended as something that would extend TrueType to permit new features - but also to support easy conversion of Adobe Type2 fonts. So presumably OpenType was intended to be the final font format that supported everything.

    A "rendering model" sounds like an implementation characteristic. That is, a new revision of the OpenType font format which allows adding more features ought to be able to add a way to express Variable Fonts. The fact that existing implementations of OpenType would have to be rewritten from the ground up to fully support the new iteration of the spec... is neither here nor there.

    That is, there's no fundamental technical reason why, in effect, they couldn't have slapped the name "Open Type 2.0" (or whatever the next available revision number would be) on CFF... at least, none that I can see. That CFF is equivalent to OTF plus a supplementary CFF 2 file makes that seem even more likely to be the case; there should be room in the OTF format to say, "oh, don't forget the CFF 2 information at the end".
  • John Savard
    John Savard Posts: 1,135
    Olli Meier said:
    I know, that we keep all the old stuff to be always backward compatible. But does this really make sense? 
    I know, that we make more money when we sell different font formats. But is this really user friendly?
    Make up your mind.

    If you stop supporting "all the old stuff to be always backward compatible", then that's exactly when the poor end-user, who had bought fonts in the old font formats, now has to buy the same font again in a new format.
  • Khaled Hosny
    Khaled Hosny Posts: 289
    The name table is a good example of why new streamlined formats don’t magically work; there is format 1 version of the table that can be used without all the legacy platforms stuff, whoever there is virtually no fonts that use format 1 name table.
  • k.l.
    k.l. Posts: 109
    Didn't the creator of the original TT rasterizer do a second version that doesn't need font-level instructions? Why didn't MS license/buy that long ago? Why, instead, does MS require each and every type designer and/or font maker to spend precious life time on instructing fonts? Alternatively, why didn't MS license/buy a highly interesting rasterizer developed ... at a telephone company? These were done at a time when high resolution devices did not even exist. (Some big four should easily afford to opensource either of these so high-quality rasterization, resolution aside, would be available to everyone.)
  • George Thomas
    George Thomas Posts: 647
    edited December 2018
    Some big four should easily afford to opensource either of these so high-quality rasterization, resolution aside, would be available to everyone.
    @KL: It appears you know who they are. Why not approach management with the idea? Maybe form a group of influential designers to show them they would be doing a huge good thing for all people if they did so. Think of the good PR they would get by doing so.
  • James Puckett
    James Puckett Posts: 1,998
    George Thomas said:
    Some big four should easily afford to opensource either of these so high-quality rasterization, resolution aside, would be available to everyone.
    @KL: It appears you know who they are. Why not approach management with the idea? Maybe form a group of influential designers to show them they would be doing a huge good thing for all people if they did so. Think of the good PR they would get by doing so.
    Satya Nadella does claim that he wants Microsoft to be the biggest open source company!
  • Belleve Invis
    Belleve Invis Posts: 269
    On the other hand, assume we need to end this chaos case. Like OT2.0 with B-splines?
    And now we have the third...
    (I agree with that TTF should have a high-level hinting and a compiler to convert HLH downto instr. The only person I know who can write TT instr is @GregHitchcock .)
  • Thomas Phinney
    Thomas Phinney Posts: 2,896
    John Savard said:
    Olli Meier said:
    I know, that we keep all the old stuff to be always backward compatible. But does this really make sense? 
    I know, that we make more money when we sell different font formats. But is this really user friendly?
    Make up your mind.

    If you stop supporting "all the old stuff to be always backward compatible", then that's exactly when the poor end-user, who had bought fonts in the old font formats, now has to buy the same font again in a new format.
    Olli was talking about the people making the fonts. They/us making fonts in a new font format that does not work on older platforms does not force anyone to re-purchase old fonts in the new format.

    I can only assume you are talking about the OS and app vendors dropping support for old versions of fonts. But that is a different question/issue.
  • Jens Kutilek
    Jens Kutilek Posts: 364
    Olli Meier said:
    Most of the current desktop applications do support both font formats (TTF and CFF), which makes live much easier. But again, why not get rid of the one format and have only one. I know that this thinking is radical and I know that both formats have their benefits. But wouldn't it make live easier? 

    For me TTF makes more sense, when you have low resolution screens and you need a special hinting for small sizes.

    But nobody wants to draw in TrueType outlines. PostScript hinting is much easier and in many cases totally fine. PostScript hinting is also much more simple and therefor it does not need so much bits and bits.
    I think you are right. TTF is more widely supported, can be better optimised for screen. So in theory it is the best format available today.

    But it is much easier today to create a ‘perfect’ OT-CFF font. The Adobe autohinter is pretty good, and there’s not much quality to gain by manual hinting. The outlines will always be as good as the designer drew them.

    TTF is, on the other hand, kind of a moving target. It’s hard to produce a general purpose TTF font that isn’t over- or under-engineered. You would need to know the rasteriser which will render the font in order to apply the required amount of hinting. For Office or webfont use, you can make a good guess, but beyond that …

    Not every font can be hinted all the way to pixel-perfect glyphs at all sizes. (I remember actually having to push pixels around in a font not too long ago because it was to be used in a thermo label printer which had an incredibly low resolution. Thankfully it was only used at two specific sizes.)

    Think of embedded systems in a car for example, they may use FreeType with on-the-fly autohinting, so you can forget about the font’s built in hinting, or it may use a rasteriser you haven’t even heard of.

    And the outlines can be anything from an automatic conversion with one of the various algorithms to manually optimised offcurve point placement.
  • Denis Moyogo Jacquerye
    Denis Moyogo Jacquerye Posts: 197
    The only person I know who can write TT instr is @GregHitchcock

    Oh, he’s not the only one. “There are dozens of us... dozens!”

  • Belleve Invis
    Belleve Invis Posts: 269
    edited December 2018
    As for CFF, its stack-based language is a disaster for font implementation, especially for embedded devices. So if you want a new format? Take these features:
    • Plain interpretation (no programming languages)
    • High-level hinting (again, no programming languages)
    • B-splines (fast and reliable C2 curve with kinkless interpolation)
    • Optional: Per-glyph variation
    • Optional: Sub-glyph component sharing
    • Optional: Low-level hinting if really needed
  • Theunis de Jong
    Theunis de Jong Posts: 112
    Belleve Invis said:
    As for CFF, its stack-based language is a disaster for font implementation, especially for embedded devices.
    Theoretically, one can push all parameters for a glyph onto the stack, followed by a long sequence of operands, and I can see how that would stress the stack. But is that really a concern, and something that does happen in practice in current fonts?

    I have looked at lots of CFF data and I cannot recall ever seeing something else than the stack immediately digested by the first command that followed.

    Is your concern based only on the "theoretically" part, i.e., that it is possible, according to the sub-language specification?
  • Belleve Invis
    Belleve Invis Posts: 269
    Theunis de Jong said:
    Belleve Invis said:
    As for CFF, its stack-based language is a disaster for font implementation, especially for embedded devices.
    Theoretically, one can push all parameters for a glyph onto the stack, followed by a long sequence of operands, and I can see how that would stress the stack. But is that really a concern, and something that does happen in practice in current fonts?

    I have looked at lots of CFF data and I cannot recall ever seeing something else than the stack immediately digested by the first command that followed.

    Is your concern based only on the "theoretically" part, i.e., that it is possible, according to the sub-language specification?
    Most CFF operators would clear the entire stack, and one exception is <blend> from CFF2, which could form huge trees of operators by nesting (though the spec said that blend operators should not nest).
    My concern is that the stack-based language made many operations (like pre-allocate glyph points) impossible, so it would complicate the implementation.
  • Dave Crossland
    Dave Crossland Posts: 1,431
    Belleve Invis said: 
    As for CFF, its stack-based language is a disaster for font implementation, especially for embedded devices. So if you want a new format? Take these features:
    • Plain interpretation (no programming languages)
    • High-level hinting (again, no programming languages)
    • B-splines (fast and reliable C2 curve with kinkless interpolation)
    • Optional: Per-glyph variation
    • Optional: Sub-glyph component sharing
    • Optional: Low-level hinting if really needed

    Agreed! A dew years ago I took a shot at enumeratiin the problems with OpenType here:

     https://meta.wikimedia.org/wiki/Future_Global_Font_Format_Requirements

Categories