Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Preparing Braah for Google Fonts #1

Closed
yanone opened this issue Dec 6, 2022 · 26 comments
Closed

Preparing Braah for Google Fonts #1

yanone opened this issue Dec 6, 2022 · 26 comments

Comments

@yanone
Copy link

yanone commented Dec 6, 2022

Hello. I've been commissioned to onboard Braah for release on Google Fonts.

The font file needs to conform to Google Fonts specifications, and I've found numerous instances where that's not the case.

Please go through the following list of warning and failures and address them. FAILs are critical to address, while for the WARNs I'd make sure to address at least the vertical metrics and the GDEF mark definitions warnings.

Please read the Google Fonts Guidelines for details on how to fix various situations, or ask me if you need any help.

You can re-generate the below report yourself after making changes using fontbakery check-googlefonts -j -F -l FAIL Braah.ttf (install with pip install fontbakery

Please let me know if you need any assistance.
Cheers

Fontbakery report

Fontbakery version: 0.8.11a7.dev18+g12b78f05

[20] Braah.ttf
🔥 FAIL: Checking file is named canonically. (com.google.fonts/check/canonical_filename)

A font's filename must be composed as "-.ttf":

  • Nunito-Regular.ttf

  • Oswald-BoldItalic.ttf

Variable fonts must list the axis tags in alphabetical order in square brackets and separated by commas:

  • Roboto[wdth,wght].ttf

  • Familyname-Italic[wght].ttf

  • 🔥 FAIL Expected "Braah-Regular.ttf. Got Braah.ttf. [code: bad-filename]
🔥 FAIL: Check Google Fonts glyph coverage. (com.google.fonts/check/glyph_coverage)

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 Missing required codepoints:

    • 0x0102 (LATIN CAPITAL LETTER A WITH BREVE)

    • 0x0100 (LATIN CAPITAL LETTER A WITH MACRON)

    • 0x0104 (LATIN CAPITAL LETTER A WITH OGONEK)

    • 0x0106 (LATIN CAPITAL LETTER C WITH ACUTE)

    • 0x010A (LATIN CAPITAL LETTER C WITH DOT ABOVE)

    • 0x0116 (LATIN CAPITAL LETTER E WITH DOT ABOVE)

    • 0x0112 (LATIN CAPITAL LETTER E WITH MACRON)

    • 0x0118 (LATIN CAPITAL LETTER E WITH OGONEK)

    • 0x011E (LATIN CAPITAL LETTER G WITH BREVE)

    • 0x0122 (LATIN CAPITAL LETTER G WITH CEDILLA)

    • 0x0120 (LATIN CAPITAL LETTER G WITH DOT ABOVE)

    • 0x0126 (LATIN CAPITAL LETTER H WITH STROKE)

    • 0x0132 (LATIN CAPITAL LIGATURE IJ)

    • 0x0130 (LATIN CAPITAL LETTER I WITH DOT ABOVE)

    • 0x012A (LATIN CAPITAL LETTER I WITH MACRON)

    • 0x012E (LATIN CAPITAL LETTER I WITH OGONEK)

    • 0x0136 (LATIN CAPITAL LETTER K WITH CEDILLA)

    • 0x0139 (LATIN CAPITAL LETTER L WITH ACUTE)

    • 0x013D (LATIN CAPITAL LETTER L WITH CARON)

    • 0x013B (LATIN CAPITAL LETTER L WITH CEDILLA)

    • 0x0143 (LATIN CAPITAL LETTER N WITH ACUTE)

    • 0x0145 (LATIN CAPITAL LETTER N WITH CEDILLA)

    • 0x014A (LATIN CAPITAL LETTER ENG)

    • 0x0150 (LATIN CAPITAL LETTER O WITH DOUBLE ACUTE)

    • 0x014C (LATIN CAPITAL LETTER O WITH MACRON)

    • 0x0154 (LATIN CAPITAL LETTER R WITH ACUTE)

    • 0x0156 (LATIN CAPITAL LETTER R WITH CEDILLA)

    • 0x015A (LATIN CAPITAL LETTER S WITH ACUTE)

    • 0x016C (LATIN CAPITAL LETTER U WITH BREVE)

    • 0x0170 (LATIN CAPITAL LETTER U WITH DOUBLE ACUTE)

    • 0x016A (LATIN CAPITAL LETTER U WITH MACRON)

    • 0x0172 (LATIN CAPITAL LETTER U WITH OGONEK)

    • 0x0174 (LATIN CAPITAL LETTER W WITH CIRCUMFLEX)

    • 0x0176 (LATIN CAPITAL LETTER Y WITH CIRCUMFLEX)

    • 0x0179 (LATIN CAPITAL LETTER Z WITH ACUTE)

    • 0x017B (LATIN CAPITAL LETTER Z WITH DOT ABOVE)

    • 0x0103 (LATIN SMALL LETTER A WITH BREVE)

    • 0x0101 (LATIN SMALL LETTER A WITH MACRON)

    • 0x010B (LATIN SMALL LETTER C WITH DOT ABOVE)

    • 0x0117 (LATIN SMALL LETTER E WITH DOT ABOVE)

    • 0x0113 (LATIN SMALL LETTER E WITH MACRON)

    • 0x011F (LATIN SMALL LETTER G WITH BREVE)

    • 0x0123 (LATIN SMALL LETTER G WITH CEDILLA)

    • 0x0121 (LATIN SMALL LETTER G WITH DOT ABOVE)

    • 0x0127 (LATIN SMALL LETTER H WITH STROKE)

    • 0x0133 (LATIN SMALL LIGATURE IJ)

    • 0x012B (LATIN SMALL LETTER I WITH MACRON)

    • 0x012F (LATIN SMALL LETTER I WITH OGONEK)

    • 0x0237 (LATIN SMALL LETTER DOTLESS J)

    • 0x0137 (LATIN SMALL LETTER K WITH CEDILLA)

    • 0x013A (LATIN SMALL LETTER L WITH ACUTE)

    • 0x013E (LATIN SMALL LETTER L WITH CARON)

    • 0x013C (LATIN SMALL LETTER L WITH CEDILLA)

    • 0x0146 (LATIN SMALL LETTER N WITH CEDILLA)

    • 0x014B (LATIN SMALL LETTER ENG)

    • 0x0151 (LATIN SMALL LETTER O WITH DOUBLE ACUTE)

    • 0x014D (LATIN SMALL LETTER O WITH MACRON)

    • 0x0155 (LATIN SMALL LETTER R WITH ACUTE)

    • 0x0157 (LATIN SMALL LETTER R WITH CEDILLA)

    • 0x016D (LATIN SMALL LETTER U WITH BREVE)

    • 0x0171 (LATIN SMALL LETTER U WITH DOUBLE ACUTE)

    • 0x016B (LATIN SMALL LETTER U WITH MACRON)

    • 0x0173 (LATIN SMALL LETTER U WITH OGONEK)

    • 0x0175 (LATIN SMALL LETTER W WITH CIRCUMFLEX)

    • 0x0177 (LATIN SMALL LETTER Y WITH CIRCUMFLEX)

    • And 0x0312 (COMBINING TURNED COMMA ABOVE)
      [code: missing-codepoints]

🔥 FAIL: Version format is correct in 'name' table? (com.google.fonts/check/name/version_format)
  • 🔥 FAIL The NameID.VERSION_STRING (nameID=5) value must follow the pattern "Version X.Y" with X.Y greater than or equal to 1.000. Current version string is: "1.000" [code: bad-version-strings]
  • 🔥 FAIL The NameID.VERSION_STRING (nameID=5) value must follow the pattern "Version X.Y" with X.Y greater than or equal to 1.000. Current version string is: "1.000" [code: bad-version-strings]
🔥 FAIL: Copyright notices match canonical pattern in fonts (com.google.fonts/check/font_copyright)
  • 🔥 FAIL Name Table entry: Copyright notices should match a pattern similar to: "Copyright 2019 The Familyname Project Authors (git url)"
    But instead we have got:
    "Copyright (c) 2021 by Ashish Kumar. All rights reserved." [code: bad-notice-format]
  • 🔥 FAIL Name Table entry: Copyright notices should match a pattern similar to: "Copyright 2019 The Familyname Project Authors (git url)"
    But instead we have got:
    "Copyright (c) 2021 by Ashish Kumar. All rights reserved." [code: bad-notice-format]
🔥 FAIL: Check glyphs do not have components which are themselves components. (com.google.fonts/check/glyf_nested_components)

There have been bugs rendering variable fonts with nested components. Additionally, some static fonts with nested components have been reported to have rendering and printing issues.

For more info, see: * fonttools/fontbakery#2961 * arrowtype/recursive#412

  • 🔥 FAIL The following glyphs have components which themselves are component glyphs:
    • tcaron
    • dcaron
    • aogonek
    • cacute
    • eogonek
    • zacute
    • zdotaccent
    • sacute and nacute [code: found-nested-components]
🔥 FAIL: Font enables smart dropout control in "prep" table instructions? (com.google.fonts/check/smart_dropout)

This setup is meant to ensure consistent rendering quality for fonts across all devices (with different rendering/hinting capabilities).

Below is the snippet of instructions we expect to see in the fonts: B8 01 FF PUSHW 0x01FF 85 SCANCTRL (unconditinally turn on dropout control mode) B0 04 PUSHB 0x04 8D SCANTYPE (enable smart dropout control)

"Smart dropout control" means activating rules 1, 2 and 5: Rule 1: If a pixel's center falls within the glyph outline, that pixel is turned on. Rule 2: If a contour falls exactly on a pixel's center, that pixel is turned on. Rule 5: If a scan line between two adjacent pixel centers (either vertical or horizontal) is intersected by both an on-Transition contour and an off-Transition contour and neither of the pixels was already turned on by rules 1 and 2, turn on the pixel which is closer to the midpoint between the on-Transition contour and off-Transition contour. This is "Smart" dropout control.

For more detailed info (such as other rules not enabled in this snippet), please refer to the TrueType Instruction Set documentation.

  • 🔥 FAIL The 'prep' table does not contain TrueType instructions enabling smart dropout control. To fix, export the font with autohinting enabled, or run ttfautohint on the font, or run the gftools fix-nonhinting script. [code: lacks-smart-dropout]
🔥 FAIL: OS/2.fsSelection bit 7 (USE_TYPO_METRICS) is set in all fonts. (com.google.fonts/check/os2/use_typo_metrics)

All fonts on the Google Fonts collection should have OS/2.fsSelection bit 7 (USE_TYPO_METRICS) set. This requirement is part of the vertical metrics scheme established as a Google Fonts policy aiming at a common ground supported by all major font rendering environments.

For more details, read: https://github.com/googlefonts/gf-docs/blob/main/VerticalMetrics/README.md

Below is the portion of that document that is most relevant to this check:

Use_Typo_Metrics must be enabled. This will force MS Applications to use the OS/2 Typo values instead of the Win values. By doing this, we can freely set the Win values to avoid clipping and control the line height with the typo values. It has the added benefit of future line height compatibility. When a new script is added, we simply change the Win values to the new yMin and yMax, without needing to worry if the line height have changed.

  • 🔥 FAIL OS/2.fsSelection bit 7 (USE_TYPO_METRICS) wasNOT set in the following fonts: ['Braah.ttf']. [code: missing-os2-fsselection-bit7]
🔥 FAIL: Checking OS/2 Metrics match hhea Metrics. (com.google.fonts/check/os2_metrics_match_hhea)

OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows.

  • Mac OS X uses the hhea values.
  • Windows uses OS/2 or Win, depending on the OS or fsSelection bit value.

When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them.

But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it.

If users complain and prefer the old broken version, they have the freedom to take care of their own situation.

  • 🔥 FAIL OS/2 sTypoAscender (1000) and hhea ascent (1130) must be equal. [code: ascender]
🔥 FAIL: Description strings in the name table must not contain copyright info. (com.google.fonts/check/name/no_copyright_on_description)
  • 🔥 FAIL Some namerecords with ID=10 (NameID.DESCRIPTION) containing copyright info should be removed (perhaps these were added by a longstanding FontLab Studio 5.x bug that copied copyright notices to them.) [code: copyright-on-description]
⚠ WARN: Checking OS/2 achVendID. (com.google.fonts/check/vendor_id)

Microsoft keeps a list of font vendors and their respective contact info. This list is updated regularly and is indexed by a 4-char "Vendor ID" which is stored in the achVendID field of the OS/2 table.

Registering your ID is not mandatory, but it is a good practice since some applications may display the type designer / type foundry contact info on some dialog and also because that info will be visible on Microsoft's website:

https://docs.microsoft.com/en-us/typography/vendors/

This check verifies whether or not a given font's vendor ID is registered in that list or if it has some of the default values used by the most common font editors.

Each new FontBakery release includes a cached copy of that list of vendor IDs. If you registered recently, you're safe to ignore warnings emitted by this check, since your ID will soon be included in one of our upcoming releases.

  • ⚠ WARN OS/2 VendorID is 'PYRS', a font editor default. If you registered it recently, then it's safe to ignore this warning message. Otherwise, you should set it to your own unique 4 character code, and register it with Microsoft at https://www.microsoft.com/typography/links/vendorlist.aspx
    [code: bad]
⚠ WARN: Are there caret positions declared for every ligature? (com.google.fonts/check/ligature_carets)

All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering.

If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.

  • ⚠ WARN This font lacks caret position values for ligature glyphs on its GDEF table. [code: lacks-caret-pos]
⚠ WARN: Is there kerning info for non-ligated sequences? (com.google.fonts/check/kerning_for_non_ligated_sequences)

Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg impallari/Raleway#14).

  • ⚠ WARN GPOS table lacks kerning info for the following non-ligated sequences:

    • f + f

    • f + i

    • i + f

    • f + l

    • l + f

    • And i + l [code: lacks-kern-info]

⚠ WARN: Check font follows the Google Fonts vertical metric schema (com.google.fonts/check/vertical_metrics)

This check generally enforces Google Fonts’ vertical metrics specifications. In particular: * lineGap must be 0 * Sum of hhea ascender + abs(descender) + linegap must be between 120% and 200% of UPM * Warning if sum is over 150% of UPM

The threshold levels 150% (WARN) and 200% (FAIL) are somewhat arbitrarily chosen and may hint at a glaring mistake in the metrics calculations or UPM settings.

Our documentation includes further information: https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics

  • ⚠ WARN We recommend the absolute sum of the hhea metrics should be between 1.2-1.5x of the font's upm. This font has 1.662x (1662) [code: bad-hhea-range]
⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table. (com.google.fonts/check/meta/script_lang_tags)

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 This font file does not have a 'meta' table. [code: lacks-meta-table]
⚠ WARN: Check font contains no unreachable glyphs (com.google.fonts/check/unreachable_glyphs)

Glyphs are either accessible directly through Unicode codepoints or through substitution rules.

In Color Fonts, glyphs are also referenced by the COLR table.

Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.

  • ⚠ WARN The following glyphs could not be reached by codepoint or substitution rules:

    • DiaComma

    • HaHalantMatraU.gm

    • HaHalantMatraUu.gm

    • HaHalantVirama.gm

    • RaHalantMatraU.gm

    • RaHalantMatraUu.gm

    • RaHalantVirama.gm

    • UdaatMatraU.gm

    • UdaatMatraUu.gm

    • UdaatVirama.gm

    • VaHalantMatraU.gm

    • VaHalantMatraUu.gm

    • VaHalantVirama.gm

    • YakashMatraU.gm

    • YakashMatraUu.gm

    • YakashVirama.gm

    • capacute

    • capcaron

    • capcircumflex

    • caphungarumlaut

    • And capring
      [code: unreachable-glyphs]

⚠ WARN: Check if each glyph has the recommended amount of contours. (com.google.fonts/check/contour_count)

Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story.

However, a quotedbl should have 2 contours, unless the font belongs to a display family.

This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.

  • ⚠ WARN This font has a 'Soft Hyphen' character (codepoint 0x00AD) which is supposed to be zero-width and invisible, and is used to mark a hyphenation possibility within a word in the absence of or overriding dictionary hyphenation. It is mostly an obsolete mechanism now, and the character is only included in fonts for legacy codepage coverage. [code: softhyphen]
  • ⚠ WARN This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct.

The following glyphs do not have the recommended number of contours:

- Glyph name: uni00AD	Contours detected: 1	Expected: 0

- Glyph name: aogonek	Contours detected: 3	Expected: 2

- Glyph name: eogonek	Contours detected: 3	Expected: 2

- Glyph name: uni25CC	Contours detected: 8	Expected: 16 or 12

- Glyph name: aogonek	Contours detected: 3	Expected: 2

- Glyph name: eogonek	Contours detected: 3	Expected: 2

- Glyph name: fi	Contours detected: 2	Expected: 3

- Glyph name: uni00AD	Contours detected: 1	Expected: 0 

- And Glyph name: uni25CC	Contours detected: 8	Expected: 16 or 12

[code: contour-count]

⚠ WARN: Does the font have a DSIG table? (com.google.fonts/check/dsig)

Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products.

As we approach the EOL date, it is now considered better to completely remove the table.

But if you still want your font to support OpenType features on Office 2013, then you may find it handy to add a fake signature on a placeholder DSIG table by running one of the helper scripts provided at https://github.com/googlefonts/gftools

Reference: fonttools/fontbakery#1845

  • ⚠ WARN This font has a digital signature (DSIG table) which is only required - even if only a placeholder - on old programs like MS Office 2013 in order to work properly.
    The current recommendation is to completely remove the DSIG table. [code: found-DSIG]
⚠ WARN: Check mark characters are in GDEF mark glyph class. (com.google.fonts/check/gdef_mark_chars)

Mark characters should be in the GDEF mark glyph class.

  • ⚠ WARN The following mark characters could be in the GDEF mark glyph class:
    acutecomb (U+0301), dotbelowcomb (U+0323), gravecomb (U+0300), hookabovecomb (U+0309), tildecomb (U+0303), uni0302 (U+0302), uni0304 (U+0304), uni0306 (U+0306), uni0307 (U+0307), uni0308 (U+0308), uni030A (U+030A), uni030B (U+030B), uni030C (U+030C), uni031B (U+031B), uni0324 (U+0324), uni0326 (U+0326), uni0327 (U+0327), uni0328 (U+0328), uni032E (U+032E), uni0331 (U+0331), uni0A01 (U+0A01), uni0A02 (U+0A02), uni0A3C (U+0A3C), uni0A41 (U+0A41), uni0A42 (U+0A42), uni0A47 (U+0A47), uni0A48 (U+0A48), uni0A4B (U+0A4B), uni0A4C (U+0A4C), uni0A51 (U+0A51), uni0A70 (U+0A70), uni0A71 (U+0A71) and uni0A75 (U+0A75) [code: mark-chars]
⚠ WARN: Do any segments have colinear vectors? (com.google.fonts/check/outline_colinear_vectors)

This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident.

This check is not run for variable fonts, as they may legitimately have colinear vectors.

  • ⚠ WARN The following glyphs have colinear vectors:

    • M (U+004D): L<<619.0,402.0>--<614.0,385.0>> -> L<<614.0,385.0>--<494.0,60.0>>

    • W (U+0057): L<<215.0,636.0>--<293.0,221.0>> -> L<<293.0,221.0>--<295.0,200.0>>

    • W (U+0057): L<<559.0,626.0>--<674.0,221.0>> -> L<<674.0,221.0>--<678.0,200.0>>

    • W (U+0057): L<<682.0,200.0>--<684.0,221.0>> -> L<<684.0,221.0>--<759.0,636.0>>

    • Wacute (U+1E82): L<<215.0,636.0>--<293.0,221.0>> -> L<<293.0,221.0>--<295.0,200.0>>

    • Wacute (U+1E82): L<<559.0,626.0>--<674.0,221.0>> -> L<<674.0,221.0>--<678.0,200.0>>

    • Wacute (U+1E82): L<<682.0,200.0>--<684.0,221.0>> -> L<<684.0,221.0>--<759.0,636.0>>

    • Wdieresis (U+1E84): L<<215.0,636.0>--<293.0,221.0>> -> L<<293.0,221.0>--<295.0,200.0>>

    • Wdieresis (U+1E84): L<<559.0,626.0>--<674.0,221.0>> -> L<<674.0,221.0>--<678.0,200.0>>

    • Wdieresis (U+1E84): L<<682.0,200.0>--<684.0,221.0>> -> L<<684.0,221.0>--<759.0,636.0>>

    • Wgrave (U+1E80): L<<215.0,636.0>--<293.0,221.0>> -> L<<293.0,221.0>--<295.0,200.0>>

    • Wgrave (U+1E80): L<<559.0,626.0>--<674.0,221.0>> -> L<<674.0,221.0>--<678.0,200.0>>

    • Wgrave (U+1E80): L<<682.0,200.0>--<684.0,221.0>> -> L<<684.0,221.0>--<759.0,636.0>>

    • uni1E42 (U+1E42): L<<619.0,402.0>--<614.0,385.0>> -> L<<614.0,385.0>--<494.0,60.0>>

    • w (U+0077): L<<426.0,318.0>--<424.0,308.0>> -> L<<424.0,308.0>--<337.0,0.0>>

    • w (U+0077): L<<515.0,0.0>--<428.0,308.0>> -> L<<428.0,308.0>--<426.0,318.0>>

    • wacute (U+1E83): L<<426.0,318.0>--<424.0,308.0>> -> L<<424.0,308.0>--<337.0,0.0>>

    • wacute (U+1E83): L<<515.0,0.0>--<428.0,308.0>> -> L<<428.0,308.0>--<426.0,318.0>>

    • wdieresis (U+1E85): L<<426.0,318.0>--<424.0,308.0>> -> L<<424.0,308.0>--<337.0,0.0>>

    • wdieresis (U+1E85): L<<515.0,0.0>--<428.0,308.0>> -> L<<428.0,308.0>--<426.0,318.0>>

    • wgrave (U+1E81): L<<426.0,318.0>--<424.0,308.0>> -> L<<424.0,308.0>--<337.0,0.0>>

    • And wgrave (U+1E81): L<<515.0,0.0>--<428.0,308.0>> -> L<<428.0,308.0>--<426.0,318.0>> [code: found-colinear-vectors]

⚠ WARN: Do outlines contain any jaggy segments? (com.google.fonts/check/outline_jaggy_segments)

This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.

  • ⚠ WARN The following glyphs have jaggy segments:

    • W (U+0057): L<<491.0,355.0>--<488.0,377.0>>/L<<488.0,377.0>--<486.0,355.0>> = 12.959594926160142

    • Wacute (U+1E82): L<<491.0,355.0>--<488.0,377.0>>/L<<488.0,377.0>--<486.0,355.0>> = 12.959594926160142

    • Wdieresis (U+1E84): L<<491.0,355.0>--<488.0,377.0>>/L<<488.0,377.0>--<486.0,355.0>> = 12.959594926160142

    • And Wgrave (U+1E80): L<<491.0,355.0>--<488.0,377.0>>/L<<488.0,377.0>--<486.0,355.0>> = 12.959594926160142 [code: found-jaggy-segments]


Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 9 11 125 8 80 0
0% 4% 5% 54% 3% 34% 0%

Note: The following loglevels were omitted in this report:

  • SKIP
  • INFO
  • PASS
  • DEBUG
@artandtype
Copy link
Owner

artandtype commented Dec 6, 2022 via email

@artandtype
Copy link
Owner

artandtype commented Dec 13, 2022 via email

@yanone
Copy link
Author

yanone commented Dec 23, 2022

You replied by email, so the image you attached didn't come through. (Do reply Github directly whenever possible by following the "view it on GitHub" link at the bottom of the email)

Make sure you're using Python 3, that's all I can say from here. Please follow up with further information about your problem.

@artandtype
Copy link
Owner

artandtype commented Dec 24, 2022 •
edited
Loading

Hello Yanone,
I was able to install fontbakery and run tests.
I'm still getting a 'FAIL' and facing difficulties in resolving it.
Please take a look at the report I've included below and guide me on how to fix this.

$ fontbakery check-googlefonts -j -F -l FAIL Braah-Regular.ttf
Start ... running 227 individual check executions.

com.google.fonts/check/integer_ppem_if_hinted
PPEM must be an integer on hinted fonts.
with Braah-Regular.ttf

  Rationale:

  Hinted fonts must have head table flag bit 3 set.

  Per https://docs.microsoft.com/en-us/typography/opentype/spec/head, bit 3
  of Head::flags decides whether PPEM should be rounded. This bit should
  always be set for hinted fonts.

  Note: Bit 3 = Force ppem to integer values for all internal scaler math;
  May use fractional ppem sizes if this bit is clear;


 FAIL This is a hinted font, so it must have bit 3 set on
      the flags of the head table, so that PPEM values will be rounded into
      an integer value.

      This can be accomplished by using the 'gftools fix-hinting' command.

      +--------------------------------------------------------------------+
      |                         create virtualenv                          |
      +--------------------------------------------------------------------+

      python3 -m venv venv

      +--------------------------------------------------------------------+
      |                        activate virtualenv                         |
      +--------------------------------------------------------------------+

      source venv/bin/activate

      +--------------------------------------------------------------------+
      |                          install gftools                           |
      +--------------------------------------------------------------------+

      pip install git+https://github.com/googlefonts/tools [code:
      bad-flags]


