[MPEG-OTSPEC] Co-existence of glyph rendering source types

[Simon Cozens]

Some thoughts on this:

You need (unfortunately) to stop looking for consistency in the spec. 
That's a horrible thing to have to say, but it's true, and it's an 
artefact of the way that the spec has been edited and expanded. New 
"glyph representation formats" (in CommonType parlance) have been added 
without the portions of the spec which refer to pre-existing glyph 
representation formats being updated.

So, for example, you quote the very start of the spec, which describes 
what an OFF font file is, and says that it "comprises either a TrueType 
or a Compact Font Format (CFF) outline font". I have interpreted this to 
mean that a conformant font must have one of a glyf table or a CFF 
table, but there is some debate about this. (see 
https://github.com/MicrosoftDocs/typography-issues/issues/583)

This sentence, however, clearly has not been updated since the addition 
of other *vector* glyph representation formats (SVG, CFF2), let alone 
new bitmap glyph representation formats, so it should no longer be 
considered reliable as a commentary on the required glyph representation 
formats in a conformant font file.

One interesting fact is that MSOT did not carry over the bhed table from 
TrueType, and as Peter mentions in the github thread referenced above, 
the TT spec explicitly refers to "sfnt-housed fonts" with only bitmap 
glyph representation formats as *not* conformant TrueType fonts. If this 
logic carries over then Noto Color Emoji is not a conformant OFF font. 
But OFF-conformant rendering software will do the right thing with it, 
so in a sense, who cares?

Speaking of doing the right thing with varied glyph representation 
formats within a font, you might find 
https://simoncozens.github.io/test-fonts/ helpful as a collection of 
rendering experiments with mixed glyph representation formats. The 
question of "which glyph representation format should get priority for 
rendering" is an important one, on which (I think) the spec is silent.

S

On 11/09/2020 23:43, Adam Twardoch (Lists) wrote:
> OpenType currently has provisions for multiple sources for glyph rendering:
> 
> 1. Outlines
> 
> - glyf (optionally with fvar)
> - CFF
> - CFF2 (with or without variations)
> - SVG
> 
> 2. Bitmaps
> 
> - EBDT
> - CBDT (uses PNG)
> - sbix (also uses PNG)
> 
> In the spec, the relationship between these seven flavors is extremely 
> convoluted, and sometimes contradictory.
> 
> https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt> says 
> nothing about whether some other glyph rendering source (e.g. glyf) must 
> or may be present in the font or not.
> 
> https://docs.microsoft.com/en-us/typography/opentype/spec/sbix 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/sbix> says 
> that the font "may also" contain glyf or CFF, but makes no mention of 
> SVG, CBDT or CFF2.
> 
> https://docs.microsoft.com/en-us/typography/opentype/spec/svg 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/svg> says 
> »For every SVG glyph description, there must be a corresponding 
> TrueType, CFF or CFF2 glyph description in the font.« No mention of sbix 
> or CBDT.
> 
> https://docs.microsoft.com/en-us/typography/opentype/spec/otff 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/otff> says » 
> An OpenType font file contains data, in table format, that comprises 
> either a TrueType or a Compact Font Format (CFF) outline font. « By 
> this, one might read that am sbix-only SFNT or a CBDT-only SFNT or an 
> EBDT-only SFNT or perhaps even a CFF2-only SFNT is not an OpenType font.
> 
> The same page says » OpenType fonts that contain TrueType outlines 
> should use the value of 0x00010000 for the sfntVersion. OpenType fonts 
> containing CFF data (version 1 or 2) should use 0x4F54544F ('OTTO', when 
> re-interpreted as a Tag) for sfntVersion.« Here CFF is used as “1 or 2”, 
> while in the SVG spec, CFF is named separately from CFF2 so it must mean 
> "1". Again, no guidance for sbix-only, CBDT-only or EBDT-only fonts.
> 
> Same document: » Required Tables. Whether TrueType or CFF outlines are 
> used in an OpenType font« Again, no word on non-outline fonts 
> (sbix-only, CBDT-only, EBDT-only).
> 
> Same document: » OpenType fonts may also contain bitmaps of glyphs, in 
> addition to outlines.« But the sbix table says outlines are optional. 
> Contradiction?
> 
> In the same document 'maxp' is listed as required in the same way as 
> 'head' is but 
> https://docs.microsoft.com/en-us/typography/opentype/spec/maxp 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/maxp> says » 
> This table establishes the memory requirements for this font. Fonts with 
> CFF data must use Version 0.5 of this table, specifying only the 
> numGlyphs field. Fonts with TrueType outlines must use Version 1.0 of 
> this table, where all data is required.« It’s unclear if “CFF” is 
> inclusive of CFF2 here or not, and it’s unclear what role the table has 
> with bitmap-only fonts.
> 
> Same on
> https://docs.microsoft.com/en-us/typography/opentype/spec/hmtx 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/hmtx> — the 
> description goes into detail about glyf, CFF & CFF2 but makes no 
> reference to bitmap-only fonts.
> 
> Therefore, the spec does not provide sufficient info about which tables 
> should or must be in an outline-less sbix-based, CBDT-based or 
> EBDT-based font.
> 
> https://docs.microsoft.com/en-us/typography/opentype/spec/ebdt 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/ebdt> and
> https://docs.microsoft.com/en-us/typography/opentype/spec/eblc 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/eblc> make no 
> mention of their relationship to the outline formats, or to other bitmap 
> formats.
> 
> https://docs.microsoft.com/en-us/typography/opentype/spec/recom#embedded-bitmaps 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/recom#embedded-bitmaps> 
> explicitly allowes EBDT-only fonts and says that all required tables 
> except glyf and loca should be there. Does that still include maxp & hmtx?
> 
> Since recommendations allow EBDT-only, one could think that CBDT-only is 
> also allowed, because somewhere it says that CBDT uses similar concepts 
> to EBDT. But maybe someone else might think differently.
> 
> sbix and CBDT also make no mention of their relationship with each 
> other, and I think sbix/CBDT are not coordinated either.
> 
> There is a reluctance on some parties’ part to support SVG in fonts, but 
> I can easily see how either CBDT or sbix or both could be used for SVG 
> the same way as EBDT was used for TT outlines — as a hand-tuned 
> representation for small sizes. An engine might prefer the fast PNG 
> rendering for smaller sizes and switch to slower SVG for larger sizes, 
> or if it doesn't have an SVG renderer, it still might render upscaled 
> PNGs from sbix/CBDT (as Apple used to do with sbix-only, and as Google 
> still does with CBDT-only).
> 
> In OFF2, we might do away with EBDT/CBDT entirely. EBDT is no better 
> than sbix, in fact it's worse because it has a max PPM of 127 (!). sbix 
> can be used for all kinds of bitmaps, and its PNGs can be monochrome or 
> grayscale.
> 
> I don't see why OT fonts that have SVG also MUST have glyf/CFF(2), while 
> sbix does not have to have glyf/CFF(2), and EBDT/CBDT also, in practice, 
> doesn't have to have outlines.
> 
> If an sbix-only font (without glyf/CFF(2)) is valid (at least some part 
> of the spec suggests it is), then a font with sbix and SVG but without 
> glyf or CFF(2) also should be valid, bit isn't.
> 
> Finally, I don't think it's clear whether a CFF2 table and a CFF table 
> can or cannot co-exist in the same font.
> 
> https://docs.microsoft.com/en-us/typography/opentype/spec/recom 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/recom> says 
> »Mixing Outline Formats
> Both Microsoft and Adobe recommend against mixing outline formats within 
> a single font. Choose the format that meets your feature requirements.«
> 
> But of course...
> https://docs.microsoft.com/en-us/typography/opentype/spec/otff 
> <https://docs.microsoft.com/en-us/typography/opentype/spec/otff> lists 
> “SVG Outlines” as the 3rd kind of outlines next to “TrueType Outlines” 
> and “CFF Outlines”, and the SVG table spec says you *must* mix SVG 
> Outlines with either TT or CFF outlines, so obviously that 
> recommendation is, uh, err... 😁
> 
> I hope we can clarify these relationships.
> 
> A.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>