-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eczar: Version 2.000 added #4321
Conversation
* Eczar Version 2.000 taken from the upstream repo https://github.com/rosettatype/eczar at commit rosettatype/eczar@f248ec9.
Fontbakery reportFontbakery version: 0.8.6 [10] Eczar[wght].ttf🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.
🔥 FAIL: Check upstream.yaml file contains all required fields--- Rationale --- If a family has been pushed using the gftools packager, we must check that all the required fields in the upstream.yaml file have been populated.
🔥 FAIL: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: DESCRIPTION.en_us.html should end in a linebreak.--- Rationale --- Some older text-handling tools sometimes misbehave if the last line of data in a text file is not terminated with a newline character (also known as '\n'). We know that this is a very small detail, but for the sake of keeping all DESCRIPTION.en_us.html files uniformly formatted throughout the GFonts collection, we chose to adopt the practice of placing this final linebreak char on them.
⚠ WARN: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ WARN: A static fonts directory with at least two fonts must accompany variable fonts--- Rationale --- Variable font family directories kept in the google/fonts git repo may include a static/ subdir containing static fonts. These files are meant to be served for users that still lack support for variable fonts in their web browsers.
⚠ WARN: Does the font contain less than 40 CJK characters?--- Rationale --- Hangul has 40 characters and it's the smallest CJK writing system. If a font contains less CJK glyphs than this writing system, we inform the user that some glyphs may be encoded incorrectly.
⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table.--- Rationale --- 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.
⚠ WARN: Check font contains no unreachable glyphs--- Rationale --- Glyphs are either accessible directly through Unicode codepoints or through substitution rules. Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.
⚠ WARN: Does the font contain chws and vchw features?--- Rationale --- The W3C recommends the addition of chws and vchw features to CJK fonts to enhance the spacing of glyphs in environments which do not fully support JLREQ layout rules. The chws_tool utility (https://github.com/googlefonts/chws_tool) can be used to add these features automatically.
Summary
Note: The following loglevels were omitted in this report:
|
2c39a75: [gftools-packager] Eczar: Version 2.000 added