Add check: `meta` table with `dlng` and `slng` structures

The OpenType meta originated at Apple. Microsoft added it to OT with just two DataMap records:

• dlng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font is designed for
• slng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font supports

The slng structure is intended to describe which languages and scripts the font overall supports. For example, a Traditional Chinese font that also contains Latin characters, can indicate Hant,Latn, showing that it supports Hant, the Traditional Chinese variant of the Hani script, and it also supports the Latn script

The dlng structure is far more interesting. A font may contain various glyphs, but only a particular subset of the glyphs may be truly “leading” in the design, while other glyphs may have been included for technical reasons. Such a Traditional Chinese font could only list Hant there, showing that it’s designed for Traditional Chinese, but the font would omit Latn, because the developers don’t think the font is really recommended for purely Latin-script use.

The tags used in the structures can comprise just script, or also language and script. For example, if a font has Bulgarian Cyrillic alternates in the locl feature for the cyrl BGR OT languagesystem, it could also indicate in dlng explicitly that it supports bul-Cyrl. (Note that the scripts and languages in meta use the ISO language and script codes, not the OpenType ones).

For example, the Windows 10-bundled Phags Pa font has this meta table:

<?xml version="1.0" encoding="UTF-8"?>
<ttFont sfntVersion="\x00\x01\x00\x00" ttLibVersion="4.24">

  <meta>
    <text tag="dlng">
      Phag
    </text>
    <text tag="slng">
      Phag,Latn
    </text>
  </meta>

</ttFont>

Font making tools should fill the slng structure algorithmically. We will develop some tool that does that.

The dlng structure should be filled manually, perhaps as a developer-controlled subset of the entries that the tool puts into slng.

@davelab6 suggests that Font Bakery should check if the font has the meta table and if the meta table contains the slng and dlng structures.

As the second step, we should develop a mechanism for creating those entries automatically, at least for slng (and also verifying the info that’s already in the font).

I think all GF fonts should be amended to contain the meta table. Windows 10 already uses it when deciding on which fonts to fall back to. The GF API and also other environments could use the data for smarter filtering. Most importantly, those entries should be added to the Noto fonts.

In the font making process, some environments store this data in external files already. But the meta table provides a convenient way to store this inside the font file, so some tools may add the data, and unrelated tools may read this data. This makes the solution much more portable and universal.

[bobh0303]

We’ve been interested in the meta table since MS added slng and dlng, but I’m curious:

• Is there any software other than MS Font view that actually uses these fields?
• Do we now have round-trip UFO workflow support in fontTools and glyphsLib?

[felipesanches]

@twardoch I labeled it 3/10 severity. Please let me know if you disagree 😉