Result: FAIL

Total:

ERROR: 0
FAIL: 1
WARN: 10
INFO: 8
SKIP: 114
PASS: 94

@artandtype artandtype mentioned this issue Dec 24, 2022
Closed
9 tasks
@yanone
Copy link
Author

yanone commented Jan 19, 2023

Okay, so there are two ways forward:

  1. You could fix this yourself if you're familiar with using the command line by following the steps as described in the FAIL. I'll simplify it for you: First you install gftools with pip install gftools, then you run gftools fix-hinting Braah-Regular.ttf. It will create a new file with a .fix ending (overwriting the existing one), which you then need to rename back to Braah-Regular.ttf.
  2. I'll do it for you and send you a Pull Request which you need to merge into your repository.

But there is more work to be done on the repository itself. It needs to (or rather: should) follow a certain folder structure, and it needs an OFL.txt license file, and a description HTML file.

I can do all of that for you and include it into the Pull Request if you like. I'm getting paid to do this kind of work, so it's really no problem. Unless you want to do it yourself out of curiosity. Then please follow these three pages in the GF Guide:

https://googlefonts.github.io/gf-guide/upstream.html
https://googlefonts.github.io/gf-guide/readmefile.html
https://googlefonts.github.io/gf-guide/description.html

In any case I need to ask you to fill the README file and description file for me, but at least I could create them as dummy files for you and you fill them.

