pie6k
commented
3 years ago Is there any ETA on this?
Closed xconsau closed 3 years ago
pie6k
commented
3 years ago Is there any ETA on this?
xconsau
commented
3 years ago @RosaWagner, can we please have any information on whether this font will be updated or not? If there is any issue preventing it from the upgrade, I am ready to fix it. Please let us know. It's been almost 4 months now.
Thank you in advance.
RosaWagner
commented
3 years ago Hi, sorry, this issue got drown in the hundreds other we received since then. I take it in my queue, so it may happen in the next quarter or so. I'll get back to you when I start it.
xconsau
commented
3 years ago Thank you for the heads up. I am in process of completing another update which will make it a variable font. Will I need to open a separate issue for the update?
RosaWagner
commented
3 years ago Since the on boarding process is long, slow and involves multiple people across the world, it is better to go through this once. Ping me here when the VF is ready :)
xconsau
commented
3 years ago That would be great. I will let you know when the VF is ready. Thanks once again. :)
xconsau
commented
3 years ago @RosaWagner The VF is ready now.
Source DesignSpace + UFO files here. (Please pardon the zip format as it takes lot of time in uploading single UFO files).
Variable TTF is located here.
As of current testing with FontBakery v 0.7.36, I get the following output:
(env) E:\76\googlefonts\KumbhSans\1.0.0.3\fonts\variable>fontbakery check-googlefonts --verbose KumbhSans[opsz,wght].ttf
Start ... running 204 individual check executions.
>> com.google.fonts/check/varfont/consistent_axes
Ensure that all variable font files have the same set of axes and axis ranges.
Rationale:
In order to facilitate the construction of intuitive and friendly user
interfaces, all variable font files in a given family should have the same
set of variation axes. Also, each axis must have a consistent setting of
min/max value ranges accross all the files.
PASS All looks good!
Result: PASS
>> com.google.fonts/check/family/tnum_horizontal_metrics
All tabular figures must have the same width across the RIBBI-family.
Rationale:
Tabular figures need to have the same metrics in all styles in order to
allow tables to be set with proper typographic control, but to maintain
the placement of decimals and numeric columns between rows.
Here's a good explanation of this:
https://www.typography.com/techniques/fonts-for-financials/#tabular-figs
SKIP Unfulfilled Conditions: RIBBI_ttFonts
Result: SKIP
>> com.google.fonts/check/family/control_chars
Does font file include unacceptable control character glyphs?
Rationale:
Use of some unacceptable control characters in the U+0000 - U+001F range
can lead to rendering issues on some platforms.
Acceptable control characters are defined as .null (U+0000) and CR
(U+000D) for this test.
PASS Unacceptable control characters were not identified.
Result: PASS
>> com.google.fonts/check/STAT/axis_order
Check axis ordering on the STAT table.
Rationale:
This is (for now) a merely informative check to detect what's the axis
ordering declared on the STAT table of fonts in the Google Fonts
collection.
We may later update this to enforce some unified axis ordering scheme, yet
to be determined.
INFO From a total of 1 font files, 0 of them (0.00%) lack a STAT
table.
[2m┌────────────────────────────────────────────────────────────────────┐[0m
[2m│[0m [40mAnd these are the most common STAT axis orderings: [0m [2m│[0m
[2m│[0m [40m('wght-opsz', 1) [0m [2m│[0m
[2m└────────────────────────────────────────────────────────────────────┘[0m
[code: summary]
Result: INFO
>> com.google.fonts/check/canonical_filename
Checking file is named canonically.
with KumbhSans[opsz,wght].ttf
Rationale:
A font's filename must be composed in the following manner:
-.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
PASS KumbhSans[opsz,wght].ttf is named canonically.
Result: PASS
>> com.google.fonts/check/description/broken_links
Does DESCRIPTION file contain broken links?
with KumbhSans[opsz,wght].ttf
Rationale:
The snippet of HTML in the DESCRIPTION.en_us.html file is added to the
font family webpage on the Google Fonts website. For that reason, all
hyperlinks in it must be properly working.
SKIP Unfulfilled Conditions: description_html
Result: SKIP
>> com.google.fonts/check/description/git_url
Does DESCRIPTION file contain a upstream Git repo URL?
with KumbhSans[opsz,wght].ttf
Rationale:
The contents of the DESCRIPTION.en-us.html file are displayed on the
Google Fonts website in the about section of each font family specimen
page.
Since all of the Google Fonts collection is composed of libre-licensed
fonts, this check enforces a policy that there must be a hypertext link in
that page directing users to the repository where the font project files
are made available.
Such hosting is typically done on sites like Github, Gitlab, GNU Savannah
or any other git-based version control service.
SKIP Unfulfilled Conditions: description_html
Result: SKIP
>> com.google.fonts/check/description/valid_html
Is this a proper HTML snippet?
with KumbhSans[opsz,wght].ttf
Rationale:
Sometimes people write malformed HTML markup. This check should ensure the
file is good.
Additionally, when packaging families for being pushed to the
`google/fonts` git repo, if there is no DESCRIPTION.en_us.html file, some
older versions of the `add_font.py` tool insert a dummy description file
which contains invalid html. This file needs to either be replaced with an
existing description file or edited by hand.
SKIP Unfulfilled Conditions: description
Result: SKIP
>> com.google.fonts/check/description/min_length
DESCRIPTION.en_us.html must have more than 200 bytes.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: description
Result: SKIP
>> com.google.fonts/check/description/max_length
DESCRIPTION.en_us.html must have less than 1000 bytes.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: description
Result: SKIP
>> com.google.fonts/check/description/eof_linebreak
DESCRIPTION.en_us.html should end in a linebreak.
with KumbhSans[opsz,wght].ttf
Rationale:
Some older text-handling tools sometimes misbehave if the last line of
data in a text file is not terminated with a newline character (also known
as '\n').
We know that this is a very small detail, but for the sake of keeping all
DESCRIPTION.en_us.html files uniformly formatted throughout the GFonts
collection, we chose to adopt the practice of placing this final linebreak
char on them.
SKIP Unfulfilled Conditions: description
Result: SKIP
>> com.google.fonts/check/metadata/parses
Check METADATA.pb parse correctly.
with KumbhSans[opsz,wght].ttf
Rationale:
The purpose of this check is to ensure that the METADATA.pb file is not
malformed.
SKIP Font family at '.' lacks a METADATA.pb file. [code:
file-not-found]
Result: SKIP
>> com.google.fonts/check/metadata/unknown_designer
Font designer field in METADATA.pb must not be 'unknown'.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/multiple_designers
Font designer field in METADATA.pb must not contain 'Multiple designers'.
with KumbhSans[opsz,wght].ttf
Rationale:
For a while the string "Multiple designers" was used as a placeholder on
METADATA.pb files. We should replace all those instances with actual
designer names so that proper credits are displayed on the Google Fonts
family specimen pages.
If there's more than a single designer, the designer names must be
separated by commas.
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/designer_values
Multiple values in font designer field in METADATA.pb must be separated by commas.
with KumbhSans[opsz,wght].ttf
Rationale:
We must use commas instead of forward slashes because the server-side code
at the fonts.google.com directory will segment the string on the commas
into a list of names and display the first item in the list as the
"principal designer" while the remaining names are identified as
"contributors".
See eg https://fonts.google.com/specimen/Rubik
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/broken_links
Does METADATA.pb copyright field contain broken links?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/undeclared_fonts
Ensure METADATA.pb lists all font binaries.
with KumbhSans[opsz,wght].ttf
Rationale:
The set of font binaries available, except the ones on a "static" subdir,
must match exactly those declared on the METADATA.pb file.
Also, to avoid confusion, we expect that font files (other than statics)
are not placed on subdirectories.
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/category
Ensure METADATA.pb category field is valid.
with KumbhSans[opsz,wght].ttf
Rationale:
There are only five acceptable values for the category field in a
METADATA.pb file:
- MONOSPACE
- SANS_SERIF
- SERIF
- DISPLAY
- HANDWRITING
This check is meant to avoid typos in this field.
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/fstype
Checking OS/2 fsType does not impose restrictions.
with KumbhSans[opsz,wght].ttf
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
PASS OS/2 fsType is properly set to zero.
Result: PASS
>> com.google.fonts/check/vendor_id
Checking OS/2 achVendID.
with KumbhSans[opsz,wght].ttf
Rationale:
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.
PASS OS/2 VendorID 'XCON' looks good!
Result: PASS
>> com.google.fonts/check/glyph_coverage
Check `Google Fonts Latin Core` glyph coverage.
with KumbhSans[opsz,wght].ttf
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.
PASS OK
Result: PASS
>> com.google.fonts/check/name/unwanted_chars
Substitute copyright, registered and trademark symbols in name table entries.
with KumbhSans[opsz,wght].ttf
PASS No need to substitute copyright, registered and trademark symbols
in name table entries of this font.
Result: PASS
>> com.google.fonts/check/usweightclass
Checking OS/2 usWeightClass.
with KumbhSans[opsz,wght].ttf
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.
PASS OS/2 usWeightClass is good
Result: PASS
>> com.google.fonts/check/family/has_license
Check font has a license.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: gfonts_repo_structure
Result: SKIP
>> com.google.fonts/check/license/OFL_copyright
Check license file has good copyright string.
with KumbhSans[opsz,wght].ttf
Rationale:
An OFL.txt file's first line should be the font copyright e.g:
"Copyright 2019 The Montserrat Project Authors
(https://github.com/julietaula/montserrat)"
SKIP Unfulfilled Conditions: license_contents
Result: SKIP
>> com.google.fonts/check/name/license
Check copyright namerecords match license file.
with KumbhSans[opsz,wght].ttf
Rationale:
A known licensing description must be provided in the NameID 14 (LICENSE
DESCRIPTION) entries of the name table.
The source of truth for this check (to determine which license is in use)
is a file placed side-by-side to your font project including the licensing
terms.
Depending on the chosen license, one of the following string snippets is
expected to be found on the NameID 13 (LICENSE DESCRIPTION) entries of the
name table:
- "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"
- "Licensed under the Apache License, Version 2.0"
- "Licensed under the Ubuntu Font Licence 1.0."
Currently accepted licenses are Apache or Open Font License.
For a small set of legacy families the Ubuntu Font License may be
acceptable as well.
When in doubt, please choose OFL for new font projects.
SKIP Unfulfilled Conditions: license
Result: SKIP
>> com.google.fonts/check/name/license_url
License URL matches License text on name table?
with KumbhSans[opsz,wght].ttf
Rationale:
A known license URL must be provided in the NameID 14 (LICENSE INFO URL)
entry of the name table.
The source of truth for this check is the licensing text found on the
NameID 13 entry (LICENSE DESCRIPTION).
The string snippets used for detecting licensing terms are:
- "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"
- "Licensed under the Apache License, Version 2.0"
- "Licensed under the Ubuntu Font Licence 1.0."
Currently accepted licenses are Apache or Open Font License.
For a small set of legacy families the Ubuntu Font License may be
acceptable as well.
When in doubt, please choose OFL for new font projects.
PASS Font has a valid license URL in NAME table.
Result: PASS
>> com.google.fonts/check/name/description_max_length
Description strings in the name table must not exceed 200 characters.
with KumbhSans[opsz,wght].ttf
Rationale:
An old FontLab version had a bug which caused it to store copyright
notices in nameID 10 entries.
In order to detect those and distinguish them from actual legitimate usage
of this name table entry, we expect that such strings do not exceed a
reasonable length of 200 chars.
Longer strings are likely instances of the FontLab bug.
PASS All description name records have reasonably small lengths.
Result: PASS
>> com.google.fonts/check/hinting_impact
Show hinting filesize impact.
with KumbhSans[opsz,wght].ttf
Rationale:
This check is merely informative, displaying and useful comparison of
filesizes of hinted versus unhinted font files.
INFO Hinting filesize impact:
[1;30;44m [0m[30;44m [0m[1;30;44m [0m[1;30;44mKumbhSans[0m[1;30;44m.ttf[0m[1;30;44m [0m
[37;40m [0m[37;40mDehinted Size[0m[37;40m [0m[30;40m [0m[37;40m [0m[37;40m 156.2kb[0m[37;40m [0m
[37;40m [0m[37;40mHinted Size [0m[37;40m [0m[30;40m [0m[37;40m [0m[37;40m 156.2kb[0m[37;40m [0m
[37;40m [0m[37;40mIncrease [0m[37;40m [0m[30;40m [0m[37;40m [0m[37;40m 24 bytes[0m[37;40m [0m
[37;40m [0m[37;40mChange [0m[37;40m [0m[30;40m [0m[37;40m [0m[37;40m 0.0 %[0m[37;40m [0m
[code: size-impact]
Result: INFO
>> com.google.fonts/check/name/version_format
Version format is correct in 'name' table?
with KumbhSans[opsz,wght].ttf
PASS Version format in NAME table entries is correct.
Result: PASS
>> com.google.fonts/check/has_ttfautohint_params
Font has ttfautohint params?
with KumbhSans[opsz,wght].ttf
SKIP Font appears to our heuristic as not hinted using ttfautohint.
[code: not-hinted]
Result: SKIP
>> com.google.fonts/check/old_ttfautohint
Font has old ttfautohint applied?
with KumbhSans[opsz,wght].ttf
Rationale:
This check finds which version of ttfautohint was used, by inspecting name
table entries and then finds which version of ttfautohint is currently
installed in the system.
ERROR ttfautohint is not available. [code: not-available]
Result: ERROR
>> com.google.fonts/check/epar
EPAR table present in font?
with KumbhSans[opsz,wght].ttf
Rationale:
The EPAR table is/was a way of expressing common licensing permissions and
restrictions in metadata; while almost nothing supported it, Dave
Crossland wonders that adding it to everything in Google Fonts could help
make it more popular.
More info is available at:
https://davelab6.github.io/epar/
INFO EPAR table not present in font. To learn more see
https://github.com/googlefonts/fontbakery/issues/818 [code:
lacks-EPAR]
Result: INFO
>> com.google.fonts/check/gasp
Is the Grid-fitting and Scan-conversion Procedure ('gasp') table set to optimize rendering?
with KumbhSans[opsz,wght].ttf
Rationale:
Traditionally version 0 'gasp' tables were set so that font sizes below 8
ppem had no grid fitting but did have antialiasing. From 9-16 ppem, just
grid fitting. And fonts above 17ppem had both antialiasing and grid
fitting toggled on. The use of accelerated graphics cards and higher
resolution screens make this approach obsolete. Microsoft's DirectWrite
pushed this even further with much improved rendering built into the OS
and apps.
In this scenario it makes sense to simply toggle all 4 flags ON for all
font sizes.
INFO These are the ppm ranges declared on the gasp table:
PPM <= 65535: flag = 0x0F - Use grid-fitting - Use grayscale rendering
- Use gridfitting with ClearType symmetric smoothing - Use smoothing
along multiple axes with ClearType®
[code: ranges]
PASS The 'gasp' table is correctly set, with one gaspRange:value of
0xFFFF:0x0F.
Result: INFO
>> com.google.fonts/check/name/familyname_first_char
Make sure family name does not begin with a digit.
with KumbhSans[opsz,wght].ttf
Rationale:
Font family names which start with a numeral are often not discoverable in
Windows applications.
PASS Font family name first character is not a digit.
Result: PASS
>> com.google.fonts/check/name/ascii_only_entries
Are there non-ASCII characters in ASCII-only NAME table entries?
with KumbhSans[opsz,wght].ttf
Rationale:
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.
PASS None of the ASCII-only NAME table entries contain non-ASCII
characteres.
Result: PASS
>> com.google.fonts/check/metadata/listed_on_gfonts
METADATA.pb: Fontfamily is listed on Google Fonts API?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/unique_full_name_values
METADATA.pb: check if fonts field only has unique "full_name" values.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/unique_weight_style_pairs
METADATA.pb: check if fonts field only contains unique style:weight pairs.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/license
METADATA.pb license is "APACHE2", "UFL" or "OFL"?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/menu_and_latin
METADATA.pb should contain at least "menu" and "latin" subsets.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/subsets_order
METADATA.pb subsets should be alphabetically ordered.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/includes_production_subsets
Check METADATA.pb includes production subsets.
with KumbhSans[opsz,wght].ttf
Rationale:
Check METADATA.pb file includes the same subsets as the family in
production.
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/copyright
METADATA.pb: Copyright notice is the same in all fonts?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/familyname
Check that METADATA.pb family values are all the same.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/has_regular
METADATA.pb: According to Google Fonts standards, families should have a Regular style.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/regular_is_400
METADATA.pb: Regular should be 400.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata, has_regular_style
Result: SKIP
>> com.google.fonts/check/metadata/nameid/family_name
Checks METADATA.pb font.name field matches family name declared on the name table.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/nameid/post_script_name
Checks METADATA.pb font.post_script_name matches postscript name declared on the name table.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/nameid/full_name
METADATA.pb font.full_name value matches fullname declared on the name table?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/nameid/font_name
METADATA.pb font.name value should be same as the family name declared on the name table.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata, style
Result: SKIP
>> com.google.fonts/check/metadata/match_fullname_postscript
METADATA.pb font.full_name and font.post_script_name fields have equivalent values ?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/match_filename_postscript
METADATA.pb font.filename and font.post_script_name fields have equivalent values?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata, not is_variable_font
Result: SKIP
>> com.google.fonts/check/metadata/valid_name_values
METADATA.pb font.name field contains font name in right format?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: style, font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/valid_full_name_values
METADATA.pb font.full_name field contains font name in right format?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: style, font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/valid_filename_values
METADATA.pb font.filename field contains font name in right format?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: style, family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/valid_post_script_name_values
METADATA.pb font.post_script_name field contains font name in right format?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/valid_copyright
Copyright notices match canonical pattern in METADATA.pb
with KumbhSans[opsz,wght].ttf
Rationale:
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)
* Then it must say "The Project Authors"
* And within parentheses, a URL for a git repository must be provided
* The check is case insensitive and does not validate whether the
familyname is correct, even though we'd expect it is (and we may soon
update the check to validate that aspect as well!)
Here is an example of a valid copyright string:
"Copyright 2017 The Archivo Black Project Authors
(https://github.com/Omnibus-Type/ArchivoBlack)"
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/font_copyright
Copyright notices match canonical pattern in fonts
with KumbhSans[opsz,wght].ttf
PASS Name Table entry: Copyright field 'Copyright 2020 The KumbhSans
Project Authors (https://github.com/xconsau/KumbhSans)' matches
canonical pattern.
PASS Name table copyright entries are good
Result: PASS
>> com.google.fonts/check/metadata/reserved_font_name
Copyright notice on METADATA.pb should not contain 'Reserved Font Name'.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/copyright_max_length
METADATA.pb: Copyright notice shouldn't exceed 500 chars.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/filenames
METADATA.pb: Font filenames match font.filename entries?
with KumbhSans[opsz,wght].ttf
Rationale:
Note:
This check only looks for files in the current directory.
Font files in subdirectories are checked by these other two checks:
- com.google.fonts/check/metadata/undeclared_fonts
- com.google.fonts/check/repo/vf_has_static_fonts
We may want to merge them all into a single check.
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/italic_style
METADATA.pb font.style "italic" matches font internals?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/normal_style
METADATA.pb font.style "normal" matches font internals?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/nameid/family_and_full_names
METADATA.pb font.name and font.full_name fields match the values declared on the name table?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/fontname_not_camel_cased
METADATA.pb: Check if fontname is not camel cased.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/match_name_familyname
METADATA.pb: Check font name is the same as family name.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata, font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/canonical_weight_value
METADATA.pb: Check that font weight has a canonical value.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/os2_weightclass
Check METADATA.pb font weights are correct.
with KumbhSans[opsz,wght].ttf
Rationale:
Check METADATA.pb font weights are correct.
For static fonts, the metadata weight should be the same as the static
font's OS/2 usWeightClass.
For variable fonts, the weight value should be 400 if the font's wght axis
range includes 400, otherwise it should be the value closest to 400.
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/metadata/match_weight_postscript
METADATA.pb weight matches postScriptName for static fonts.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata, not is_variable_font
Result: SKIP
>> com.google.fonts/check/metadata/canonical_style_names
METADATA.pb: Font styles are named canonically?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/unitsperem_strict
Stricter unitsPerEm criteria for Google Fonts.
with KumbhSans[opsz,wght].ttf
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.
PASS Font em size is good (unitsPerEm = 2048).
Result: PASS
>> com.google.fonts/check/version_bump
Version number has increased since previous release on Google Fonts?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: api_gfonts_ttFont, github_gfonts_ttFont
Result: SKIP
>> com.google.fonts/check/production_glyphs_similarity
Glyphs are similiar to Google Fonts version?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: api_gfonts_ttFont
Result: SKIP
>> com.google.fonts/check/fsselection
Checking OS/2 fsSelection value.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: style
Result: SKIP
>> com.google.fonts/check/italic_angle
Checking post.italicAngle value.
with KumbhSans[opsz,wght].ttf
Rationale:
The 'post' table italicAngle property should be a reasonable amount,
likely not more than -20°, never more than -30°, and never greater than
0°. Note that in the OpenType specification, the value is negative for a
lean rightwards.
https://docs.microsoft.com/en-us/typography/opentype/spec/post
SKIP Unfulfilled Conditions: style
Result: SKIP
>> com.google.fonts/check/mac_style
Checking head.macStyle value.
with KumbhSans[opsz,wght].ttf
Rationale:
The values of the flags on the macStyle entry on the 'head' OpenType table
that describe whether a font is bold and/or italic must be coherent with
the actual style of the font as inferred by its filename.
SKIP Unfulfilled Conditions: style
Result: SKIP
>> com.google.fonts/check/contour_count
Check if each glyph has the recommended amount of contours.
with KumbhSans[opsz,wght].ttf
Rationale:
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.
SKIP Unfulfilled Conditions: not is_variable_font
Result: SKIP
>> com.google.fonts/check/metadata/nameid/copyright
Copyright field for this font on METADATA.pb matches all copyright notice entries on the name table ?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: font_metadata
Result: SKIP
>> com.google.fonts/check/name/mandatory_entries
Font has all mandatory 'name' table entries?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: style
Result: SKIP
>> com.google.fonts/check/name/familyname
Check name table: FONT_FAMILY_NAME entries.
with KumbhSans[opsz,wght].ttf
Rationale:
Checks that the family name infered from the font filename matches the
string at nameID 1 (NAMEID_FONT_FAMILY_NAME) if it conforms to RIBBI and
otherwise checks that nameID 1 is the family name + the style name.
SKIP Unfulfilled Conditions: style
Result: SKIP
>> com.google.fonts/check/name/subfamilyname
Check name table: FONT_SUBFAMILY_NAME entries.
with KumbhSans[opsz,wght].ttf
PASS FONT_SUBFAMILY_NAME entries are all good.
Result: PASS
>> com.google.fonts/check/name/fullfontname
Check name table: FULL_FONT_NAME entries.
with KumbhSans[opsz,wght].ttf
Rationale:
Requirements for the FULL_FONT_NAME entries in the 'name' table.
SKIP Unfulfilled Conditions: style_with_spaces
Result: SKIP
>> com.google.fonts/check/name/postscriptname
Check name table: POSTSCRIPT_NAME entries.
with KumbhSans[opsz,wght].ttf
Rationale:
Requirements for the POSTSCRIPT_NAME entries in the 'name' table.
SKIP Unfulfilled Conditions: style
Result: SKIP
>> com.google.fonts/check/name/typographicfamilyname
Check name table: TYPOGRAPHIC_FAMILY_NAME entries.
with KumbhSans[opsz,wght].ttf
Rationale:
Requirements for the TYPOGRAPHIC_FAMILY_NAME entries in the 'name' table.
SKIP Unfulfilled Conditions: style
Result: SKIP
>> com.google.fonts/check/name/typographicsubfamilyname
Check name table: TYPOGRAPHIC_SUBFAMILY_NAME entries.
with KumbhSans[opsz,wght].ttf
Rationale:
Requirements for the TYPOGRAPHIC_SUBFAMILY_NAME entries in the 'name'
table.
PASS TYPOGRAPHIC_SUBFAMILY_NAME entries are all good.
Result: PASS
>> com.google.fonts/check/name/copyright_length
Length of copyright notice must not exceed 500 characters.
with KumbhSans[opsz,wght].ttf
Rationale:
This is an arbitrary max length for the copyright notice field of the name
table. We simply don't want such notices to be too long. Typically such
notices are actually much shorter than this with a length of roughly 70 or
80 characters.
PASS All copyright notice name entries on the 'name' table are shorter
than 500 characters.
Result: PASS
>> com.google.fonts/check/fontdata_namecheck
Familyname must be unique according to namecheck.fontdata.com
with KumbhSans[opsz,wght].ttf
Rationale:
We need to check names are not already used, and today the best place to
check that is http://namecheck.fontdata.com
PASS Font familyname seems to be unique.
Result: PASS
>> com.google.fonts/check/fontv
Check for font-v versioning.
with KumbhSans[opsz,wght].ttf
Rationale:
The git sha1 tagging and dev/release features of Source Foundry `font-v`
tool are awesome and we would love to consider upstreaming the approach
into fontmake someday. For now we only emit a WARN if a given font does
not yet follow the experimental versioning style, but at some point we may
start enforcing it.
INFO Version string is: "Version 1.003" The version string must
ideally include a git commit hash and either a "dev" or a "release"
suffix such as in the example below: "Version 1.3;
git-0d08353-release" [code: bad-format]
Result: INFO
>> com.google.fonts/check/varfont/generate_static
Check a static ttf can be generated from a variable font.
with KumbhSans[opsz,wght].ttf
Rationale:
Google Fonts may serve static fonts which have been generated from
variable fonts. This test will attempt to generate a static ttf using
fontTool's varLib mutator.
The target font will be the mean of each axis e.g:
**VF font axes**
- min weight, max weight = 400, 800
- min width, max width = 50, 100
**Target Instance**
- weight = 600
- width = 75
PASS fontTools.varLib.mutator generated a static font instance
Result: PASS
>> com.google.fonts/check/varfont/has_HVAR
Check that variable fonts have an HVAR table.
with KumbhSans[opsz,wght].ttf
Rationale:
Not having a HVAR table can lead to costly text-layout operations on some
platforms, which we want to avoid.
So, all variable fonts on the Google Fonts collection should have an HVAR
with valid values.
More info on the HVAR table can be found at:
https://docs.microsoft.com/en-us/typography/opentype/spec
/otvaroverview#variation-data-tables-and-miscellaneous-requirements
PASS This variable font contains an HVAR table.
Result: PASS
>> com.google.fonts/check/smart_dropout
Font enables smart dropout control in "prep" table instructions?
with KumbhSans[opsz,wght].ttf
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.
PASS 'prep' table contains instructions enabling smart dropout
control.
Result: PASS
>> com.google.fonts/check/vttclean
There must not be VTT Talk sources in the font.
with KumbhSans[opsz,wght].ttf
Rationale:
The goal here is to reduce filesizes and improve pageloading when dealing
with webfonts.
The VTT Talk sources are not necessary at runtime and endup being just
dead weight when left embedded in the font binaries. The sources should be
kept on the project files but stripped out when building release binaries.
PASS There are no tables with VTT Talk sources embedded in the font.
Result: PASS
>> com.google.fonts/check/aat
Are there unwanted Apple tables?
with KumbhSans[opsz,wght].ttf
Rationale:
Apple's TrueType reference manual [1] describes SFNT tables not in the
Microsoft OpenType specification [2] and these can sometimes sneak into
final release files, but Google Fonts should only have OpenType tables.
[1]
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06
/Chap6.html
[2] https://docs.microsoft.com/en-us/typography/opentype/spec/
PASS There are no unwanted AAT tables.
Result: PASS
>> com.google.fonts/check/fvar_name_entries
All name entries referenced by fvar instances exist on the name table?
with KumbhSans[opsz,wght].ttf
Rationale:
The purpose of this check is to make sure that all name entries referenced
by variable font instances do exist in the name table.
PASS OK
Result: PASS
>> com.google.fonts/check/varfont_has_instances
A variable font must have named instances.
with KumbhSans[opsz,wght].ttf
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.
PASS OK
Result: PASS
>> com.google.fonts/check/varfont_weight_instances
Variable font weight coordinates must be multiples of 100.
with KumbhSans[opsz,wght].ttf
Rationale:
The named instances on the weight axis of a variable font must have
coordinates that are multiples of 100 on the design space.
PASS OK
Result: PASS
>> com.google.fonts/check/integer_ppem_if_hinted
PPEM must be an integer on hinted fonts.
with KumbhSans[opsz,wght].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;
SKIP Unfulfilled Conditions: is_hinted
Result: SKIP
>> com.google.fonts/check/ligature_carets
Are there caret positions declared for every ligature?
with KumbhSans[opsz,wght].ttf
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.
SKIP Unfulfilled Conditions: ligature_glyphs
Result: SKIP
>> com.google.fonts/check/kerning_for_non_ligated_sequences
Is there kerning info for non-ligated sequences?
with KumbhSans[opsz,wght].ttf
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).
SKIP Unfulfilled Conditions: ligatures
Result: SKIP
>> com.google.fonts/check/name/family_and_style_max_length
Combined length of family and style must not exceed 27 characters.
with KumbhSans[opsz,wght].ttf
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
PASS All name entries are good.
Result: PASS
>> com.google.fonts/check/name/line_breaks
Name table entries should not contain line-breaks.
with KumbhSans[opsz,wght].ttf
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
PASS Name table entries are all single-line (no line-breaks found).
Result: PASS
>> com.google.fonts/check/name/rfn
Name table strings must not contain the string 'Reserved Font Name'.
with KumbhSans[opsz,wght].ttf
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.
PASS None of the name table strings contain "Reserved Font Name".
Result: PASS
>> com.google.fonts/check/repo/dirname_matches_nameid_1
Directory name in GFonts repo structure must match NameID 1 of the regular.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: gfonts_repo_structure, not
is_variable_font
Result: SKIP
>> com.google.fonts/check/repo/vf_has_static_fonts
A static fonts directory with at least two fonts must accompany variable fonts
with KumbhSans[opsz,wght].ttf
Rationale:
Variable font family directories kept in the google/fonts git repo may
include a static/ subdir containing static fonts.
These files are meant to be served for users that still lack support for
variable fonts in their web browsers.
SKIP Unfulfilled Conditions: gfonts_repo_structure
Result: SKIP
>> com.google.fonts/check/repo/fb_report
A font repository should not include fontbakery report files
with KumbhSans[opsz,wght].ttf
Rationale:
A FontBakery report is ephemeral and so should be used for posting issues
on a bug-tracker instead of being hosted in the font project repository.
PASS OK
Result: PASS
>> com.google.fonts/check/repo/zip_files
A font repository should not include ZIP files
with KumbhSans[opsz,wght].ttf
Rationale:
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.
PASS OK
Result: PASS
>> com.google.fonts/check/vertical_metrics_regressions
Check if the vertical metrics of a family are similar to the same family hosted on Google Fonts.
with KumbhSans[opsz,wght].ttf
Rationale:
If the family already exists on Google Fonts, we need to ensure that the
checked family's vertical metrics are similar. This check will test the
following schema which was outlined in Fontbakery issue #1162 [1]:
- The family should visually have the same vertical metrics as the Regular
style hosted on Google Fonts.
- If the family on Google Fonts has differing hhea and typo metrics, the
family being checked should use the typo metrics for both the hhea and
typo entries.
- If the family on Google Fonts has use typo metrics not enabled and the
family being checked has it enabled, the hhea and typo metrics should use
the family on Google Fonts winAscent and winDescent values.
- If the upms differ, the values must be scaled so the visual appearance
is the same.
[1] https://github.com/googlefonts/fontbakery/issues/1162
FAIL Kumbh Sans Regular: OS/2 sTypoAscender is 2045 when it should be
1540 [code: bad-typo-ascender]
FAIL Kumbh Sans Regular: hhea Ascender is 2045 when it should be 1540
[code: bad-hhea-ascender]
Result: FAIL
>> com.google.fonts/check/cjk_vertical_metrics
Check font follows the Google Fonts CJK vertical metric schema
with KumbhSans[opsz,wght].ttf
Rationale:
CJK fonts have different vertical metrics when compared to Latin fonts. We
follow the schema developed by dr Ken Lunde for Source Han Sans and the
Noto CJK fonts.
Our documentation includes further information:
https://github.com/googlefonts/gf-docs/tree/main/Spec#cjk-vertical-metrics
SKIP Unfulfilled Conditions: is_cjk_font, not remote_styles
Result: SKIP
>> com.google.fonts/check/cjk_vertical_metrics_regressions
Check if the vertical metrics of a CJK family are similar to the same family hosted on Google Fonts.
with KumbhSans[opsz,wght].ttf
Rationale:
Check CJK family has the same vertical metrics as the same family hosted
on Google Fonts.
SKIP Unfulfilled Conditions: is_cjk_font
Result: SKIP
>> com.google.fonts/check/cjk_not_enough_glyphs
Does the font contain less than 40 CJK characters?
with KumbhSans[opsz,wght].ttf
Rationale:
Hangul has 40 characters and it's the smallest CJK writing system.
If a font contains less CJK glyphs than this writing system, we inform the
user that some glyphs may be encoded incorrectly.
SKIP Unfulfilled Conditions: is_cjk_font
Result: SKIP
>> com.google.fonts/check/varfont_instance_coordinates
Check variable font instances have correct coordinate values
with KumbhSans[opsz,wght].ttf
PASS Instance coordinates are correct
Result: PASS
>> com.google.fonts/check/varfont_instance_names
Check variable font instances have correct names
with KumbhSans[opsz,wght].ttf
PASS Instance names are correct
Result: PASS
>> com.google.fonts/check/varfont_duplicate_instance_names
Check variable font instances don't have duplicate names
with KumbhSans[opsz,wght].ttf
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.
PASS Instance names are unique
Result: PASS
>> com.google.fonts/check/varfont/unsupported_axes
Ensure VFs do not contain slnt or ital axes.
with KumbhSans[opsz,wght].ttf
Rationale:
The 'ital' and 'slnt' axes are not supported yet in Google Chrome.
For the time being, we need to ensure that VFs do not contain either of
these axes. Once browser support is better, we can deprecate this check.
For more info regarding browser support, see:
https://arrowtype.github.io/vf-slnt-test/
PASS Looks good!
Result: PASS
>> com.google.fonts/check/metadata/gf-axisregistry_bounds
Validate METADATA.pb axes values are within gf-axisregistry bounds.
with KumbhSans[opsz,wght].ttf
Rationale:
Each axis range in a METADATA.pb file must be registered, and within the
bounds of the axis definition in the Google Fonts Axis Registry, available
at https://github.com/google/fonts/tree/main/axisregistry
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/gf-axisregistry_valid_tags
Validate METADATA.pb axes tags are defined in gf-axisregistry.
with KumbhSans[opsz,wght].ttf
Rationale:
Ensure all axes in a METADATA.pb file are registered in the Google Fonts
Axis Registry, available at
https://github.com/google/fonts/tree/main/axisregistry
Why does Google Fonts have its own Axis Registry?
We support a superset of the OpenType axis registry axis set, and use
additional metadata for each axis. Axes present in a font file but not in
this registry will not function via our API. No variable font is expected
to support all of the axes here.
Any font foundry or distributor library that offers variable fonts has a
implicit, latent, de-facto axis registry, which can be extracted by
scanning the library for axes' tags, labels, and min/def/max values. While
in 2016 Microsoft originally offered to include more axes in the OpenType
1.8 specification (github.com/microsoft/OpenTypeDesignVariationAxisTags),
as of August 2020, this effort has stalled. We hope more foundries and
distributors will publish documents like this that make their axes
explicit, to encourage of adoption of variable fonts throughout the
industry, and provide source material for a future update to the OpenType
specification's axis registry.
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/gf-axisregistry/fvar_axis_defaults
Validate defaults on fvar table match registered fallback names in GFAxisRegistry.
with KumbhSans[opsz,wght].ttf
Rationale:
Check that axis defaults have a corresponding fallback name registered at
the Google Fonts Axis Registry, available at
https://github.com/google/fonts/tree/main/axisregistry
This is necessary for the following reasons:
To get ZIP files downloads on Google Fonts to be accurate — otherwise the
chosen default font is not generated. The Newsreader family, for instance,
has a default value on the 'opsz' axis of 16pt. If 16pt was not a
registered fallback position, then the ZIP file would instead include
another position as default (such as 14pt).
For the Variable fonts to display the correct location on the specimen
page.
For VF with no weight axis to be displayed at all. For instance, Ballet,
which has no weight axis, was not appearing in sandbox because default
position on 'opsz' axis was 16pt, and it was not yet a registered fallback
positon.
PASS OK
Result: PASS
>> com.google.fonts/check/STAT/gf-axisregistry
Validate STAT particle names and values match the fallback names in GFAxisRegistry.
with KumbhSans[opsz,wght].ttf
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]
Result: FAIL
>> com.google.fonts/check/metadata/consistent_axis_enumeration
Validate VF axes match the ones declared on METADATA.pb.
with KumbhSans[opsz,wght].ttf
Rationale:
All font variation axes present in the font files must be properly
declared on METADATA.pb so that they can be served by the GFonts API.
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/metadata/escaped_strings
Ensure METADATA.pb does not use escaped strings.
with KumbhSans[opsz,wght].ttf
Rationale:
In some cases we've seen designer names and other fields with escaped
strings in METADATA files.
Nowadays the strings can be full unicode strings and do not need escaping.
SKIP Unfulfilled Conditions: metadata_file
Result: SKIP
>> com.google.fonts/check/metadata/designer_profiles
METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: family_metadata
Result: SKIP
>> com.google.fonts/check/mandatory_avar_table
Ensure variable fonts include an avar table.
with KumbhSans[opsz,wght].ttf
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]
Result: FAIL
>> com.google.fonts/check/description/family_update
On a family update, the DESCRIPTION.en_us.html file should ideally also be updated.
with KumbhSans[opsz,wght].ttf
Rationale:
We want to ensure that any significant changes to the font family are
properly mentioned in the DESCRIPTION file.
In general, it means that the contents of the DESCRIPTION.en_us.html file
will typically change if when font files are updated. Please treat this
check as a reminder to do so whenever appropriate!
SKIP Unfulfilled Conditions: description, github_gfonts_description
Result: SKIP
>> com.google.fonts/check/missing_small_caps_glyphs
Check small caps glyphs are available
with KumbhSans[opsz,wght].ttf
Rationale:
Ensure small caps glyphs are available if a font declares smcp or c2sc OT
features
PASS OK
Result: PASS
>> com.google.fonts/check/stylisticset_description
Ensure Stylistic Sets have description.
with KumbhSans[opsz,wght].ttf
Rationale:
Stylistic sets must provide description text. Programs such as InDesign,
TextEdit and Inkscape use that info to display to the users so that they
know what a given stylistic set offers.
PASS OK
Result: PASS
>> com.google.fonts/check/family/single_directory
Checking all files are in the same directory.
Rationale:
If the set of font files passed in the command line is not all in the same
directory, then we warn the user since the tool will interpret the set of
files as belonging to a single family (and it is unlikely that the user
would store the files from a single family spreaded in several separate
directories).
PASS All files are in the same directory.
Result: PASS
>> com.google.fonts/check/ftxvalidator_is_available
Is the command `ftxvalidator` (Apple Font Tool Suite) 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]
Result: WARN
>> com.google.fonts/check/fontbakery_version
Do we have the latest version of FontBakery installed?
PASS Font Bakery is up-to-date
Result: PASS
>> com.google.fonts/check/family/vertical_metrics
Each font in a family must have the same set of vertical metrics values.
Rationale:
We want all fonts within a family to have the same vertical metrics so
their line spacing is consistent across the family.
PASS Vertical metrics are the same across the family.
Result: PASS
>> com.google.fonts/check/name/trailing_spaces
Name table records must not have trailing spaces.
with KumbhSans[opsz,wght].ttf
PASS No trailing spaces on name table entries.
Result: PASS
>> com.google.fonts/check/family/win_ascent_and_descent
Checking OS/2 usWinAscent & usWinDescent.
with KumbhSans[opsz,wght].ttf
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).
PASS OS/2 usWinAscent & usWinDescent values look good!
Result: PASS
>> com.google.fonts/check/os2_metrics_match_hhea
Checking OS/2 Metrics match hhea Metrics.
with KumbhSans[opsz,wght].ttf
Rationale:
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.
PASS OS/2.sTypoAscender/Descender values match hhea.ascent/descent.
Result: PASS
>> com.google.fonts/check/ftxvalidator
Checking with ftxvalidator.
with KumbhSans[opsz,wght].ttf
SKIP Unfulfilled Conditions: ftxvalidator_cmd
Result: SKIP
>> com.google.fonts/check/ots
Checking with ots-sanitize.
with KumbhSans[opsz,wght].ttf
PASS ots-sanitize passed this file
Result: PASS
>> com.google.fonts/check/mandatory_glyphs
Font contains '.notdef' as its first glyph?
with KumbhSans[opsz,wght].ttf
Rationale:
The OpenType specification v1.8.2 recommends that the first glyph is the
'.notdef' glyph without a codepoint assigned and with a drawing.
https://docs.microsoft.com/en-us/typography/opentype/spec
/recom#glyph-0-the-notdef-glyph
Pre-v1.8, it was recommended that fonts should also contain 'space', 'CR'
and '.null' glyphs. This might have been relevant for MacOS 9
applications.
PASS OK
Result: PASS
>> com.google.fonts/check/whitespace_glyphs
Font contains glyphs for whitespace characters?
with KumbhSans[opsz,wght].ttf
PASS Font contains glyphs for whitespace characters.
Result: PASS
>> com.google.fonts/check/whitespace_glyphnames
Font has **proper** whitespace glyph names?
with KumbhSans[opsz,wght].ttf
Rationale:
This check enforces adherence to recommended whitespace (codepoints 0020
and 00A0) glyph names according to the Adobe Glyph List.
PASS Font has [1mAGL recommended[0m names for whitespace glyphs.
Result: PASS
>> com.google.fonts/check/whitespace_ink
Whitespace glyphs have ink?
with KumbhSans[opsz,wght].ttf
PASS There is no whitespace glyph with ink.
Result: PASS
>> com.google.fonts/check/required_tables
Font contains all required tables?
with KumbhSans[opsz,wght].ttf
Rationale:
Depending on the typeface and coverage of a font, certain tables are
recommended for optimum quality. For example, the performance of a
non-linear font is improved if the VDMX, LTSH, and hdmx tables are
present. Non-monospaced Latin fonts should have a kern table. A gasp table
is necessary if a designer wants to influence the sizes at which
grayscaling is used under Windows. A DSIG table containing a digital
signature helps ensure the integrity of the font file. Etc.
INFO This font contains the following optional tables:
[1;33m • [0mloca
[1;33m • [0mprep
[1;33m • [0mGPOS
[1;33m • [0mDSIG
[1;33m • [0mgasp [code: required-tables]
PASS Font contains all required tables.
Result: INFO
>> com.google.fonts/check/unwanted_tables
Are there unwanted tables?
with KumbhSans[opsz,wght].ttf
Rationale:
Some font editors store source data in their own SFNT tables, and these
can sometimes sneak into final release files, which should only have
OpenType spec tables.
PASS There are no unwanted tables.
Result: PASS
>> com.google.fonts/check/STAT_strings
Check correctness of STAT table strings
with KumbhSans[opsz,wght].ttf
Rationale:
On the STAT table, the "Italic" keyword must not be used on AxisValues for
variation axes other than 'ital'.
PASS Looks good!
Result: PASS
>> com.google.fonts/check/valid_glyphnames
Glyph names are all valid?
with KumbhSans[opsz,wght].ttf
Rationale:
Microsoft's recommendations for OpenType Fonts states the following:
'NOTE: The PostScript glyph name must be no longer than 31 characters,
include only uppercase or lowercase English letters, European digits, the
period or the underscore, i.e. from the set [A-Za-z0-9_.] and should start
with a letter, except the special glyph name ".notdef" which starts with a
period.'
https://docs.microsoft.com/en-us/typography/opentype/spec/recom#post-table
In practice, though, particularly in modern environments, glyph names can
be as long as 63 characters.
According to the "Adobe Glyph List Specification" available at:
https://github.com/adobe-type-tools/agl-specification
PASS Glyph names are all valid.
Result: PASS
>> com.google.fonts/check/unique_glyphnames
Font contains unique glyph names?
with KumbhSans[opsz,wght].ttf
Rationale:
Duplicate glyph names prevent font installation on Mac OS X.
PASS Font contains unique glyph names.
Result: PASS
>> com.google.fonts/check/ttx-roundtrip
Checking with fontTools.ttx
with KumbhSans[opsz,wght].ttf
PASS Hey! It all looks good!
Result: PASS
>> com.google.fonts/check/superfamily/list
List all superfamily filepaths
with KumbhSans[opsz,wght].ttf
Rationale:
This is a merely informative check that lists all sibling families
detected by fontbakery.
Only the fontfiles in these directories will be considered in
superfamily-level checks.
INFO . [code: family-path]
Result: INFO
>> com.google.fonts/check/superfamily/vertical_metrics
Each font in set of sibling families must have the same set of vertical metrics values.
with KumbhSans[opsz,wght].ttf
Rationale:
We may want all fonts within a super-family (all sibling families) to have
the same vertical metrics so their line spacing is consistent across the
super-family.
This is an experimental extended version of
com.google.fonts/check/superfamily/vertical_metrics and for now it will
only result in WARNs.
SKIP Sibling families were not detected.
Result: SKIP
>> com.google.fonts/check/rupee
Ensure indic fonts have the Indian Rupee Sign glyph.
with KumbhSans[opsz,wght].ttf
Rationale:
Per Bureau of Indian Standards every font supporting one of the official
Indian languages needs to include Unicode Character “₹” (U+20B9) Indian
Rupee Sign.
SKIP Unfulfilled Conditions: is_indic_font
Result: SKIP
>> com.adobe.fonts/check/cff_call_depth
Is the CFF subr/gsubr call depth > 10?
with KumbhSans[opsz,wght].ttf
Rationale:
Per "The Type 2 Charstring Format, Technical Note #5177", the "Subr
nesting, stack limit" is 10.
SKIP Unfulfilled Conditions: is_cff
Result: SKIP
>> com.adobe.fonts/check/cff2_call_depth
Is the CFF2 subr/gsubr call depth > 10?
with KumbhSans[opsz,wght].ttf
Rationale:
Per "The CFF2 CharString Format", the "Subr nesting, stack limit" is 10.
SKIP Unfulfilled Conditions: is_cff2
Result: SKIP
>> com.adobe.fonts/check/cff_deprecated_operators
Does the font use deprecated CFF operators or operations?
with KumbhSans[opsz,wght].ttf
Rationale:
The 'dotsection' operator and the use of 'endchar' to build accented
characters from the Adobe Standard Encoding Character Set ("seac") are
deprecated in CFF. Adobe recommends repairing any fonts that use these,
especially endchar-as-seac, because a rendering issue was discovered in
Microsoft Word with a font that makes use of this operation. The check
treats that useage as a FAIL. There are no known ill effects of using
dotsection, so that check is a WARN.
SKIP Unfulfilled Conditions: is_cff
Result: SKIP
>> com.google.fonts/check/family/equal_unicode_encodings
Fonts have equal unicode encodings?
PASS Fonts have equal unicode encodings.
Result: PASS
>> com.google.fonts/check/all_glyphs_have_codepoints
Check all glyphs have codepoints assigned.
with KumbhSans[opsz,wght].ttf
PASS All glyphs have a codepoint value assigned.
Result: PASS
>> com.google.fonts/check/family/equal_font_versions
Make sure all font files have the same version value.
PASS All font files have the same version.
Result: PASS
>> com.google.fonts/check/unitsperem
Checking unitsPerEm value is reasonable.
with KumbhSans[opsz,wght].ttf
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.
PASS The unitsPerEm value (2048) on the 'head' table is reasonable.
Result: PASS
>> com.google.fonts/check/font_version
Checking font version fields (head and name table).
with KumbhSans[opsz,wght].ttf
PASS All font version fields match.
Result: PASS
>> com.google.fonts/check/family/panose_proportion
Fonts have consistent PANOSE proportion?
PASS Fonts have consistent PANOSE proportion.
Result: PASS
>> com.google.fonts/check/family/panose_familytype
Fonts have consistent PANOSE family type?
PASS Fonts have consistent PANOSE family type.
Result: PASS
>> com.adobe.fonts/check/family/bold_italic_unique_for_nameid1
Check that OS/2.fsSelection bold & italic settings are unique for each NameID1
Rationale:
Per the OpenType spec: name ID 1 'is used in combination with Font
Subfamily name (name ID 2), and should be shared among at most four fonts
that differ only in weight or style...
This four-way distinction should also be reflected in the OS/2.fsSelection
field, using bits 0 and 5.
SKIP Unfulfilled Conditions: RIBBI_ttFonts
Result: SKIP
>> com.google.fonts/check/xavgcharwidth
Check if OS/2 xAvgCharWidth is correct.
with KumbhSans[opsz,wght].ttf
PASS OS/2 xAvgCharWidth value is correct.
Result: PASS
>> com.adobe.fonts/check/fsselection_matches_macstyle
Check if OS/2 fsSelection matches head macStyle bold and italic bits.
with KumbhSans[opsz,wght].ttf
Rationale:
The bold and italic bits in OS/2.fsSelection must match the bold and
italic bits in head.macStyle per the OpenType spec.
PASS The OS/2.fsSelection and head.macStyle bold and italic settings
match.
Result: PASS
>> com.google.fonts/check/code_pages
Check code page character ranges
with KumbhSans[opsz,wght].ttf
Rationale:
At least some programs (such as Word and Sublime Text) under Windows 7 do
not recognize fonts unless code page bits are properly set on the
ulCodePageRange1 (and/or ulCodePageRange2) fields of the OS/2 table.
More specifically, the fonts are selectable in the font menu, but
whichever Windows API these applications use considers them unsuitable for
any character set, so anything set in these fonts is rendered with a
fallback font of Arial.
This check currently does not identify which code pages should be set.
Auto-detecting coverage is not trivial since the OpenType specification
leaves the interpretation of whether a given code page is "functional" or
not open to the font developer to decide.
So here we simply detect as a FAIL when a given font has no code page
declared at all.
PASS At least one code page is defined.
Result: PASS
>> com.google.fonts/check/family/underline_thickness
Fonts have consistent underline thickness?
Rationale:
Dave C Lemon (Adobe Type Team) recommends setting the underline thickness
to be consistent across the family.
If thicknesses are not family consistent, words set on the same line which
have different styles look strange.
See also:
https://twitter.com/typenerd1/status/690361887926697986
PASS Fonts have consistent underline thickness.
Result: PASS
>> com.google.fonts/check/post_table_version
Font has correct post table version?
with KumbhSans[opsz,wght].ttf
Rationale:
Apple recommends against using 'post' table format 3 under most
circumstances, as it can create problems with some printer drivers and PDF
documents. The savings in disk space usually does not justify the
potential loss in functionality.
Source:
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06
/Chap6post.html
The CFF2 table does not contain glyph names, so variable OTFs should be
allowed to use post table version 2.
This check expects:
- Version 2 for TTF or OTF CFF2 Variable fonts
- Version 3 for OTF
PASS Font has post table version 2.
Result: PASS
>> com.adobe.fonts/check/family/max_4_fonts_per_family_name
Verify that each group of fonts with the same nameID 1 has maximum of 4 fonts
Rationale:
Per the OpenType spec:
'The Font Family name [...] should be shared among at most four fonts that
differ only in weight or style [...]'
PASS There were no more than 4 fonts per family name.
Result: PASS
>> com.adobe.fonts/check/name/empty_records
Check name table for empty records.
with KumbhSans[opsz,wght].ttf
Rationale:
Check the name table for empty records, as this can cause problems in
Adobe apps.
PASS No empty name table records found.
Result: PASS
>> com.google.fonts/check/name/no_copyright_on_description
Description strings in the name table must not contain copyright info.
with KumbhSans[opsz,wght].ttf
PASS Description strings in the name table do not contain any
copyright string.
Result: PASS
>> com.google.fonts/check/monospace
Checking correctness of monospaced metadata.
with KumbhSans[opsz,wght].ttf
Rationale:
There are various metadata in the OpenType spec to specify if a font is
monospaced or not. If the font is not truly monospaced, then no monospaced
metadata should be set (as sometimes they mistakenly are...)
Requirements for monospace fonts:
* post.isFixedPitch - "Set to 0 if the font is proportionally spaced,
non-zero if the font is not proportionally spaced (monospaced)"
www.microsoft.com/typography/otspec/post.htm
* hhea.advanceWidthMax must be correct, meaning no glyph's width value is
greater.
www.microsoft.com/typography/otspec/hhea.htm
* OS/2.panose.bProportion must be set to 9 (monospace). Spec says: "The
PANOSE definition contains ten digits each of which currently describes up
to sixteen variations. Windows uses bFamilyType, bSerifStyle and
bProportion in the font mapper to determine family type. It also uses
bProportion to determine if the font is monospaced."
www.microsoft.com/typography/otspec/os2.htm#pan
monotypecom-test.monotype.de/services/pan2
* OS/2.xAvgCharWidth must be set accurately.
"OS/2.xAvgCharWidth is used when rendering monospaced fonts, at least by
Windows GDI"
http://typedrawers.com/discussion/comment/15397/#Comment_15397
Also we should report an error for glyphs not of average width.
Please also note:
Thomas Phinney told us that a few years ago (as of December 2019), if you
gave a font a monospace flag in Panose, Microsoft Word would ignore the
actual advance widths and treat it as monospaced. Source:
https://typedrawers.com/discussion/comment/45140/#Comment_45140
PASS Font is not monospaced and all related metadata look good. [code:
good]
Result: PASS
>> com.google.fonts/check/name/match_familyname_fullfont
Does full font name begin with the font family name?
with KumbhSans[opsz,wght].ttf
PASS Full font name begins with the font family name.
Result: PASS
>> com.google.fonts/check/family_naming_recommendations
Font follows the family naming recommendations?
with KumbhSans[opsz,wght].ttf
PASS Font follows the family naming recommendations.
Result: PASS
>> com.adobe.fonts/check/name/postscript_vs_cff
CFF table FontName must match name table ID 6 (PostScript name).
with KumbhSans[opsz,wght].ttf
Rationale:
The PostScript name entries in the font's 'name' table should match the
FontName string in the 'CFF ' table.
The 'CFF ' table has a lot of information that is duplicated in other
tables. This information should be consistent across tables, because
there's no guarantee which table an app will get the data from.
SKIP Unfulfilled Conditions: is_cff
Result: SKIP
>> com.adobe.fonts/check/name/postscript_name_consistency
Name table ID 6 (PostScript name) must be consistent across platforms.
with KumbhSans[opsz,wght].ttf
Rationale:
The PostScript name entries in the font's 'name' table should be
consistent across platforms.
This is the TTF/CFF2 equivalent of the CFF 'postscript_name_cff_vs_name'
check.
PASS Entries in the "name" table for ID 6 (PostScript name) are
consistent.
Result: PASS
>> com.google.fonts/check/loca/maxp_num_glyphs
Does the number of glyphs in the loca table match the maxp table?
with KumbhSans[opsz,wght].ttf
PASS 'loca' table matches numGlyphs in 'maxp' table.
Result: PASS
>> com.google.fonts/check/linegaps
Checking Vertical Metric Linegaps.
with KumbhSans[opsz,wght].ttf
PASS OS/2 sTypoLineGap and hhea lineGap are both 0.
Result: PASS
>> com.google.fonts/check/maxadvancewidth
MaxAdvanceWidth is consistent with values in the Hmtx and Hhea tables?
with KumbhSans[opsz,wght].ttf
PASS MaxAdvanceWidth is consistent with values in the Hmtx and Hhea
tables.
Result: PASS
>> com.google.fonts/check/dsig
Does the font have a DSIG table?
with KumbhSans[opsz,wght].ttf
Rationale:
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.
This checks verifies that this signature is available in the font.
A fake signature is enough to address this issue. If needed, a dummy table
can be added to the font with the `gftools fix-dsig` script available at
https://github.com/googlefonts/gftools
Reference: https://github.com/googlefonts/fontbakery/issues/1845
PASS Digital Signature (DSIG) exists.
Result: PASS
>> com.google.fonts/check/whitespace_widths
Space and non-breaking space have the same width?
with KumbhSans[opsz,wght].ttf
PASS Space and non-breaking space have the same width.
Result: PASS
>> com.google.fonts/check/gdef_spacing_marks
Check mark characters are in GDEF mark glyph class)
with KumbhSans[opsz,wght].ttf
Rationale:
Glyphs in the GDEF mark glyph class should be non-spacing.
Spacing glyphs in the GDEF mark glyph class may have incorrect anchor
positioning that was only intended for building composite glyphs during
design.
SKIP Font does not declare an optional "GDEF" table or has any GDEF
glyph class definition.
Result: SKIP
>> com.google.fonts/check/gdef_mark_chars
Check mark characters are in GDEF mark glyph class
with KumbhSans[opsz,wght].ttf
Rationale:
Mark characters should be in the GDEF mark glyph class.
SKIP Font does not declare an optional "GDEF" table or has any GDEF
glyph class definition.
Result: SKIP
>> com.google.fonts/check/gdef_non_mark_chars
Check GDEF mark glyph class doesn't have characters that are not marks)
with KumbhSans[opsz,wght].ttf
Rationale:
Glyphs in the GDEF mark glyph class become non-spacing and may be
repositioned if they have mark anchors.
Only combining mark glyphs should be in that class. Any non-mark glyph
must not be in that class, in particular spacing glyphs.
SKIP Font does not declare an optional "GDEF" table or has any GDEF
glyph class definition.
Result: SKIP
>> com.google.fonts/check/gpos_kerning_info
Does GPOS table have kerning information? This check skips monospaced fonts as defined by post.isFixedPitch value
with KumbhSans[opsz,wght].ttf
PASS GPOS table check for kerning information passed.
Result: PASS
>> com.google.fonts/check/kern_table
Is there a usable "kern" table declared in the font?
with KumbhSans[opsz,wght].ttf
Rationale:
Even though all fonts should have their kerning implemented in the GPOS
table, there may be kerning info at the kern table as well.
Some applications such as MS PowerPoint require kerning info on the kern
table. More specifically, they require a format 0 kern subtable from a
kern table version 0 with only glyphs defined in the cmap table, which is
the only one that Windows understands (and which is also the simplest and
more limited of all the kern subtables).
Google Fonts ingests fonts made for download and use on desktops, and does
all web font optimizations in the serving pipeline (using libre libraries
that anyone can replicate.)
Ideally, TTFs intended for desktop users (and thus the ones intended for
Google Fonts) should have both KERN and GPOS tables.
Given all of the above, we currently treat kerning on a v0 kern table as a
good-to-have (but optional) feature.
PASS Font does not declare an optional "kern" table.
Result: PASS
>> com.google.fonts/check/glyf_unused_data
Is there any unused data at the end of the glyf table?
with KumbhSans[opsz,wght].ttf
PASS There is no unused data at the end of the glyf table.
Result: PASS
>> com.google.fonts/check/points_out_of_bounds
Check for points out of bounds.
with KumbhSans[opsz,wght].ttf
PASS All glyph paths have coordinates within bounds!
Result: PASS
>> com.google.fonts/check/glyf_non_transformed_duplicate_components
Check glyphs do not have duplicate components which have the same x,y coordinates.
with KumbhSans[opsz,wght].ttf
Rationale:
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.
PASS Glyphs do not contain duplicate components which have the same
x,y coordinates.
Result: PASS
>> com.google.fonts/check/glyf_nested_components
Check glyphs do not have components which are themselves components.
with KumbhSans[opsz,wght].ttf
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
PASS Glyphs do not contain nested components.
Result: PASS
>> com.google.fonts/check/varfont/regular_wght_coord
The variable font 'wght' (Weight) axis coordinate must be 400 on the 'Regular' instance.
with KumbhSans[opsz,wght].ttf
Rationale:
According to the Open-Type spec's registered design-variation tag 'wght'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wght
If a variable font has a 'wght' (Weight) axis, then the coordinate of its
'Regular' instance is required to be 400.
PASS Regular:wght is 400.
Result: PASS
>> com.google.fonts/check/varfont/regular_wdth_coord
The variable font 'wdth' (Width) axis coordinate must be 100 on the 'Regular' instance.
with KumbhSans[opsz,wght].ttf
Rationale:
According to the Open-Type spec's registered design-variation tag 'wdth'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wdth
If a variable font has a 'wdth' (Width) axis, then the coordinate of its
'Regular' instance is required to be 100.
SKIP Unfulfilled Conditions: regular_wdth_coord
Result: SKIP
>> com.google.fonts/check/varfont/regular_slnt_coord
The variable font 'slnt' (Slant) axis coordinate must be zero on the 'Regular' instance.
with KumbhSans[opsz,wght].ttf
Rationale:
According to the Open-Type spec's registered design-variation tag 'slnt'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_slnt
If a variable font has a 'slnt' (Slant) axis, then the coordinate of its
'Regular' instance is required to be zero.
SKIP Unfulfilled Conditions: regular_slnt_coord
Result: SKIP
>> com.google.fonts/check/varfont/regular_ital_coord
The variable font 'ital' (Italic) axis coordinate must be zero on the 'Regular' instance.
with KumbhSans[opsz,wght].ttf
Rationale:
According to the Open-Type spec's registered design-variation tag 'ital'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_ital
If a variable font has a 'ital' (Italic) axis, then the coordinate of its
'Regular' instance is required to be zero.
SKIP Unfulfilled Conditions: regular_ital_coord
Result: SKIP
>> com.google.fonts/check/varfont/regular_opsz_coord
The variable font 'opsz' (Optical Size) axis coordinate should be between 9 and 13 on the 'Regular' instance.
with KumbhSans[opsz,wght].ttf
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.
PASS Regular:opsz coordinate ({regular_opsz_coord}) looks good.
Result: PASS
>> com.google.fonts/check/varfont/bold_wght_coord
The variable font 'wght' (Weight) axis coordinate must be 700 on the 'Bold' instance.
with KumbhSans[opsz,wght].ttf
Rationale:
The Open-Type spec's registered design-variation tag 'wght' available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wght
does not specify a required value for the 'Bold' instance of a variable
font.
But Dave Crossland suggested that we should enforce a required value of
700 in this case.
PASS Bold:wght is 700.
Result: PASS
>> com.google.fonts/check/varfont/wght_valid_range
The variable font 'wght' (Weight) axis coordinate must be within spec range of 1 to 1000 on all instances.
with KumbhSans[opsz,wght].ttf
Rationale:
According to the Open-Type spec's registered design-variation tag 'wght'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wght
On the 'wght' (Weight) axis, the valid coordinate range is 1-1000.
PASS OK
Result: PASS
>> com.google.fonts/check/varfont/wdth_valid_range
The variable font 'wdth' (Weight) axis coordinate must be within spec range of 1 to 1000 on all instances.
with KumbhSans[opsz,wght].ttf
Rationale:
According to the Open-Type spec's registered design-variation tag 'wdth'
available at
https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wdth
On the 'wdth' (Width) axis, the valid coordinate range is 1-1000
PASS OK
Result: PASS
>> com.google.fonts/check/varfont/slnt_range
The variable font 'slnt' (Slant) axis coordinate specifies positive values in its range?
with KumbhSans[opsz,wght].ttf
Rationale:
The OpenType spec says at
https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_slnt
that:
[...] the scale for the Slant axis is interpreted as the angle of slant in
counter-clockwise degrees from upright. This means that a typical,
right-leaning oblique design will have a negative slant value. This
matches the scale used for the italicAngle field in the post table.
SKIP Unfulfilled Conditions: slnt_axis
Result: SKIP
>> com.google.fonts/check/varfont/stat_axis_record_for_each_axis
All fvar axes have a correspondent Axis Record on STAT table?
with KumbhSans[opsz,wght].ttf
Rationale:
cording to the OpenType spec, there must be an Axis Record for every axis
defined in the fvar table.
tps://docs.microsoft.com/en-us/typography/opentype/spec/stat#axis-records
PASS STAT table has all necessary Axis Records
Result: PASS
>> com.google.fonts/check/outline_alignment_miss
Are there any misaligned on-curve points?
with KumbhSans[opsz,wght].ttf
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.
PASS Y-coordinates of points fell on appropriate boundaries.
Result: PASS
>> com.google.fonts/check/outline_short_segments
Are any segments inordinately short?
with KumbhSans[opsz,wght].ttf
Rationale:
This check looks for outline segments which seem particularly short (less
than 0.006%% of the overall path length).
This check is not run for variable fonts, as they may legitimately have
short segments. As this check is liable to generate significant numbers of
false positives, it will pass if there are more than 100 reported short
segments.
SKIP Unfulfilled Conditions: is_not_variable_font
Result: SKIP
>> com.google.fonts/check/outline_colinear_vectors
Do any segments have colinear vectors?
with KumbhSans[opsz,wght].ttf
Rationale:
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.
SKIP Unfulfilled Conditions: is_not_variable_font
Result: SKIP
>> com.google.fonts/check/outline_jaggy_segments
Do outlines contain any jaggy segments?
with KumbhSans[opsz,wght].ttf
Rationale:
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.
SKIP Unfulfilled Conditions: is_not_variable_font
Result: SKIP
>> com.google.fonts/check/outline_semi_vertical
Do outlines contain any semi-vertical or semi-horizontal lines?
with KumbhSans[opsz,wght].ttf
Rationale:
This check detects line segments which are nearly, but not quite, exactly
horizontal or vertical. Sometimes such lines are created by design, but
often they are indicative of a design error.
This check is disabled for italic styles, which often contain
nearly-upright lines.
SKIP Unfulfilled Conditions: is_not_variable_font
Result: SKIP
>> com.google.fonts/check/shaping/regression
Check that texts shape as per expectation
with KumbhSans[opsz,wght].ttf
Rationale:
Fonts with complex layout rules can benefit from regression tests to
ensure that the rules are behaving as designed. This checks runs a shaping
test suite and compares expected shaping against actual shaping, reporting
any differences.
Shaping test suites should be written by the font engineer and referenced
in the fontbakery configuration file. For more information about write
shaping test files and how to configure fontbakery to read the shaping
test suites, see https://simoncozens.github.io/tdd-for-otl/
SKIP Shaping test directory not defined in configuration file
Result: SKIP
>> com.google.fonts/check/shaping/forbidden
Check that no forbidden glyphs are found while shaping
with KumbhSans[opsz,wght].ttf
Rationale:
Fonts with complex layout rules can benefit from regression tests to
ensure that the rules are behaving as designed. This checks runs a shaping
test suite and reports if any glyphs are generated in the shaping which
should not be produced. (For example, .notdef glyphs, visible viramas,
etc.)
Shaping test suites should be written by the font engineer and referenced
in the fontbakery configuration file. For more information about write
shaping test files and how to configure fontbakery to read the shaping
test suites, see https://simoncozens.github.io/tdd-for-otl/
SKIP Shaping test directory not defined in configuration file
Result: SKIP
>> com.google.fonts/check/shaping/collides
Check that no collisions are found while shaping
with KumbhSans[opsz,wght].ttf
Rationale:
Fonts with complex layout rules can benefit from regression tests to
ensure that the rules are behaving as designed. This checks runs a shaping
test suite and reports instances where the glyphs collide in unexpected
ways.
Shaping test suites should be written by the font engineer and referenced
in the fontbakery configuration file. For more information about write
shaping test files and how to configure fontbakery to read the shaping
test suites, see https://simoncozens.github.io/tdd-for-otl/
SKIP Shaping test directory not defined in configuration file
Result: SKIP
Total:
ERROR: 1
FAIL: 3
WARN: 1
INFO: 7
SKIP: 100
PASS: 92
DONE!
Meaning of check results:
An ERROR is something wrong with FontBakery itself, possibly a bug.
A FAIL is a problem with the font that must be fixed.
A WARN is something that you should consider addressing.
An INFO result simply prints something useful. Typically stats.
A PASS means the font looks good for the given checking routine.
And a SKIP happens when the check does not apply to the given font.
If you get ERRORs, please help us improve the tool by reporting them at
https://github.com/googlefonts/fontbakery/issues
(but other kinds of bug reports and/or
feature requests are also always welcome, of course!)
About the 3 FAILs:
FAIL Kumbh Sans Regular: OS/2 sTypoAscender is 2045 when it should be
1540 [code: bad-typo-ascender]
FAIL Kumbh Sans Regular: hhea Ascender is 2045 when it should be 1540
[code: bad-hhea-ascender]
The initial version had improper vertical metrics, and it was intended to fix this in next update. I have corrected vertical metrics now. The hhea Ascender and OS/2 sTypoAscender is increased so that the font sits more vertically centered. If this change can not be allowed, I will revert back to 1540.
FAIL STAT table is missing Axis Value Records [code:
missing-axis-values]
I will need help on this one as I am unable to understand and fix this issue.
FAIL This variable font does not have an avar table. [code:
missing-avar]
Since the progression rates of axes is linear, this check can be ignored?
gftools-fix-dsig
gftools-fix-nonhinting (The hinting will give bad results on 100 weight variant). Non hinted works better.
Static Instances There are 9 static instances for weight axis ranging 100 to 900. These can be generated when VF is passed.
I would also like to know if the compiled static instances need to be checked against FontBakery individually?
Thank you for your time.
davelab6
commented
3 years ago I did a call with @xconsau and @dberlow today to discuss the 2nd axis.
For now I'd like to ask @xconsau to use the following axis definition; I'll follow up with a complete axis registry definition soon.
label: Contract (Geometric)
code: CTGO
default, min, max: 0,0..100Thanks very much @davelab6 and @dberlow for your time and insights. I will make these changes to the 2nd axis.
xconsau
commented
3 years ago label: Contract (Geometric) code: CTGO default, min, max: 0,0..100
@davelab6 Can you confirm if it is "Contract" or "Contrast". And the code was CTGO or CTGE?
dberlow
commented
3 years ago 100% confirm that it is “contrast”.
dberlow
commented
3 years ago It was great speaking with you and I’m sorry it sounded confused at times but I think we covered all the possibilities :-)
xconsau
commented
3 years ago @RosaWagner, @davelab6 The VF has been updated now with the new Contrast (Geometric) axis CTGO
Variable TTF here
Attached is the FontBakery Report with v 0.7.37
There are two FAILs now:
FAIL Kumbh Sans Regular: OS/2 sTypoAscender is 2020 when it should be
1540 [code: bad-typo-ascender]
FAIL Kumbh Sans Regular: hhea Ascender is 2020 when it should be 1540
[code: bad-hhea-ascender]
Already discussed and allowed here.
FAIL This variable font does not have an avar table. [code:
missing-avar]
Since the progression rates of axes is linear, it may be allowed?
xconsau
commented
3 years ago It was great speaking with you and I’m sorry it sounded confused at times but I think we covered all the possibilities :-)
Please do not be sorry David Sir [@dberlow ]. If any confusion arose, that might be because I didn't presented the background, use-case and overall objective properly. But the session was very informative and helpful. We have already proceeded in creation of the contrast axis as of now. :)
RosaWagner
commented
3 years ago @xconsau we do require a non-linear progression for the weight axis, cause it is most likely that a weight distribution among the instances looks better when not linear. But it also depends a lot on design, and in the case of this project, it also depends on regression. The font has been published with these values before, and it would be a safe choice to update it with these same progression. Now, the font is also "recent", so if you think the font would benefit from a different axis mapping, we can test and see if we can ship.
RosaWagner
commented
3 years ago Concerning the custom axis and the planning of publication around it. There are 3 possible situations, and I do think number 2 is the worst. @davelab6, what is your favourite answer?
xconsau
commented
3 years ago ... we do require a non-linear progression for the weight axis, cause it is most likely that a weight distribution among the instances looks better when not linear.
Though I have chosen the stem width of extreme masters by dividing it evenly across 9 weights, taking original 400 stem width as the base. The weight will almost distribute evenly. But as you said, non-linear would be better. (I will need some guidance on creating an avar table please).
RosaWagner
commented
3 years ago @xconsau I precise, I was speaking in "general", to explain why this check is existing (it is not an absolute truth). In general, when the weight is distributed mathematically even, it may not look optically even.
To change the axis mapping, it happens in the design space file if you work with UFO:
(edit: corrected the image with values in the usual order)
xconsau
commented
3 years ago @RosaWagner, Now I see what you mean here. :) But unfortunately, assigning true Design Coordinates also doesn't generate an avar table. I will describe it as below:
<axis default="400" tag="wght" maximum="900" minimum="100" name="weight"> <labelname xml:lang="en">Weight</labelname> <map output="100" input="100"/> <map output="200" input="200"/> <map output="300" input="300"/> <map output="400" input="400"/> <map output="500" input="500"/> <map output="600" input="600"/> <map output="700" input="700"/> <map output="800" input="800"/> <map output="900" input="900"/> </axis>
<axis default="400" tag="wght" minimum="100" name="weight" maximum="900"> <labelname xml:lang="en">Weight</labelname> <map output="44" input="100"/> <map output="88" input="200"/> <map output="132" input="300"/> <map output="176" input="400"/> <map output="220" input="500"/> <map output="264" input="600"/> <map output="308" input="700"/> <map output="352" input="800"/> <map output="396" input="900"/> </axis>
The sources and instances are also changed accordingly. For example:
<source filename="masters/KumbhSans-BlackDisplay.ufo" stylename="Black Display" familyname="Kumbh Sans" name="BlackDisplay">
<location>
<dimension xvalue="396" name="weight"/>
<dimension xvalue="100" name="contrast (geometric)"/>
</location>
</source>
INFO:fontTools.varLib:Generating avar INFO:fontTools.varLib:No need for avar
i.e. it still detects it as pure linear progression and will not generate an avar table.
FYI, before creating the masters and considering the regression, I used this equation:
If 'x' be the stem width of Regular(400) variant (which is already hosted), then new stems would be:
Thin(100) = x/4 Black(900) = x/4 * 9
Maybe because of this calculation, the progression remains pure linear, and will not change. Any thoughts? I have no clue here what else can be changed. :)
Thanks for your cooperation and support so far.
RosaWagner
commented
3 years ago It probably doesn't work because the values are reversed. In output you need 100/200/300 etc. and it input: 44/88/132 etc. Although if the calculation is still linear, then it won't create a avar table ;) the avar is only if you have a non-linear progression.
xconsau
commented
3 years ago It probably doesn't work because the values are reversed. In output you need 100/200/300 etc. and it input: 44/88/132 etc
The input/output values seems correct. Input is the 'User Range' and Output is the 'Design Range'. I further confirmed it with the example of Nunito font. Simon has explained it nicely here.
Coming to the avar table, I have generated it successfully now. What I did is slightly changed the design range value of one of the instances. The weight 800 was not hosted before, so I changed it's design coordinate from 352 to 350, thereby breaking the linear progression. This method might not be the correct way, but I managed to get the avar table generated. The variable TTF is updated now.
RosaWagner
commented
3 years ago The input/output values seems correct. Input is the 'User Range' and Output is the 'Design Range'. I further confirmed it with the example of Nunito font. Simon has explained it nicely here.
Yes you are right, I got it wrong in your designspace, cause the input values are usually on the left, and output on the right.
Coming to the avar table, I have generated it successfully now. What I did is slightly changed the design range value of one of the instances. The weight 800 was not hosted before, so I changed it's design coordinate from 352 to 350, thereby breaking the linear progression. This method might not be the correct way, but I managed to get the avar table generated. The variable TTF is updated now.
The thing is, it is useless to generate an avar just to have an avar. This check is there to encourage designer to not have a linear progression. If you want to have a linear progression, then you don't need to bother to have an avar table…
xconsau
commented
3 years ago Yes you are right, I got it wrong in your designspace, cause the input values are usually on the left, and output on the right.
I guessed that, as in all other examples the 'input' attribute comes first.
The thing is, it is useless to generate an avar just to have an avar. This check is there to encourage designer to not have a linear progression. If you want to have a linear progression, then you don't need to bother to have an avar table…
I agree, there is no point in generating it just for the sake of passing FB test. Since I have already created stem widths in masters with linear calculation, we will have to ignore the avar now.
xconsau
commented
3 years ago @RosaWagner The variable ttf and sources now reverted back to the linear one (without an avar).
davelab6
commented
3 years ago Concerning the custom axis and the planning of publication around it. There are 3 possible situations, and I do think number 2 is the worst. @davelab6, what is your favourite answer?
- You are confident the axis will be registered with this exact definition -> SO we can ship the font with 2 axes and complete STAT table, before the axis get registered.
- Same -> BUT we can't ship the font before this axis gets registered and so it will be pending until it happens.
- Let's first ship the font update with only a weight axis (like…now), wait for the custom one to be registered, and then send another update with the custom axis.
(3) is best for me I think.
xconsau
commented
3 years ago @RosaWagner Can you mention what changes are required in the VF now to only include weight axis. Is it just removing the Contrast axis entry from the STAT table, or removing the axis from the sources and then compiling a new VF?
RosaWagner
commented
3 years ago It would probably spare some file size to remove it everywhere. But would be preferable to do that during export to not duplicate sources: varlib instancer can be useful for that in your build script (https://fonttools.readthedocs.io/en/latest/_modules/fontTools/varLib/instancer.html)
xconsau
commented
3 years ago Thank you, that was helpful. The VF is updated now. See KumbhSans[wght].ttf
I have dropped the CTGO axis using instancer. (Not sure if that was the correct way). Also let me know if I need to upload static instances for all weights 100 to 900. I suppose that will be achieved using Mutator from this partial VF?
RosaWagner
commented
3 years ago Awesome, thanks! The API will generate the statics. I don't see the build script mentioned in your README.md to replicate your building process. Can you re-add it for the future users?
xconsau
commented
3 years ago Actually I am not using any build script. All steps are manually performed one-by-one. I was not able to establish a shell script environment properly in Windows. So I do this in a virtual environment in command prompt of Windows. This involves renaming files, copying them from one folder to another, and so on. So an automated script won't work. I can document the steps though.
Upstream Repo: https://github.com/xconsau/KumbhSans
Edit: More changes. v1.001: Fixed vertical metrices v1.002: Added/adjusted kerning pairs for the Light variant
Thank you for your time and review.