OT file extension recommendation

[tiroj]

I also suggest we only encouraging one ("otf") and discontinue the distinction between glyf-flavored and CFF-flavored fonts.

Agree with this. Literally the whole point of OT is that you can have different outlines within the font and the end user doesn't have to care. People still talk about "OTFs" versus "TTFs" as if they're separate things, when they're really just talking about implementation details within OpenType, and it's not helpful.

Originally posted by @simoncozens in https://github.com/MicrosoftDocs/typography-issues/issues/508#issuecomment-684618643

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 6a1bda96-a268-b684-6cea-9b0c7be6f24e
• Version Independent ID: 36485fec-f05d-3984-6da8-ff2dd2799041
• Content: OpenType font file - Typography
• Content Source: typographydocs/opentype/spec/otff.md
• Product: typography
• GitHub Login: @PeterCon
• Microsoft Alias: PeterCon

[tiroj]

Background In the late 1990s, the reason for the .ttf vs .otf file extension split was that CFF OT fonts were an entirely new format that required new rendering implementation in software, while TTF OT fonts were backwards compatible—with limitations regarding OT Layout support, of course—with older systems, which would treat them as TrueType fonts. So we all got into the habit of using .ttf for the TrueType flavour fonts, and .otf for the CFF flavour fonts, even though this tended to confuse users.

2020 My inclination is that we can probably recommend .otf (and .otc) as the file extension for any OT font regardless of flavour, but add a note regarding use of .ttf and (.ttc) for backwards compatibility with ancient systems.

[PeterCon]

This change in recommendation would have small impact for tools/apps, but it could have a big impact for font vendors and their customers. I'd like to see broad input from that segment (in addition to platform/app/tool vendors). Perhaps open a discussion on TypeDrawers, in the Type Business category?

I'm going to set the priority to Future, meaning for a release after 1.8.4.

[simoncozens]

Oddly I was just thinking about this very issue in relation to something else.

Another issue is that "a .ttf file" is now ambiguous. It could be a TrueType file or it could be an MSOT file. MSOT is not a complete superset of TrueType, so something could be a "valid .ttf" which is a valid TrueType file but not valid MSOT file - another good reason to avoid calling MSOT files ".ttf".

[tiroj]

A lot of font vendors offer both flavours of OT fonts, either as independent license products or including both flavours in packages so the user can select which to use. Simon wrote

Literally the whole point of OT is that you can have different outlines within the font and the end user doesn't have to care.

but in fact users have always cared because TTF and CFF have different virtues and vices, and have worked better or worse in different environments and even at different sizes (as I recall, TypeKit was serving different flavours of webfonts for text and display).

So I'm inclined to agree with Peter that this is something that should be discussed within the type community.

[khaledhosny]

User confusion (and developer confusion) about the difference between .ttf and .otf uis rather prelevant, and there are still a considerable chunk of people who thing .ttf → TrueType → no OpenType layout, and .otf → OpenType → OpenType layout.

The sfntVersion is another source of confusion, so I agree with Behdad comment on the other issue that it should always be OTTO. Other values supported by implmentations should be documented as legacy (0x00010000 and true).

[khaledhosny]

OpenType now has a lot more than two glyphs representation tables, so signaling out glyf/CFF is not helping.

[simoncozens]

It still has the concept (I believe) of a primary outline representation format. I don’t think a MSOT font is valid without at least glyf, CFF or CFF2. (I don’t know if this is formally documented outside of CommonType yet or just de facto.) So SVG or the bitmap formats are secondary glyph representation formats, but talking about glyf/CFF(/CFF2) does make sense.

[simoncozens]

This page is very relevant to this discussion: https://simoncozens.github.io/test-fonts/

[khaledhosny]

Using sfntVersion to detect whether the fonts has glyf/loca or CFF table is still redundant since the presence or absence of these tables can be checked for already (and the sfntVersion can’t be blindly trusted anyway). They don’t need this special privilege. Any decision based on sfntVersion is redundant at best, misguided at worst. But it is probably a too much of a breaking change for current OpenType spec.

[behdad]

I don’t think a MSOT font is valid without at least glyf, CFF or CFF2.

Huh? The CBDT/CLBC fonts like Noto Color Emoji don't have a glyf/CFF/CFF2.

[PeterConstable]

I'm not sure if the OT spec, up to now, has had a clear statement on whether an "OpenType font" could be bitmap-only. Apple's TT spec appears to state that a bitmap-only font is not considered a TT font:

Table 2: The required tables

Tag	Table
'cmap'	character to glyph mapping
'glyf'	glyph data
'head'	font header
'hhea'	horizontal header
'hmtx'	horizontal metrics
'loca'	index to location
'maxp'	maximum profile
'name'	naming
'post'	PostScript

…

Warning! Apple makes a distinction between a "TrueType font" (which refers to a particular font outline definition technology) and an "sfnt-housed font," which refers to any font which uses the same packaging format as a TrueType font: that is, it uses the same directory structure and the same table format and meaning for any tables present.

This is an important distinction, because Apple supports other varieties of sfnt-housed font on OS X and iOS, most notably bitmap-only fonts and OpenType fonts. Informally, people often refer to any sfnt-housed font as a "TrueType font," but this is strictly speaking inaccurate.

Unlike Apple's TT spec, the OT spec hasn't listed 'glyf' or 'CFF' as required tables—understandable since OT (vs. TTO) allowed one or the other outline format. On the other hand, it does have this statement in the intro to the OT Font File chapter:

An OpenType font file contains data, in table format, that comprises either a TrueType or a PostScript outline font.

It's unambiguous that the CBDT and CBLC can be considered OT tables. But less clear whether, by strict terms of the current spec, whether a font with bitmap tables but not glyf/CFF/CFF2 is an "OpenType font".

I'd be happy to see discussion on that point. But it's a separate issue from this issue regarding file extension recommendations.

[behdad]

Note that in the Free Software world, when we dropped support for non-OT fonts, we told people they can use EBDT-only fonts to convert their bitmap fonts into OT. Some even started using .otb to refer to those. I think that's a legitimate use of the format.