Let me know how you want to proceed and please don't hesitate if you have more questions.

@yanone
Copy link
Author

yanone commented Jan 19, 2023

Also I would like to draw your attention to the width of the space. Is it maybe too narrow?
If you look at the attached screenshot, I find the word space too narrow, even for the Latin, especially when compared to the small size text in the text field at the top of the screenshot.

Maybe you could try two things: Increase the space width a bit, maybe to around 250 units, and also try to reduce the overlaps of the Gurmukhi letters a bit. I understand that they need to overlap, but it's maybe too much and eating into the word space too much.

Bildschirm­foto 2023-01-19 um 14 00 03

@artandtype
Copy link
Owner

Hello Yanone!
I apologize for not getting back to you sooner; I was on vacation.
I will increase the space width to resolve the word spacing issue, but I intentionally kept the overall spacing a bit tight as part of a design decision. We can continue with that. The other reason we should not reduce overlap for the use case is if the user (primarily graphic designers) wants to increase the overall spacing for their design; there should be some extra overlap.

@yanone
Copy link
Author

yanone commented Feb 8, 2023

Excellent, thank you. Increasing just the space width is a good solution.

@artandtype
Copy link
Owner

artandtype commented Mar 13, 2023 •
edited
Loading

Hello Yanone,
I got occupied with my office project, sorry for the delay.
I made suggested changes and created the required documents too. I'll be able to share it by next week.
But after updating the Fontbakety tool, I'm getting soft dotted characters issue, How do I fix it? Can we fix it by any gf tools command? or is there any script reference that I can run with Fontlab during font export? or lastly, could you fix it from your end?
Please check the below details for the failure.

