Issues to fix for Google Fonts

[yanone]

As mentioned, here are the issues for Mikhak. Again, please ignore the issue about the file name.

I can already prepare you that we’ll have trouble onboarding this font because of the two custom axes. Google Fonts has a very tight grip on which axes they publish. I will look into this and update you. In the worst case, we’ll publish a basic version without the two custom axes.

If you have any questions, please do let me know.
Thank you

Fontbakery report

Fontbakery version: 0.8.7.dev11+g266bdf1a

[14] Mikhak-VF[wght,KSHD,DSTY].ttf

🔥 FAIL: Checking file is named canonically.

• com.google.fonts/check/canonical_filename

--- Rationale ---
A font's filename must be composed in the following manner:
<familyname>-<stylename>.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 The file 'Mikhak-VF[wght,KSHD,DSTY].ttf' must be renamed to 'MikhakVF[DSTY,KSHD,wght].ttf' according to the Google Fonts naming policy for variable fonts. [code: bad-varfont-filename]

🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.

• com.google.fonts/check/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 Missing required codepoints:

  • 0x02C6 (MODIFIER LETTER CIRCUMFLEX ACCENT)

  • 0x02DA (RING ABOVE)

  • 0x02DC (SMALL TILDE)

  • 0x2044 (FRACTION SLASH)

  • 0x2074 (SUPERSCRIPT FOUR)

  • 0x2212 (MINUS SIGN)

  • And 0x2215 (DIVISION SLASH)
    [code: missing-codepoints]

🔥 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 Amin Abedi (@aminabedi68)-www.fontamin.com,
  with Reserved Font Name Mikhak.

This Font Software is licensed under the SIL Open Font License, Version 1.1.
This license is available with a FAQ at: http://scripts.sil.org/OFL" [code: bad-notice-format]

🔥 FAIL: Check name table: TYPOGRAPHIC_SUBFAMILY_NAME entries.

• com.google.fonts/check/name/typographicsubfamilyname

--- Rationale ---
Requirements for the TYPOGRAPHIC_SUBFAMILY_NAME entries in the 'name' table.

• 🔥 FAIL TYPOGRAPHIC_SUBFAMILY_NAME for Win is missing. It must be "Thin". [code: missing-typo-win]

🔥 FAIL: Font enables smart dropout control in "prep" table instructions?

• com.google.fonts/check/smart_dropout

--- Rationale ---
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: Name table entries should not contain line-breaks.

• com.google.fonts/check/name/line_breaks

--- Rationale ---
There are some entries on the name table that may include more than one line of
text. The Google Fonts team, though, prefers to keep the name table entries
short and simple without line breaks.
For instance, some designers like to include the full text of a font license in
the "copyright notice" entry, but for the GFonts collection this entry should
only mention year, author and other basic info in a manner enforced by
com.google.fonts/check/font_copyright

• 🔥 FAIL Name entry COPYRIGHT_NOTICE on platform WINDOWS contains a line-break. [code: line-break]
• 🔥 FAIL Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]

🔥 FAIL: Name table strings must not contain the string 'Reserved Font Name'.

• com.google.fonts/check/name/rfn

--- Rationale ---
Some designers adopt the "Reserved Font Name" clause of the OFL license. This
means that the original author reserves the rights to the family name and other
people can only distribute modified versions using a different family name.
Google Fonts published updates to the fonts in the collection in order to fix
issues and/or implement further improvements to the fonts. It is important to
keep the family name so that users of the webfonts can benefit from the updates.
Since it would forbid such usage scenario, all families in the GFonts collection
are required to not adopt the RFN clause.
This check ensures "Reserved Font Name" is not mentioned in the name table.

