Prepare for GF release

[pathumego]

• Prepare promo images for GF
• Update DESCRIPTION.en_us.html
• Credits on README.md
• Review Sinhala
• Review Latin
• Credits on FONTLOG.md
• Copyright notice on OFL.tt
• Version on FONTLOG.md
• Description (Names/ Dates)
• Check Issue Tracker for Release Milestone
• Final Feature Testing
• rc-1 Testing
• Make final binaries

[yanone]

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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#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: fonttools/fontbakery#3762
See also: fonttools/fontbakery#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: fonttools/fontbakery#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:

• WARN
• SKIP
• INFO
• PASS
• DEBUG

[yanone]

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]

@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.