"description":"Ensure soft_dotted characters lose their dot when combined with marks that replace the dot.

"message":"The dot of soft dotted characters used in orthographies must disappear in the following strings: i̊ i̋ j̀ j́ j̃ j̄ j̈ į̀ į́ į̂ į̃ į̄ į̌ ị̀ ị́ ị̂ ị̃ ị̄ The dot of soft dotted characters should disappear in other cases, for example: i̇ ǐ i̒ i̛̇ i̛̊ i̛̋ ǐ̛ i̛̒ i̤̇ i̤̊ i̤̋ ǐ̤ i̤̒ i̦̇ i̦̊ i̦̋ ǐ̦ i̦̒ i̧̇ i̧̊ [code: soft-dotted]",
"status":"FAIL"

"rationale":" An accent placed on characters with a "soft dot", like i or j, causes the dot to disappear. An explicit dot above can be added where required. See "Diacritics on i and j" in Section 7.1, "Latin" in The Unicode Standard. Characters with the Soft_Dotted property are listed in https://www.unicode.org/Public/UCD/latest/ucd/PropList.txt ",
"result":"FAIL"

@yanone
Copy link
Author

yanone commented Mar 14, 2023

Let's ignore the soft-dotted characters issue for now. The requirement/check is brand new and I myself don't know yet how to pull it off. Chances are it'll get accepted anyway. And if not, then we'll look for a solution.

I'll be checking the new files later today. Thank you.

@yanone
Copy link
Author

yanone commented Mar 14, 2023

Sorry, I overlooked "I'll be able to share it by next week".
Sure, let me know once the files are ready.

@artandtype
Copy link
Owner

Hello Yanone!
I have rearranged the git repo, kindly check and let me know if anything else is required from my end.
Link: https://github.com/artandtype/Braah

@yanone
Copy link
Author

yanone commented Mar 21, 2023

Thanks for the update. One tiny issue remains: Please update the license string to "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL" (Version changed from 1.0 to 1.1).

Also, please update the description HTML file. I made one clarification about the scripts and inserted the correct repository link instead of your email address (Google Fonts requirement). Otherwise, please feel free to expand on the description, max 2000 characters incl. HTML tags. (Not a must)

<p>
    Braah is a display font that perfectly blends boldness and playfulness.
    The font is available with corresponding Latin/Gurmukhi scripts,
    making it versatile and adaptable to different languages.
</p>
<p>
    To contribute to the project please see <a
        href="https://github.com/artandtype/Braah">github.com/artandtype/Braah</a>.
</p>

And another question: What are the chances that Braah will receive an update in the future that will add a Regular weight? Google Fonts has a policy for releasing single-weight fonts that are not Regular weight, in which case "One" needs to be added to the family name and the style be set to Regular. See here.

