Font serialization variations

[inexorabletash]

When a font (e.g. "Optima-Bold") is provided through the API, whether the source is the OS or a locally installed font, the actual data of the font may vary across browsers, OSes, or even time on the same device.

• The font could be a non-OpenType version (e.g. Type 1, SVG, or some other format). See Non-OpenType fonts #19
• The font could be a future format that is not serialized using SFNT
• The font could be an alternate version from a different foundry.
• The font could include bug fixes or improvements
• The font could include additional data, e.g. expanded to include glyphs from other scripts, etc
  ... and much much more!

There is the case where the underlying font data is actually identical, but the SFNT serialization has changed in ways such that the files are not byte-identical, e.g. the tables are in a different order, or e.g. within the name table the entries are in a different order.

Do we need browsers to normalize this? Or is this the equivalent of e.g. a JPEG/JFIF file having markers in an undefined order when uploading <input type=file>?

The expected use case is that font data is parsed with a small number of robust libraries (e.g. HarfBuzz and FreeType) which conceal this from the calling code, so for most API users this will not be an issue.

[rcombs]

vary across browsers

Which cases are you expecting this to happen in? TTC handling, maybe? I would expect that for regular TTF or OTF files, the browser would simply hand the caller the contents of the on-disk file.

[inexorabletash]

vary across browsers

Which cases are you expecting this to happen in? TTC handling, maybe? I would expect that for regular TTF or OTF files, the browser would simply hand the caller the contents of the on-disk file.

That's my expectation as well for most implementations. But I could imagine a UA that does things differently, e.g. a UA that bundles a set of fonts, and the font data for those evolves over time e.g. to support new writing scripts.