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

[Adam Twardoch (Lists)]

Ps. In my world, OFF2 would bring down the number of flavors to just 4:
glyf (TT, optionally also cubic), CFF2 (for political reasons), SVG and
sbix.

Drop EBDT, CBDT and CFF.

On Sat, 12 Sep 2020 at 00:43, Adam Twardoch (Lists) <list.adam at twardoch.com>
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 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 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 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 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 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 — 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 and
> 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
> 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 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 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200912/ad489845/attachment.html>