Google Fonts have waived this practice in the past if there is really no intention whatsoever, but I need to discuss this with the team in any case. What are your thoughts on this?

@artandtype
Copy link
Owner

Yanone!
I have updated the description file as you suggested.
I did not get this> Please update the license string to "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL" Do you mean that I need to add this text in OFL.txt and remove the existing license details in the OFL.txt?

Regarding future updates for Braah: Yes, 1. I have been working on a stylized version of Braah 2. There is a plan to make Braah a multi-weight font and it has the potential to convert into variable font as well.
Apart from multi-weight, I have a long-term plan to make Braah a multi-script font, keeping Devanagari, Gujarati, Bengali, and south Indian scripts in mind.

@yanone
Copy link
Author

yanone commented Mar 22, 2023

Okay, so that means that you need to please rename the font family name to "Braah One" for the time being, until a version with more weights is ready. Google Fonts would then publish the multi-weight family as "Braah" and quietly discontinue "Braah One" (while continuing to serve it for those websites that already use it).

About the license string: Look for it in the Font Info of whichever font editor you're using. You should find it there, and simply replace the "1.0" with "1.1".

@artandtype
Copy link
Owner

Thanks Yanone!
It's clear now, I'll take the suggested actions.

Thank you!

@artandtype
Copy link
Owner

