search

floriankarsten / montagu-slab

Montagu Slab by Florian Karsten
SIL Open Font License 1.1
32 stars 4 forks source link

Google Font QA report - VF #3

Open vv-monsalve opened 3 years ago

vv-monsalve commented 3 years ago

Fontbakery report

Fontbakery version: 0.7.34

[12] Montagu-Slab[wght,opsz].ttf
🔥 FAIL: Checking file is named canonically. * [com.google.fonts/check/canonical_filename](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#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 'Montagu-Slab[wght,opsz].ttf' must be renamed to 'MontaguSlab[opsz,wght].ttf' according to the Google Fonts naming policy for variable fonts. [code: bad-varfont-filename]
🔥 FAIL: Checking OS/2 fsType does not impose restrictions. * [com.google.fonts/check/fstype](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/fstype) 
--- Rationale ---

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
* 🔥 **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 Latin Core` glyph coverage. * [com.google.fonts/check/glyph_coverage](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#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: 0x0026 (AMPERSAND), 0x002B (PLUS SIGN), 0x003C (LESS-THAN SIGN), 0x003D (EQUALS SIGN) and 23 more. [code: missing-codepoints]
🔥 FAIL: Checking OS/2 usWeightClass. * [com.google.fonts/check/usweightclass](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/usweightclass) 
--- Rationale ---

Google Fonts expects variable fonts, static ttfs and static otfs to have
differing OS/2 usWeightClass values.

For Variable Fonts, Thin-Black must be 100-900
For static ttfs, Thin-Black can be 100-900 or 250-900
For static otfs, Thin-Black must be 250-900

If static otfs are set lower than 250, text may appear blurry in legacy Windows
applications.

Glyphsapp users can change the usWeightClass value of an instance by adding a
'weightClass' customParameter.
* 🔥 **FAIL** OS/2 usWeightClass is '100' when it should be '400'. [code: bad-value]
🔥 FAIL: Copyright notices match canonical pattern in fonts * [com.google.fonts/check/font_copyright](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#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 2020 FKxGF Schoolbook Project Authors (https://github.com/floriankarsten/fk-gf-schoolbook)" [code: bad-notice-format]
🔥 FAIL: A variable font must have named instances. * [com.google.fonts/check/varfont_has_instances](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/varfont_has_instances) 
--- Rationale ---

Named instances must be present in all variable fonts in order not to frustrate
the users' typical expectations of a traditional static font workflow.
* 🔥 **FAIL** This variable font lacks named instances on the fvar table. [code: lacks-named-instances]
🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent. * [com.google.fonts/check/family/win_ascent_and_descent](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#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 2426, but got 1800 instead [code: ascent]
🔥 FAIL: Check glyphs do not have components which are themselves components. * [com.google.fonts/check/glyf_nested_components](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/glyf.html#com.google.fonts/check/glyf_nested_components) 
--- Rationale ---

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:
* https://github.com/googlefonts/fontbakery/issues/2961
* https://github.com/arrowtype/recursive/issues/412
* 🔥 **FAIL** The following glyphs have components which themselves are component glyphs: * uni1EB2 * uni1EB4 * uni1EA8 * uni1EAA * uni01C4 * uni01C5 * uni1EC2 * uni1EC4 * uni01C8 * uni01CB and 33 more. [code: found-nested-components]
⚠ WARN: Are there caret positions declared for every ligature? * [com.google.fonts/check/ligature_carets](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/ligature_carets) 
--- Rationale ---

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, ligature carets can be set directly on canvas by accessing
the `Glyph -> Set Anchors` menu option or by pressing the `Cmd+U` keyboard
shortcut.

If designing with UFOs, (as of Oct 2020) ligature carets are not yet compiled
by ufo2ft, and therefore will not build via FontMake. See
googlefonts/ufo2ft/issues/329
* ⚠ **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](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/kerning_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** GPOS table lacks kerning info for the following non-ligated sequences: - f + f - f + i - i + f - f + l - l + f - i + l [code: lacks-kern-info]
⚠ WARN: Combined length of family and style must not exceed 27 characters. * [com.google.fonts/check/name/family_and_style_max_length](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/family_and_style_max_length) 
--- Rationale ---

According to a GlyphsApp tutorial [1], in order to make sure all versions of
Windows recognize it as a valid font file, we must make sure that the
concatenated length of the familyname (NameID.FONT_FAMILY_NAME) and style
(NameID.FONT_SUBFAMILY_NAME) strings in the name table do not exceed 20
characters.

After discussing the problem in more detail at `FontBakery issue #2179 [2] we
decided that allowing up to 27 chars would still be on the safe side, though.

[1]
https://glyphsapp.com/tutorials/multiple-masters-part-3-setting-up-instances
[2] https://github.com/googlefonts/fontbakery/issues/2179
* ⚠ **WARN** The combined length of family and style exceeds 27 chars in the following 'WINDOWS' entries: FONT_FAMILY_NAME = 'Montagu Slab Thin Text' / SUBFAMILY_NAME = 'Regular' Please take a look at the conversation at https://github.com/googlefonts/fontbakery/issues/2179 in order to understand the reasoning behind these name table records max-length criteria. [code: too-long]
⚠ WARN: Are there any misaligned on-curve points? * [com.google.fonts/check/outline_alignment_miss](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/.html#com.google.fonts/check/outline_alignment_miss) 
--- Rationale ---

This test heuristically looks for on-curve points which are close to, but do
not sit on, significant boundary coordinates. For example, a point which has a
Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the
baseline, the test also checks for points near the x-height (but only for lower
case Latin letters), cap-height, ascender and descender Y coordinates.

Not all such misaligned curve points are a mistake, and sometimes the design
may call for points in locations near the boundaries. As this test is liable to
generate significant numbers of false positives, the test will pass if there
are more than 100 reported misalignments.
* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * u: X=258.0,Y=1102.0 (should be at x-height 1100?) * u: X=306.0,Y=1102.0 (should be at x-height 1100?) * uni1EA9: X=824.0,Y=1801.0 (should be at ascender 1800?) * uni02BC: X=143.0,Y=1502.0 (should be at cap-height 1500?) * uni03020309: X=552.0,Y=1801.0 (should be at ascender 1800?) * colon: X=142.0,Y=1.5 (should be at baseline 0?) * colon: X=228.0,Y=1.5 (should be at baseline 0?) * uni0312: X=107.5,Y=1498.0 (should be at cap-height 1500?) * uni1EC3: X=837.0,Y=1801.0 (should be at ascender 1800?) * ellipsis: X=142.0,Y=1.5 (should be at baseline 0?) and 21 more. [code: found-misalignments]

Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 8 4 90 8 85 0
0% 4% 2% 46% 4% 44% 0%

Note: The following loglevels were omitted in this report:

vv-monsalve commented 3 years ago

Hi @mightybart This is a FB report for tests performed into a temporary VF created. As you are familiar with most of them, please let me know if you have any questions. Some of the reported Warns have to do with our Outline Quality Checklist The Fail of Nested components could be handle with a recently implemented -f option in Fontmake.

I'll file a new Issue with a list of what would be needed for the launching of this new project.

mightybart commented 3 years ago

Fontbakery report

Fontbakery version: 0.7.34

[1] Family checks
⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available? * [com.google.fonts/check/ftxvalidator_is_available](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/ftxvalidator_is_available) 
--- Rationale ---

There's no reasonable (and legal) way to run the command `ftxvalidator` of the
Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc.

If Font Bakery is not running on an OSX machine, the machine running Font
Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure
call (rpc).

There's an ssh example implementation at:
https://github.com/googlefonts/fontbakery/blob/master/prebuilt/workarounds
/ftxvalidator/ssh-implementation/ftxvalidator
* ⚠ **WARN** Could not find ftxvalidator.

[4] MontaguSlab[opsz,wght].ttf
🔥 FAIL: Check name table: TYPOGRAPHIC_SUBFAMILY_NAME entries. * [com.google.fonts/check/name/typographicsubfamilyname](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/typographicsubfamilyname) * 🔥 **FAIL** TYPOGRAPHIC_SUBFAMILY_NAME for Win "Thin 144pt" is incorrect. It must be "Thin". [code: bad-typo-win]
⚠ WARN: Is there kerning info for non-ligated sequences? * [com.google.fonts/check/kerning_for_non_ligated_sequences](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/kerning_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** GPOS table lacks kerning info for the following non-ligated sequences: - f + f - f + i - i + f - f + l - l + f - i + l [code: lacks-kern-info]
⚠ WARN: The variable font 'opsz' (Optical Size) axis coordinate should be between 9 and 13 on the 'Regular' instance. * [com.google.fonts/check/varfont/regular_opsz_coord](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/fvar.html#com.google.fonts/check/varfont/regular_opsz_coord) 
--- Rationale ---

According to the Open-Type spec's registered design-variation tag 'opsz'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_opsz

If a variable font has a 'opsz' (Optical Size) axis, then the coordinate of its
'Regular' instance is recommended to be a value in the range 9 to 13.
* ⚠ **WARN** The "opsz" (Optical Size) coordinate on the "Regular" instance is recommended to be a value in the range 9 to 13. Got 144.0 instead. [code: out-of-range]
⚠ WARN: Are there any misaligned on-curve points? * [com.google.fonts/check/outline_alignment_miss](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/.html#com.google.fonts/check/outline_alignment_miss) 
--- Rationale ---

This test heuristically looks for on-curve points which are close to, but do
not sit on, significant boundary coordinates. For example, a point which has a
Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the
baseline, the test also checks for points near the x-height (but only for lower
case Latin letters), cap-height, ascender and descender Y coordinates.

Not all such misaligned curve points are a mistake, and sometimes the design
may call for points in locations near the boundaries. As this test is liable to
generate significant numbers of false positives, the test will pass if there
are more than 100 reported misalignments.
* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * uni1EA9: X=866.0,Y=1802.0 (should be at ascender 1800?) * uni1EA9: X=732.0,Y=1801.0 (should be at ascender 1800?) * uni1EA9: X=866.0,Y=1802.0 (should be at ascender 1800?) * uni1EA3: X=426.0,Y=1499.0 (should be at cap-height 1500?) * aring: X=438.5,Y=1501.0 (should be at cap-height 1500?) * aring: X=693.5,Y=1501.0 (should be at cap-height 1500?) * aringacute: X=438.5,Y=1501.0 (should be at cap-height 1500?) * aringacute: X=693.5,Y=1501.0 (should be at cap-height 1500?) * uni1EC3: X=879.0,Y=1802.0 (should be at ascender 1800?) * uni1EC3: X=745.0,Y=1801.0 (should be at ascender 1800?) and 44 more. [code: found-misalignments]

Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 1 4 88 8 94 0
0% 1% 2% 45% 4% 48% 0%

Note: The following loglevels were omitted in this report:

mightybart commented 3 years ago

Not sure how to solve remaining FAIL. Any advice @vv-monsalve ?

vv-monsalve commented 3 years ago

The name of the main Master shouldn't include the '14 pt' particle.

Also, please update the build instructions in the readme including:

mightybart commented 3 years ago

Updated the description. I tried to be as clear as possible and describe every step (part 1: installing the script, part 2: using the script).

Is it necessary to have build.sh in the "glyphs-decomposed" folder? I think we may clean up the sources folder a little bit more after all. There are a few type of files mixed up together right now:

  1. actual glpyhs source with all smart components
  2. font tables imported during build
  3. scripts that are part of build process
  4. pre-build related files (decomposed glyphs file and glyphs script, both placed in "glyphs-decomposed" folder)
mightybart commented 3 years ago

I tried another folder arrangement and placed the glyphs source in a separate folder. It was confusing when it was in the same folder as build.sh, the two are not related.

@vv-monsalve if you think this is still not OK, maybe #6 is more related to this issue

mightybart commented 3 years ago

Fontbakery report

Fontbakery version: 0.7.34

[1] Family checks
⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available? * [com.google.fonts/check/ftxvalidator_is_available](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/ftxvalidator_is_available) 
--- Rationale ---

There's no reasonable (and legal) way to run the command `ftxvalidator` of the
Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc.

If Font Bakery is not running on an OSX machine, the machine running Font
Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure
call (rpc).

There's an ssh example implementation at:
https://github.com/googlefonts/fontbakery/blob/master/prebuilt/workarounds
/ftxvalidator/ssh-implementation/ftxvalidator
* ⚠ **WARN** Could not find ftxvalidator.

[3] MontaguSlab[opsz,wght].ttf
⚠ WARN: Is there kerning info for non-ligated sequences? * [com.google.fonts/check/kerning_for_non_ligated_sequences](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/kerning_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** GPOS table lacks kerning info for the following non-ligated sequences: - f + f - f + i - i + f - f + l - l + f - i + l [code: lacks-kern-info]
⚠ WARN: The variable font 'opsz' (Optical Size) axis coordinate should be between 9 and 13 on the 'Regular' instance. * [com.google.fonts/check/varfont/regular_opsz_coord](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/fvar.html#com.google.fonts/check/varfont/regular_opsz_coord) 
--- Rationale ---

According to the Open-Type spec's registered design-variation tag 'opsz'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_opsz

If a variable font has a 'opsz' (Optical Size) axis, then the coordinate of its
'Regular' instance is recommended to be a value in the range 9 to 13.
* ⚠ **WARN** The "opsz" (Optical Size) coordinate on the "Regular" instance is recommended to be a value in the range 9 to 13. Got 144.0 instead. [code: out-of-range]
⚠ WARN: Are there any misaligned on-curve points? * [com.google.fonts/check/outline_alignment_miss](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/.html#com.google.fonts/check/outline_alignment_miss) 
--- Rationale ---

This test heuristically looks for on-curve points which are close to, but do
not sit on, significant boundary coordinates. For example, a point which has a
Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the
baseline, the test also checks for points near the x-height (but only for lower
case Latin letters), cap-height, ascender and descender Y coordinates.

Not all such misaligned curve points are a mistake, and sometimes the design
may call for points in locations near the boundaries. As this test is liable to
generate significant numbers of false positives, the test will pass if there
are more than 100 reported misalignments.
* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * Cdotaccent: X=619.0,Y=1798.0 (should be at ascender 1800?) * Cdotaccent: X=1051.0,Y=1798.0 (should be at ascender 1800?) * Edotaccent: X=572.0,Y=1798.0 (should be at ascender 1800?) * Edotaccent: X=1004.0,Y=1798.0 (should be at ascender 1800?) * Gdotaccent: X=631.0,Y=1798.0 (should be at ascender 1800?) * Gdotaccent: X=1063.0,Y=1798.0 (should be at ascender 1800?) * Idotaccent: X=238.0,Y=1798.0 (should be at ascender 1800?) * Idotaccent: X=670.0,Y=1798.0 (should be at ascender 1800?) * uni1E44: X=669.0,Y=1798.0 (should be at ascender 1800?) * uni1E44: X=1101.0,Y=1798.0 (should be at ascender 1800?) and 41 more. [code: found-misalignments]

Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 0 4 88 8 95 0
0% 0% 2% 45% 4% 49% 0%

Note: The following loglevels were omitted in this report:

vv-monsalve commented 3 years ago

I tried another folder arrangement and placed the glyphs source in a separate folder. It was confusing when it was in the same folder as build.sh, the two are not related.

@vv-monsalve if you think this is still not OK, maybe #6 is more related to this issue

New order and instructions look good.

mightybart commented 3 years ago

New build & fontbakery check:

Fontbakery report

Fontbakery version: 0.7.36

[1] Family checks
⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available? * [com.google.fonts/check/ftxvalidator_is_available](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/ftxvalidator_is_available) 
--- Rationale ---
There's no reasonable (and legal) way to run the command `ftxvalidator` of the
Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc.
If Font Bakery is not running on an OSX machine, the machine running Font Bakery
could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call
(rpc).
There's an ssh example implementation at:
https://github.com/googlefonts/fontbakery/blob/main/prebuilt/workarounds
/ftxvalidator/ssh-implementation/ftxvalidator
* ⚠ **WARN** Could not find ftxvalidator. [code: ftxvalidator-available]

[5] MontaguSlab[opsz,wght].ttf
⚠ WARN: Stricter unitsPerEm criteria for Google Fonts. * [com.google.fonts/check/unitsperem_strict](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/unitsperem_strict) 
--- Rationale ---
Even though the OpenType spec allows unitsPerEm to be any value between 16 and
16384, the Google Fonts project aims at a narrower set of reasonable values.
The spec suggests usage of powers of two in order to get some performance
improvements on legacy renderers, so those values are acceptable.
But values of 500 or 1000 are also acceptable, with the added benefit that it
makes upm math easier for designers, while the performance hit of not using a
power of two is most likely negligible nowadays.
Additionally, values above 2048 would likely result in unreasonable filesize
increases.
* ⚠ **WARN** Font em size (unitsPerEm) is 2200 which may be too large (causing filesize bloat), unless you are sure that the detail level in this font requires that much precision. [code: large-value]
⚠ WARN: Is there kerning info for non-ligated sequences? * [com.google.fonts/check/kerning_for_non_ligated_sequences](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/kerning_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** GPOS table lacks kerning info for the following non-ligated sequences: - f + f - f + i - i + f - f + l - l + f - i + l [code: lacks-kern-info]
⚠ WARN: Checking unitsPerEm value is reasonable. * [com.google.fonts/check/unitsperem](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/head.html#com.google.fonts/check/unitsperem) 
--- Rationale ---
According to the OpenType spec:
The value of unitsPerEm at the head table must be a value between 16 and 16384.
Any value in this range is valid.
In fonts that have TrueType outlines, a power of 2 is recommended as this allows
performance optimizations in some rasterizers.
But 1000 is a commonly used value. And 2000 may become increasingly more common
on Variable Fonts.
* ⚠ **WARN** In order to optimize performance on some legacy renderers, the value of unitsPerEm at the head table should idealy be a power of between 16 to 16384. And values of 1000 and 2000 are also common and may be just fine as well. But we got 2200 instead. [code: suboptimal]
⚠ WARN: The variable font 'opsz' (Optical Size) axis coordinate should be between 9 and 13 on the 'Regular' instance. * [com.google.fonts/check/varfont/regular_opsz_coord](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/fvar.html#com.google.fonts/check/varfont/regular_opsz_coord) 
--- Rationale ---
According to the Open-Type spec's registered design-variation tag 'opsz'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_opsz
If a variable font has a 'opsz' (Optical Size) axis, then the coordinate of its
'Regular' instance is recommended to be a value in the range 9 to 13.
* ⚠ **WARN** The "opsz" (Optical Size) coordinate on the "Regular" instance is recommended to be a value in the range 9 to 13. Got 144.0 instead. [code: out-of-range]
⚠ WARN: Are there any misaligned on-curve points? * [com.google.fonts/check/outline_alignment_miss](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/.html#com.google.fonts/check/outline_alignment_miss) 
--- Rationale ---
This check heuristically looks for on-curve points which are close to, but do
not sit on, significant boundary coordinates. For example, a point which has a
Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the
baseline, here we also check for points near the x-height (but only for lower
case Latin letters), cap-height, ascender and descender Y coordinates.
Not all such misaligned curve points are a mistake, and sometimes the design may
call for points in locations near the boundaries. As this check is liable to
generate significant numbers of false positives, it will pass if there are more
than 100 reported misalignments.
* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * uni1EA8: X=1284.5,Y=2161.0 (should be at ascender 2160?) * uni1EC2: X=1171.5,Y=2161.0 (should be at ascender 2160?) * uni1ED4: X=1301.5,Y=2161.0 (should be at ascender 2160?) * uni1EA9: X=1219.0,Y=1501.0 (should be at cap-height 1500?) * uni1EA3: X=608.0,Y=1499.5 (should be at cap-height 1500?) * uni1EC3: X=1190.0,Y=1501.0 (should be at cap-height 1500?) * uni1EBB: X=579.0,Y=1499.5 (should be at cap-height 1500?) * uni1EC9: X=341.0,Y=1499.5 (should be at cap-height 1500?) * uni1ED5: X=1249.0,Y=1501.0 (should be at cap-height 1500?) * uni1ECF: X=638.0,Y=1499.5 (should be at cap-height 1500?) and 12 more. [code: found-misalignments]

Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 0 6 94 8 96 0
0% 0% 3% 46% 4% 47% 0%

Note: The following loglevels were omitted in this report:

vv-monsalve commented 3 years ago

New FB - VF report under v0.7.38 after pulling latest files at commit 67844456da8d91cc3c62a79f6c64b7ee1666bf40

Fontbakery report

Fontbakery version: 0.7.38

[4] MontaguSlab[opsz,wght].ttf
⚠ WARN: Are there caret positions declared for every ligature? * [com.google.fonts/check/ligature_carets](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/ligature_carets) 
--- Rationale ---
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 positioning values for these ligature glyphs: - f_b.liga - f_h.liga - f_k.liga - f_t.liga - t_t.liga [code: incomplete-caret-pos-data]
⚠ WARN: Is there kerning info for non-ligated sequences? * [com.google.fonts/check/kerning_for_non_ligated_sequences](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/kerning_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** GPOS table lacks kerning info for the following non-ligated sequences: - f + f - f + b - b + f - f + h - h + f - f + i - i + f - f + k - k + f - f + l - l + b - h + i - i + k - k + l - l + t - t + t [code: lacks-kern-info]
⚠ WARN: The variable font 'opsz' (Optical Size) axis coordinate should be between 10 and 16 on the 'Regular' instance. * [com.google.fonts/check/varfont/regular_opsz_coord](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/fvar.html#com.google.fonts/check/varfont/regular_opsz_coord) 
--- Rationale ---
According to the Open-Type spec's registered design-variation tag 'opsz'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_opsz
If a variable font has an 'opsz' (Optical Size) axis, then the coordinate of its
'Regular' instance is recommended to be a value in the range 10 to 16.
* ⚠ **WARN** The "opsz" (Optical Size) coordinate on the "Regular" instance is recommended to be a value in the range 10 to 16. Got 144.0 instead. [code: out-of-range]
⚠ WARN: Are there any misaligned on-curve points? * [com.google.fonts/check/outline_alignment_miss](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/.html#com.google.fonts/check/outline_alignment_miss) 
--- Rationale ---
This check heuristically looks for on-curve points which are close to, but do
not sit on, significant boundary coordinates. For example, a point which has a
Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the
baseline, here we also check for points near the x-height (but only for lower
case Latin letters), cap-height, ascender and descender Y coordinates.
Not all such misaligned curve points are a mistake, and sometimes the design may
call for points in locations near the boundaries. As this check is liable to
generate significant numbers of false positives, it will pass if there are more
than 100 reported misalignments.
* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * uni1EB2: X=535.0,Y=981.5 (should be at ascender 982?) * uni1EA8: X=643.5,Y=981.0 (should be at ascender 982?) * uni1EA8: X=585.0,Y=983.0 (should be at ascender 982?) * uni1EA8: X=587.5,Y=983.5 (should be at ascender 982?) * uni1EC2: X=591.5,Y=981.0 (should be at ascender 982?) * uni1EC2: X=533.0,Y=983.0 (should be at ascender 982?) * uni1EC2: X=535.5,Y=983.5 (should be at ascender 982?) * uni1ED4: X=650.5,Y=981.0 (should be at ascender 982?) * uni1ED4: X=592.0,Y=983.0 (should be at ascender 982?) * uni1ED4: X=594.5,Y=983.5 (should be at ascender 982?) and 47 more. [code: found-misalignments]

Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 0 4 94 8 101 0
0% 0% 2% 45% 4% 49% 0%

Note: The following loglevels were omitted in this report:

mightybart commented 3 years ago

New report for current files (26 July):

Fontbakery report

Fontbakery version: 0.8.0

[1] Family checks
⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available? * [com.google.fonts/check/ftxvalidator_is_available](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/ftxvalidator_is_available) 
--- Rationale ---
There's no reasonable (and legal) way to run the command `ftxvalidator` of the
Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc.
If Font Bakery is not running on an OSX machine, the machine running Font Bakery
could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call
(rpc).
There's an ssh example implementation at:
https://github.com/googlefonts/fontbakery/blob/main/prebuilt/workarounds
/ftxvalidator/ssh-implementation/ftxvalidator
* ⚠ **WARN** Could not find ftxvalidator. [code: ftxvalidator-available]

[4] MontaguSlab[opsz,wght].ttf
⚠ WARN: Is there kerning info for non-ligated sequences? * [com.google.fonts/check/kerning_for_non_ligated_sequences](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/kerning_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** GPOS table lacks kerning info for the following non-ligated sequences: - f + f - f + b - b + f - f + h - h + f - f + i - i + f - f + k - k + f - f + l - l + b - h + i - i + k - k + l - l + t - t + t [code: lacks-kern-info]
⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table. * [com.google.fonts/check/meta/script_lang_tags](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/meta/script_lang_tags) 
--- 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** This font file does not have a 'meta' table. [code: lacks-meta-table]
⚠ WARN: The variable font 'opsz' (Optical Size) axis coordinate should be between 10 and 16 on the 'Regular' instance. * [com.google.fonts/check/varfont/regular_opsz_coord](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/fvar.html#com.google.fonts/check/varfont/regular_opsz_coord) 
--- Rationale ---
According to the Open-Type spec's registered design-variation tag 'opsz'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_opsz
If a variable font has an 'opsz' (Optical Size) axis, then the coordinate of its
'Regular' instance is recommended to be a value in the range 10 to 16.
* ⚠ **WARN** The "opsz" (Optical Size) coordinate on the "Regular" instance is recommended to be a value in the range 10 to 16. Got 144.0 instead. [code: out-of-range]
⚠ WARN: Are there any misaligned on-curve points? * [com.google.fonts/check/outline_alignment_miss](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/.html#com.google.fonts/check/outline_alignment_miss) 
--- Rationale ---
This check heuristically looks for on-curve points which are close to, but do
not sit on, significant boundary coordinates. For example, a point which has a
Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the
baseline, here we also check for points near the x-height (but only for lower
case Latin letters), cap-height, ascender and descender Y coordinates.
Not all such misaligned curve points are a mistake, and sometimes the design may
call for points in locations near the boundaries. As this check is liable to
generate significant numbers of false positives, it will pass if there are more
than 100 reported misalignments.
* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * uni1EB2: X=535.0,Y=981.5 (should be at ascender 982?) * uni1EA8: X=643.5,Y=981.0 (should be at ascender 982?) * uni1EA8: X=585.0,Y=983.0 (should be at ascender 982?) * uni1EA8: X=587.5,Y=983.5 (should be at ascender 982?) * uni1EC2: X=596.5,Y=981.0 (should be at ascender 982?) * uni1EC2: X=538.0,Y=983.0 (should be at ascender 982?) * uni1EC2: X=540.5,Y=983.5 (should be at ascender 982?) * uni1ED4: X=648.5,Y=981.0 (should be at ascender 982?) * uni1ED4: X=590.0,Y=983.0 (should be at ascender 982?) * uni1ED4: X=592.5,Y=983.5 (should be at ascender 982?) and 46 more. [code: found-misalignments]

Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 0 5 95 8 105 0
0% 0% 2% 45% 4% 49% 0%

Note: The following loglevels were omitted in this report: