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

Adam Twardoch (Lists) list.adam at twardoch.com
Sat Sep 12 00:43:28 CEST 2020


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/52be7e66/attachment.html>


More information about the mpeg-otspec mailing list