Hi Yanane!
Changed font family name and updated license string.
let me know if there are still any issues.

@yanone
Copy link
Author

yanone commented Mar 23, 2023

Excellent, thank you.
The last piece that's missing is for you to please fill out this form for the designer bio and avatar in whichever configuration you would like to be credited (studio, personal, etc.)

@artandtype
Copy link
Owner

Done, shared :)
Thank you for all the help.

@yanone
Copy link
Author

yanone commented Mar 24, 2023

I found another small mistake: Could you please update the Github URL in the copyright string of the font to https://github.com/artandtype/Braah (also to be found in the font info)?
Thank you

@artandtype
Copy link
Owner

Aah ok, I just realized, I had changed my profile name a few days back. I'll update it in some time.

@artandtype
Copy link
Owner

Done. Updated

@artandtype
Copy link
Owner

Hello Yanon!
I provided the designer's info in the Google form you have shared, I hope that was included. :)

image

@yanone
Copy link
Author

yanone commented Mar 29, 2023

Yes. You can see the actual data submitted on that same page on the right under "Files changed". Btw, it usually takes around 3 weeks for fonts to go live after they've been officially accepted. Please stay patient and let us know if you don't see anything after that.

@artandtype
Copy link
Owner

Thank you very much Yanone !

@artandtype
Copy link
Owner

Thank you very much Yanone, for helping me onboard the font.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@yanone @artandtype