Bungee Tint - Reported Warns

[vv-monsalve]

Hi @justvanrossum, Bungee Tint is reporting a couple of Warns, bringing here the main ones.

• Please review and ensure the mark glyph class includes the reported marks.

⚠️ WARN Check mark characters are in GDEF mark glyph class.

> > Mark characters should be in the GDEF mark glyph class. > > Original proposal: https://github.com/fonttools/fontbakery/issues/2877

• ⚠️ WARN

  The following mark characters could be in the GDEF mark glyph class:
  horncmb (U+031B)

  
  [code: mark-chars]

[vv-monsalve]

⚠️ WARN Ensure fonts have ScriptLangTags declared on the 'meta' table.

> > The OpenType 'meta' table 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). > > This check ensures that the font has the meta table containing the > slng and dlng structures. > > All families in the Google Fonts collection should contain the 'meta' table. > Windows 10 already uses it when deciding on which fonts to fall back to. > The Google Fonts 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. >

Original proposal: fonttools/fontbakery#3349

• ⚠️ WARN

  This font file does not have a 'meta' table.

  
  [code: lacks-meta-table]

[justvanrossum]

Ouch, I did add the public.openTypeMeta info to the sources, but they were ignored in the assemble phase. Fixing.

[justvanrossum]

Do you have an idea how to fix the horncmb / GDEF warning?

[vv-monsalve]

Do you have an idea how to fix the horncmb / GDEF warning?

The comb marks need to have anchors to be listed as class 3 in GDEF by Fontmake. However, after inspecting the file, I've seen the composite glyphs are decomposed, so I think we could leave it like that and wait for users' feedback if they need another accented letter using it. In that case, it would probably be needed to create the composite ':D

[justvanrossum]

Additionally, I think the warn comes from the fact that "horncmb" does have a _horn anchor in the source, but there isn't a single glyph with a horn anchor to attach it to. That possibly causes fontmake to not mark it as class 3.

So, ok to close this issue? The "meta" table problem has been resolved with #118.

[vv-monsalve]

So if there is no base glyph using it, I wonder if FM is not even including the anchor in the glyph. Reviewing this again, yes, the source have the anchor, but inspecting the font the anchor is not in there, and FB checks only the binaries.

So yes, I think we can close this issue.

[justvanrossum]

FB probably decides on the “cmb” aspect that it should be class 3, regardless of anchors.