• 🔥 FAIL Name table entry ("Copyright (c) 2021 by Amin Abedi (@aminabedi68)-www.fontamin.com,
  with Reserved Font Name Mikhak.

This Font Software is licensed under the SIL Open Font License, Version 1.1.
This license is available with a FAQ at: http://scripts.sil.org/OFL") contains "Reserved Font Name". This is an error except in a few specific rare cases. [code: rfn]

🔥 FAIL: Check variable font instances don't have duplicate names

• com.google.fonts/check/varfont_duplicate_instance_names

--- Rationale ---
This check's purpose is to detect duplicate named instances names in a given
variable font.
Repeating instance names may be the result of instances for several VF axes
defined in `fvar`, but since currently only weight+italic tokens are allowed in
instance names as per GF specs, they ended up repeating.
Instead, only a base set of fonts for the most default representation of the
family can be defined through instances in the `fvar` table, all other instances
will have to be left to access through the `STAT` table.

• 🔥 FAIL Following instances names are duplicate:
  • Thin
  • ExtraLight
  • Light
  • Regular
  • Medium
  • SemiBold
  • Bold
  • ExtraBold
  • Black
  • Thin
  • ExtraLight
  • Light
  • Regular
  • Medium
  • SemiBold
  • Bold
  • ExtraBold
  • Black
    [code: duplicate-instance-names]

🔥 FAIL: Validate STAT particle names and values match the fallback names in GFAxisRegistry.

• com.google.fonts/check/STAT/gf-axisregistry

--- Rationale ---
Check that particle names and values on STAT table match the fallback names in
each axis entry at the Google Fonts Axis Registry, available at
https://github.com/google/fonts/tree/main/axisregistry

• 🔥 FAIL STAT table is missing Axis Value Records [code: missing-axis-values]

🔥 FAIL: Ensure variable fonts include an avar table.

• com.google.fonts/check/mandatory_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.

• 🔥 FAIL This variable font does not have an avar table. [code: missing-avar]

🔥 FAIL: OS/2.fsSelection bit 7 (USE_TYPO_METRICS) is set in all fonts.

• com.google.fonts/check/os2/use_typo_metrics

--- Rationale ---
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: ['dist/Mikhak-VF[wght,KSHD,DSTY].ttf']. [code: missing-os2-fsselection-bit7]

🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.

• com.google.fonts/check/family/win_ascent_and_descent

--- Rationale ---
A font's winAscent and winDescent values should be greater than the head table's
yMax, abs(yMin) values. If they are less than these values, clipping can occur
on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33).
If the font includes tall/deep writing systems such as Arabic or Devanagari, the
winAscent and winDescent can be greater than the yMax and abs(yMin) to
accommodate vowel marks.
When the win Metrics are significantly greater than the upm, the linespacing can
appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7
(Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This
means the font developer can control the linespacing with the typo values,
whilst avoiding clipping by setting the win values to values greater than the
yMax and abs(yMin).

• 🔥 FAIL OS/2.usWinAscent value should be equal or greater than 2553, but got 2200 instead [code: ascent]
• 🔥 FAIL OS/2.usWinDescent value should be equal or greater than 1444, but got 1200 instead. [code: descent]

🔥 FAIL: Ensure component transforms do not perform scaling or rotation.

• com.google.fonts/check/transformed_components

--- Rationale ---
Some families have glyphs which have been constructed by using transformed
components e.g the 'u' being constructed from a flipped 'n'.
From a designers point of view, this sounds like a win (less work). However,
such approaches can lead to rasterization issues, such as having the 'u' not
sitting on the baseline at certain sizes after running the font through
ttfautohint.
As of July 2019, Marc Foley observed that ttfautohint assigns cvt values to
transformed glyphs as if they are not transformed and the result is they render
very badly, and that vttLib does not support flipped components.
When building the font with fontmake, the problem can be fixed by adding this to
the command line:
--filter DecomposeTransformedComponentsFilter

• 🔥 FAIL The following glyphs had components with scaling or rotation:

• Thorn (component I)

• exclamdown (component exclam)

• questiondown (component question)

• quotedblbase (component uni060C)

• quotedblbase (component uni060C)

• quotedblright (component uni060C)

• quotedblright (component uni060C)

• quoteright (component uni060C)

• quotesinglbase (component uni060C)

• uni0657 (component uniE042)

• uni066C (component uni060C)

• uni0686 (component uniE002)

• uniE029 (component uniE003)

• uniE02A (component uniE003)

• uniFB7B (component uniE002)
  [code: transformed-components]

🔥 FAIL: Space and non-breaking space have the same width?

• com.google.fonts/check/whitespace_widths

• 🔥 FAIL Space and non-breaking space have differing width: The space glyph named space is 350 font units wide, non-breaking space named (uni00A0) is 801 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]

Summary

💔 ERROR	🔥 FAIL	⚠ WARN	💤 SKIP	ℹ INFO	🍞 PASS	🔎 DEBUG
0	14	6	106	8	89	0
0%	6%	3%	48%	4%	40%	0%

Note: The following loglevels were omitted in this report:

• WARN
• SKIP
• INFO
• PASS
• DEBUG

[bateni]

Amin, thanks for taking on the job of preparing the fonts for google-fonts. You mentioned that you have some tasks to perform on the two fonts. I'm curious to know what your timeline is like.

[aminabedi68]

hi @bateni
yes, i've planned for some tasks:

1. for Estedad:

• closing the issues.
• redesign glyphs and refine curves on some cases.
• control and reduce saturation in black master.
• create opentype mark and ccmp fallback for Latin glyphs.
• maybe: an alternate "a" with flat right side working with calt.
• maybe: removing bold master.
• ...

2. for Mikhak:

• correcting "w" weight in black master.
• add support: opentype routine for Arabic End of Ayah (U+06DD).
• ...

... and issues reported by fontbakery.
these are primary issues and features, everything might change in the update process.

[davelab6]

@aminabedi68 I wonder if you have any updates on these issues :)

[aminabedi68]

Hi @davelab6
this font has updated since this issue has opened. after your comment i checked with latest fontbakery google fonts check and got some fails(5 fails):
fontbakery-report.zip

if we have to fix all fails(i hope we have not to), two fails are easy to fix(fail about names, fail about glyph coverage), i can work on them.
three fails seems related to DSTY and KSHD axes, i don't know what we can do about them.

[yanone]

@aminabedi68 I looked at the Fontbakery results. Please focus on the glyph coverage for now. The rest are details we'll iron out once Google Fonts decides to onboard it. As you know, we're still debating the KSHD axis.