search

mooniak / maname-font

Maname fonts project repository
SIL Open Font License 1.1
8 stars 3 forks source link

Prepare for GF release #11

Closed pathumego closed 5 months ago

pathumego commented 6 months ago
yanone commented 6 months ago

FontBakery report

fontbakery version: 0.12.5

Check results

[13] Maname-Regular.ttf
💥 ERROR Check the direction of the outermost contour in each glyph
> > In TrueType fonts, the outermost contour of a glyph should be oriented > counter-clockwise, while the inner contours should be oriented clockwise. > Getting the path direction wrong can lead to rendering issues in some > software. > > Original proposal: https://github.com/fonttools/fontbakery/issues/2056 * 💥 **ERROR**

Failed with ZeroDivisionError: float division by zero

  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/fontbakery/checkrunner.py", line 213, in _run_check
    subresults = list(subresults)
                 ^^^^^^^^^^^^^^^^
  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/fontbakery/checks/outline.py", line 366, in com_google_fonts_check_outline_direction
    if path.direction == 1:
       ^^^^^^^^^^^^^^
  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/beziers/path/__init__.py", line 558, in direction
    return math.copysign(1, self.signed_area)
                            ^^^^^^^^^^^^^^^^
  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/beziers/path/__init__.py", line 541, in signed_area
    flat = self.flatten()
           ^^^^^^^^^^^^^^
  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/beziers/path/__init__.py", line 494, in flatten
    segs.extend(s.flatten(degree))
                ^^^^^^^^^^^^^^^^^
  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/beziers/quadraticbezier.py", line 58, in flatten
    samples = self.sample(self.length/degree)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/yanone/.pyenv/versions/3.11.1/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/beziers/utils/samplemixin.py", line 20, in sample
    step = 1.0 / float(samples)
           ~~~~^~~~~~~~~~~~~~~~
[code: failed-check]
🔥 FAIL Check glyphs do not have duplicate components which have the same x,y coordinates.
> > There have been cases in which fonts had faulty double quote marks, with each > of them containing two single quote marks as components with the same > x, y coordinates which makes them visually look like single quote marks. > > This check ensures that glyphs do not contain duplicate components > which have the same x,y coordinates. > > Original proposal: https://github.com/fonttools/fontbakery/pull/2709 * 🔥 **FAIL**

The following glyphs have duplicate components which have the same x,y coordinates: * {'glyph': 'ellipsis', 'component': 'period', 'x': 0, 'y': 0} * {'glyph': 'ellipsis', 'component': 'period', 'x': 0, 'y': 0} * {'glyph': 'quotedblbase', 'component': 'comma', 'x': 0, 'y': 0} * {'glyph': 'guillemotleft', 'component': 'guilsinglleft', 'x': 0, 'y': 0} and {'glyph': 'trtight', 'component': 'guilsinglright', 'x': 0, 'y': 0}

[code: found-duplicates]
🔥 FAIL Check accent of Lcaron, dcaron, lcaron, tcaron
> > Lcaron, dcaron, lcaron, tcaron should NOT be composed with quoteright > or quotesingle or comma or caron(comb). It should be composed with a > distinctive glyph which doesn't look like an apostrophe. > > Source: > https://ilovetypography.com/2009/01/24/on-diacritics/ > http://diacritics.typo.cz/index.php?id=5 > https://www.typotheque.com/articles/lcaron > > Original proposal: https://github.com/fonttools/fontbakery/issues/3308 * 🔥 **FAIL**

Lcaron uses component comma.

Overridden: This check was originally a WARN but was overridden by the ufo profile: For Google Fonts, one of the comma-lookalikes is a FAIL

[code: bad-mark] * 🔥 **FAIL**

dcaron uses component comma.

Overridden: This check was originally a WARN but was overridden by the ufo profile: For Google Fonts, one of the comma-lookalikes is a FAIL

[code: bad-mark] * 🔥 **FAIL**

lcaron uses component comma.

Overridden: This check was originally a WARN but was overridden by the ufo profile: For Google Fonts, one of the comma-lookalikes is a FAIL

[code: bad-mark] * 🔥 **FAIL**

tcaron uses component comma.

Overridden: This check was originally a WARN but was overridden by the ufo profile: For Google Fonts, one of the comma-lookalikes is a FAIL

[code: bad-mark]
🔥 FAIL Space and non-breaking space have the same width?
> > If the space and nbspace glyphs have different widths, then Google Workspace > has problems with the font. > > The nbspace is used to replace the space character in multiple situations in > documents; such as the space before punctuation in languages that do that. It > avoids the punctuation to be separated from the last word and go to next line. > > This is automatic substitution by the text editors, not by fonts. It's also used > by designers in text composition practice to create nicely shaped paragraphs. > If the space and the nbspace are not the same width, it breaks the text > composition of documents. > > Original proposal: https://github.com/fonttools/fontbakery/issues/3843 > See also: legacy:check/050 * 🔥 **FAIL**

Space and non-breaking space have differing width: The space glyph named space is 220 font units wide, non-breaking space named (uni00A0) is 200 font units wide, and both should be positive and the same. GlyphsApp has "Sidebearing arithmetic" (https://glyphsapp.com/tutorials/spacing) which allows you to set the non-breaking space width to always equal the space width.

[code: different-widths]
🔥 FAIL Shapes languages in all GF glyphsets.
> > This check uses a heuristic to determine which GF glyphsets a font supports. > Then it checks the font for correct shaping behaviour for all languages in > those glyphsets. > > Original proposal: https://github.com/googlefonts/fontbakery/issues/4147 * 🔥 **FAIL**

GF_Latin_Core glyphset:

Language FAIL messages
nl_Latn (Dutch) Shaper didn't attach acutecomb to J
^ Shaper didn't attach acutecomb to uni0237
[code: failed-language-shaping]
🔥 FAIL Check license file has good copyright string.
> > An OFL.txt file's first line should be the font copyright. > > > The expected pattern for the copyright string adheres to the following rules: > > * It must say "Copyright" followed by a 4 digit year (optionally followed by > a hyphen and another 4 digit year) > > * Additional years or year ranges are also valid. > > * An optional comma can be placed here. > > * Then it must say "The Project Authors" and, within parentheses, > a URL for a git repository must be provided. But we have an exception > for the fonts from the Noto project, that simply have > "google llc. all rights reserved" here. > > * The check is case insensitive and does not validate whether the familyname > is correct, even though we'd obviously expect it to be. > > > Here is an example of a valid copyright string: > > "Copyright 2017 The Archivo Black Project Authors > (https://github.com/Omnibus-Type/ArchivoBlack)" > > Original proposal: https://github.com/fonttools/fontbakery/issues/2764 * 🔥 **FAIL**

First line in license file is:

"copyright (c) 2015-2017, maname fonts project authors."

which does not match the expected format, similar to:

"Copyright 2022 The Familyname Project Authors (git url)"

[code: bad-format]
🔥 FAIL A font repository should not include ZIP files
> > Sometimes people check in ZIPs into their font project repositories. While we > accept the practice of checking in binaries, we believe that a ZIP is a step > too far ;) > > Note: a source purist position is that only source files and build scripts > should be checked in. > > Original proposal: https://github.com/fonttools/fontbakery/issues/2903 * 🔥 **FAIL**

Please do not host ZIP files on the project repository. These files were detected: * fonts/ttf/Maname-Regular.ttf.zip

[code: zip-files]
🔥 FAIL Copyright notices match canonical pattern in fonts
> > This check aims at ensuring a uniform and legally accurate copyright statement > on the name table entries of font files accross the Google Fonts library. > > > The expected pattern for the copyright string adheres to the following rules: > > * It must say "Copyright" followed by a 4 digit year (optionally followed by > a hyphen and another 4 digit year) > > * Additional years or year ranges are also valid. > > * An optional comma can be placed here. > > * Then it must say "The Project Authors" and, within parentheses, > a URL for a git repository must be provided. But we have an exception > for the fonts from the Noto project, that simply have > "google llc. all rights reserved" here. > > * The check is case insensitive and does not validate whether the familyname > is correct, even though we'd obviously expect it to be. > > > Here is an example of a valid copyright string: > > "Copyright 2017 The Archivo Black Project Authors > (https://github.com/Omnibus-Type/ArchivoBlack)" > > Original proposal: https://github.com/fonttools/fontbakery/pull/2383 * 🔥 **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 2015—2023 The Maname Project Authors <See at https://github.com/mooniak/maname-font/>"

[code: bad-notice-format]
🔥 FAIL Check font names are correct
> > Google Fonts has several rules which need to be adhered to when > setting a font's name table. Please read: > https://googlefonts.github.io/gf-guide/statics.html#supported-styles > https://googlefonts.github.io/gf-guide/statics.html#style-linking > https://googlefonts.github.io/gf-guide/statics.html#unsupported-styles > https://googlefonts.github.io/gf-guide/statics.html#single-weight-families > > Original proposal: https://github.com/fonttools/fontbakery/pull/3800 * 🔥 **FAIL**

Font names are incorrect:

nameID current expected
Family Name Maname Maname
Subfamily Name Regular Regular
Full Name Maname Regular Maname Regular
Postscript Name Maname Maname-Regular
[code: bad-names]
🔥 FAIL Checking OS/2 fsType does not impose restrictions.
> > The fsType in the OS/2 table is a legacy DRM-related field. Fonts in the > Google Fonts collection must have it set to zero (also known as > "Installable Embedding"). This setting indicates that the fonts can be > embedded in documents and permanently installed by applications on > remote systems. > > More detailed info is available at: > https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fstype > > Original proposal: legacy:check/016 * 🔥 **FAIL**

In this font fsType is set to 8 meaning that: The font may be embedded but must only be installed temporarily on other systems.

No such DRM restrictions can be enabled on the Google Fonts collection, so the fsType field must be set to zero (Installable Embedding) instead.

[code: drm]
🔥 FAIL Check Google Fonts 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. > > Original proposal: https://github.com/fonttools/fontbakery/pull/2488 * 🔥 **FAIL**

Missing required codepoints:

- 0x00BB (RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK)
[code: missing-codepoints]
🔥 FAIL Are there non-ASCII characters in ASCII-only NAME table entries?
> > The OpenType spec requires ASCII for the POSTSCRIPT_NAME (nameID 6). > > For COPYRIGHT_NOTICE (nameID 0) ASCII is required because that string should be > the same in CFF fonts which also have this requirement in the OpenType spec. > > Note: > A common place where we find non-ASCII strings is on name table entries > with NameID > 18, which are expressly for localising the ASCII-only IDs > into Hindi / Arabic / etc. > > Original proposal: legacy:check/074 > See also: https://github.com/fonttools/fontbakery/issues/1663 * 🔥 **FAIL**

Bad string at [nameID 0, 'utf_16_be']: 'b'Copyright 2015—2023 The Maname Project Authors <See at https://github.com/mooniak/maname-font/>''

[code: bad-string] * 🔥 **FAIL**

There are 1 strings containing non-ASCII characters in the ASCII-only NAME table entries.

[code: non-ascii-strings]
🔥 FAIL Check font follows the Google Fonts vertical metric schema
> > 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 > > Original proposal: https://github.com/fonttools/fontbakery/pull/3762 > See also: https://github.com/fonttools/fontbakery/pull/3921 * 🔥 **FAIL**

The OS/2 sTypoDescender must be negative or zero. This font has a strictly positive value.

[code: typo-descender] * 🔥 **FAIL**

The hhea descender must be negative or zero. This font has a strictly positive value.

[code: hhea-descent]
[1] Family checks
🔥 FAIL OS/2.fsSelection bit 7 (USE_TYPO_METRICS) is set in all fonts.
> > 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. > > Original proposal: https://github.com/fonttools/fontbakery/issues/3241 * 🔥 **FAIL**

OS/2.fsSelection bit 7 (USE_TYPO_METRICS) wasNOT set in the following fonts: ['fonts/ttf/Maname-Regular.ttf'].

[code: missing-os2-fsselection-bit7]

Summary

💥 ERROR ☠ FATAL 🔥 FAIL ⚠️ WARN ⏩ SKIP ℹ️ INFO ✅ PASS 🔎 DEBUG
1 0 13 14 115 6 101 0
0% 0% 5% 6% 46% 2% 40% 0%

Note: The following loglevels were omitted in this report:

yanone commented 6 months ago

Please address all of the above Fontbakery FAILs.

A few comments:

Check accent of Lcaron, dcaron, lcaron, tcaron Use caroncomb.alt for these, but replace the outlines with something that looks like the comma.

Shapes languages in all GF glyphsets Attach anchors (top, bottom, etc) to J and jdotless, and also to all combining marks. These are required to compose certain character sequences in the text shaper, such as for Durch. I suggest to use anchors and automatic glyph composition (disabled in font info) to compose all Latin characters. That will already solve a few other issue.

Additionally and related (the check is currently disabled in Fontbakery), please ensure that all legacy accents (non-*comb) have positive sidebearings, and all combining marks have zero-width.

In fact, I tried to fix issues myself quickly and was going to send you a PR back, but changing the spacing of the marks changed the mark positions in all accented letters, and that was too much for me to deal with. Using automatic composition with anchors would have solved that, as the anchor positions are then relevant to the composition and not the mark's sidebearings, so the composed glyphs would have not changed at all when adjusting the sidebearings.

A font repository should not include ZIP files Ignore this one

Generally, please consider using Fontbakery on your end. You can update it to the latest version with pip install -U fontbakery. Do this regularly, as the release cycle is increasing and issues get fixed more frequently nowadays.

yanone commented 5 months ago

@pathumego Please merge this PR (just spell-checking on the description) and then create a release so we can publish it. We need either a release or the font files to be available in the repo directly.

I have 6 more work days until end of June before my summer break. Would be great if we could finish this. We're almost there. The fonts are looking great.