Font Bakery is a command-line tool for checking the quality of font projects.
Current output
>> com.google.fonts/check/required_tables
Font contains all required tables?
with Kitab-Regular.ttf
Rationale:
According to the OpenType spec
https://docs.microsoft.com/en-us/typography/opentype/spec
/otff#required-tables
Whether TrueType or CFF outlines are used in an OpenType font, the
following tables are required for the font to function correctly:
- cmap (Character to glyph mapping)
- head (Font header)
- hhea (Horizontal header)
- hmtx (Horizontal metrics)
- maxp (Maximum profile)
- name (Naming table)
- OS/2 (OS/2 and Windows specific metrics)
- post (PostScript information)
The spec also documents that variable fonts require the following table:
- STAT (Style attributes)
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. Etc.
INFO This font contains the following optional tables:
- loca
- GPOS
- GSUB
- And gasp
[code: optional-tables]
Result: INFO
>> com.google.fonts/check/unwanted_tables
Are there unwanted tables?
with Kitab-Regular.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.
FAIL The following unwanted font tables were found:
• FFTM - Table contains redundant FontForge timestamp info
They can be removed with the fix-unwanted-tables script provided by
gftools. [code: unwanted-tables]
Result: FAIL
>> com.google.fonts/check/superfamily/list
List all superfamily filepaths
with Kitab-Regular.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/unreachable_glyphs
Check font contains no unreachable glyphs
with Kitab-Regular.ttf
Rationale:
Glyphs are either accessible directly through Unicode codepoints or
through substitution rules.
In Color Fonts, glyphs are also referenced by the COLR table.
Any glyphs not accessible by either of these means are redundant and
serve only to increase the font's file size.
WARN The following glyphs could not be reached by
codepoint or substitution rules:
- _bar.2
- _dot3u_tah
- _hamzaDamma
- _hamzaDamma.filled
- _highHamza
- _wavyHamza.b
- absAutoKashida
- nonmarkingreturn
- period.test
- tab
- And 4 more.
Use -F or --full-lists to disable shortening of long lists.
[code: unreachable-glyphs]
Result: WARN
>> com.google.fonts/check/contour_count
Check if each glyph has the recommended amount of contours.
with Kitab-Regular.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.
WARN This font has a 'Soft Hyphen' character (codepoint
0x00AD) which is supposed to be zero-width and invisible, and is used
to mark a hyphenation possibility within a word in the absence of or
overriding dictionary hyphenation. It is mostly an obsolete mechanism
now, and the character is only included in fonts for legacy codepage
coverage. [code: softhyphen]
WARN This check inspects the glyph outlines and detects
the total number of contours in each of them. The expected values are
infered from the typical ammounts of contours observed in a large
collection of reference font families. The divergences listed below
may simply indicate a significantly different design on some of your
glyphs. On the other hand, some of these may flag actual bugs in the
font such as glyphs mapped to an incorrect codepoint. Please consider
reviewing the design and codepoint assignment of these to make sure
they are correct.
The following glyphs do not have the recommended number of contours:
- Glyph name: percent Contours detected: 4 Expected: 5
- Glyph name: asterisk Contours detected: 8 Expected: 1 or 4
- Glyph name: sfthyphen Contours detected: 1 Expected: 0
- Glyph name: asterisk Contours detected: 8 Expected: 1 or 4
- And Glyph name: percent Contours detected: 4 Expected: 5
[code: contour-count]
Result: WARN
>> com.google.fonts/check/xavgcharwidth
Check if OS/2 xAvgCharWidth is correct.
with Kitab-Regular.ttf
WARN OS/2 xAvgCharWidth is 1230 but it should be 1107
which corresponds to the average of the widths of all glyphs in the
font. [code: xAvgCharWidth-wrong]
Result: WARN
>> 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 Kitab-Regular.ttf
WARN GPOS table lacks kerning information. [code:
lacks-kern-info]
Result: WARN
>> com.google.fonts/check/outline_colinear_vectors
Do any segments have colinear vectors?
with Kitab-Regular.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.
WARN The following glyphs have colinear vectors:
* uni060B (U+060B): L<<413.0,-182.0>--<413.0,-240.0>> ->
L<<413.0,-240.0>--<434.0,-490.0>>
* uni061C (U+061C): L<<367.0,797.0>--<508.0,406.0>> ->
L<<508.0,406.0>--<510.0,400.0>>
* uni06AA (U+06AA): L<<32.0,181.0>--<303.0,162.0>> ->
L<<303.0,162.0>--<1590.0,162.0>>
* uniE100 (U+E100): L<<1473.0,867.0>--<1469.0,857.0>> ->
L<<1469.0,857.0>--<1461.0,837.0>>
* uniE100 (U+E100): L<<898.0,840.0>--<926.0,566.0>> ->
L<<926.0,566.0>--<948.0,313.0>>
* uniE101 (U+E101): L<<754.0,787.0>--<754.0,796.0>> ->
L<<754.0,796.0>--<754.0,797.0>>
* uniE103 (U+E103): L<<2059.0,359.0>--<2060.0,358.0>> ->
L<<2060.0,358.0>--<2168.0,252.0>>
* uniFD4A (U+FD4A): L<<247.0,308.0>--<224.0,268.0>> ->
L<<224.0,268.0>--<189.0,191.0>>
* uniFD4E (U+FD4E): L<<1451.0,1205.0>--<1477.0,1244.0>> ->
L<<1477.0,1244.0>--<1498.0,1272.0>>
* uniFD4E (U+FD4E): L<<1639.0,-373.0>--<1665.0,-336.0>> ->
L<<1665.0,-336.0>--<1685.0,-304.0>>
* And 3 more.
Use -F or --full-lists to disable shortening of long lists. [code:
found-colinear-vectors]
Result: WARN
>> com.google.fonts/check/outline_jaggy_segments
Do outlines contain any jaggy segments?
with Kitab-Regular.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.
WARN The following glyphs have jaggy segments:
* uniE102 (U+E102):
B<<981.0,533.5>-<974.0,562.0>-<974.0,564.0>>/B<<974.0,564.0>-<957.0,
5.0>-<928.5,453.0>> = 13.840695491655588
* uniFD41 (U+FD41):
L<<623.0,1047.0>--<636.0,1045.0>>/B<<636.0,1045.0>-<635.0,1045.0>-<6
.0,1005.0>> = 8.746162262555211
* uniFD42 (U+FD42):
L<<523.0,997.0>--<536.0,995.0>>/B<<536.0,995.0>-<535.0,995.0>-<530.0
55.0>> = 8.746162262555211
* uniFD43 (U+FD43):
L<<1103.0,1017.0>--<1116.0,1015.0>>/B<<1116.0,1015.0>-<1115.0,1015.0
<1110.0,975.0>> = 8.746162262555211
* uniFD44 (U+FD44):
L<<643.0,1017.0>--<656.0,1015.0>>/B<<656.0,1015.0>-<655.0,1015.0>-<6
.0,975.0>> = 8.746162262555211
* uniFD45 (U+FD45):
L<<883.0,1037.0>--<896.0,1035.0>>/B<<896.0,1035.0>-<895.0,1035.0>-<8
.0,995.0>> = 8.746162262555211
* uniFD4A (U+FD4A):
B<<735.0,562.0>-<713.0,617.0>-<713.0,714.0>>/B<<713.0,714.0>-<704.0,
3.0>-<674.0,605.0>> = 8.392925187392485
* And uniFD4C (U+FD4C):
B<<294.0,941.0>-<319.0,956.0>-<320.0,967.0>>/B<<320.0,967.0>-<320.0,
0.0>-<314.0,1003.0>> = 5.1944289077348
[code: found-jaggy-segments]
Result: WARN
>> com.google.fonts/check/outline_semi_vertical
Do outlines contain any semi-vertical or semi-horizontal lines?
with Kitab-Regular.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.
WARN The following glyphs have
semi-vertical/semi-horizontal lines:
* uni06E9 (U+06E9): L<<1067.0,0.0>--<131.0,1.0>>
* uni06E9 (U+06E9): L<<249.0,32.0>--<947.0,31.0>>
* And uni06E9 (U+06E9): L<<429.0,112.0>--<769.0,111.0>>
[code: found-semi-vertical]
Result: WARN
Total:
ERROR: 0
FAIL: 1
WARN: 7
INFO: 2
SKIP: 29
PASS: 54
[PPPPPPPPPPPIFSPPPISSWWSPPPSPPSSSPPPPPPPPWPPPPPPPPPPSPPPPPPPPWPPPPSSSSSSSSSSSSSSSSSPPPPPWWWSSS] 100%
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!)
Current output
>> com.google.fonts/check/required_tables Font contains all required tables? with Kitab-Regular.ttf Rationale: According to the OpenType spec https://docs.microsoft.com/en-us/typography/opentype/spec /otff#required-tables Whether TrueType or CFF outlines are used in an OpenType font, the following tables are required for the font to function correctly: - cmap (Character to glyph mapping) - head (Font header) - hhea (Horizontal header) - hmtx (Horizontal metrics) - maxp (Maximum profile) - name (Naming table) - OS/2 (OS/2 and Windows specific metrics) - post (PostScript information) The spec also documents that variable fonts require the following table: - STAT (Style attributes) 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. Etc. INFO This font contains the following optional tables: - loca - GPOS - GSUB - And gasp [code: optional-tables] Result: INFO >> com.google.fonts/check/unwanted_tables Are there unwanted tables? with Kitab-Regular.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. FAIL The following unwanted font tables were found: • FFTM - Table contains redundant FontForge timestamp info They can be removed with the fix-unwanted-tables script provided by gftools. [code: unwanted-tables] Result: FAIL >> com.google.fonts/check/superfamily/list List all superfamily filepaths with Kitab-Regular.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/unreachable_glyphs Check font contains no unreachable glyphs with Kitab-Regular.ttf Rationale: Glyphs are either accessible directly through Unicode codepoints or through substitution rules. In Color Fonts, glyphs are also referenced by the COLR table. Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size. WARN The following glyphs could not be reached by codepoint or substitution rules: - _bar.2 - _dot3u_tah - _hamzaDamma - _hamzaDamma.filled - _highHamza - _wavyHamza.b - absAutoKashida - nonmarkingreturn - period.test - tab - And 4 more. Use -F or --full-lists to disable shortening of long lists. [code: unreachable-glyphs] Result: WARN >> com.google.fonts/check/contour_count Check if each glyph has the recommended amount of contours. with Kitab-Regular.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. WARN This font has a 'Soft Hyphen' character (codepoint 0x00AD) which is supposed to be zero-width and invisible, and is used to mark a hyphenation possibility within a word in the absence of or overriding dictionary hyphenation. It is mostly an obsolete mechanism now, and the character is only included in fonts for legacy codepage coverage. [code: softhyphen] WARN This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: - Glyph name: percent Contours detected: 4 Expected: 5 - Glyph name: asterisk Contours detected: 8 Expected: 1 or 4 - Glyph name: sfthyphen Contours detected: 1 Expected: 0 - Glyph name: asterisk Contours detected: 8 Expected: 1 or 4 - And Glyph name: percent Contours detected: 4 Expected: 5 [code: contour-count] Result: WARN >> com.google.fonts/check/xavgcharwidth Check if OS/2 xAvgCharWidth is correct. with Kitab-Regular.ttf WARN OS/2 xAvgCharWidth is 1230 but it should be 1107 which corresponds to the average of the widths of all glyphs in the font. [code: xAvgCharWidth-wrong] Result: WARN >> 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 Kitab-Regular.ttf WARN GPOS table lacks kerning information. [code: lacks-kern-info] Result: WARN >> com.google.fonts/check/outline_colinear_vectors Do any segments have colinear vectors? with Kitab-Regular.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. WARN The following glyphs have colinear vectors: * uni060B (U+060B): L<<413.0,-182.0>--<413.0,-240.0>> -> L<<413.0,-240.0>--<434.0,-490.0>> * uni061C (U+061C): L<<367.0,797.0>--<508.0,406.0>> -> L<<508.0,406.0>--<510.0,400.0>> * uni06AA (U+06AA): L<<32.0,181.0>--<303.0,162.0>> -> L<<303.0,162.0>--<1590.0,162.0>> * uniE100 (U+E100): L<<1473.0,867.0>--<1469.0,857.0>> -> L<<1469.0,857.0>--<1461.0,837.0>> * uniE100 (U+E100): L<<898.0,840.0>--<926.0,566.0>> -> L<<926.0,566.0>--<948.0,313.0>> * uniE101 (U+E101): L<<754.0,787.0>--<754.0,796.0>> -> L<<754.0,796.0>--<754.0,797.0>> * uniE103 (U+E103): L<<2059.0,359.0>--<2060.0,358.0>> -> L<<2060.0,358.0>--<2168.0,252.0>> * uniFD4A (U+FD4A): L<<247.0,308.0>--<224.0,268.0>> -> L<<224.0,268.0>--<189.0,191.0>> * uniFD4E (U+FD4E): L<<1451.0,1205.0>--<1477.0,1244.0>> -> L<<1477.0,1244.0>--<1498.0,1272.0>> * uniFD4E (U+FD4E): L<<1639.0,-373.0>--<1665.0,-336.0>> -> L<<1665.0,-336.0>--<1685.0,-304.0>> * And 3 more. Use -F or --full-lists to disable shortening of long lists. [code: found-colinear-vectors] Result: WARN >> com.google.fonts/check/outline_jaggy_segments Do outlines contain any jaggy segments? with Kitab-Regular.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. WARN The following glyphs have jaggy segments: * uniE102 (U+E102): B<<981.0,533.5>-<974.0,562.0>-<974.0,564.0>>/B<<974.0,564.0>-<957.0, 5.0>-<928.5,453.0>> = 13.840695491655588 * uniFD41 (U+FD41): L<<623.0,1047.0>--<636.0,1045.0>>/B<<636.0,1045.0>-<635.0,1045.0>-<6 .0,1005.0>> = 8.746162262555211 * uniFD42 (U+FD42): L<<523.0,997.0>--<536.0,995.0>>/B<<536.0,995.0>-<535.0,995.0>-<530.0 55.0>> = 8.746162262555211 * uniFD43 (U+FD43): L<<1103.0,1017.0>--<1116.0,1015.0>>/B<<1116.0,1015.0>-<1115.0,1015.0 <1110.0,975.0>> = 8.746162262555211 * uniFD44 (U+FD44): L<<643.0,1017.0>--<656.0,1015.0>>/B<<656.0,1015.0>-<655.0,1015.0>-<6 .0,975.0>> = 8.746162262555211 * uniFD45 (U+FD45): L<<883.0,1037.0>--<896.0,1035.0>>/B<<896.0,1035.0>-<895.0,1035.0>-<8 .0,995.0>> = 8.746162262555211 * uniFD4A (U+FD4A): B<<735.0,562.0>-<713.0,617.0>-<713.0,714.0>>/B<<713.0,714.0>-<704.0, 3.0>-<674.0,605.0>> = 8.392925187392485 * And uniFD4C (U+FD4C): B<<294.0,941.0>-<319.0,956.0>-<320.0,967.0>>/B<<320.0,967.0>-<320.0, 0.0>-<314.0,1003.0>> = 5.1944289077348 [code: found-jaggy-segments] Result: WARN >> com.google.fonts/check/outline_semi_vertical Do outlines contain any semi-vertical or semi-horizontal lines? with Kitab-Regular.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. WARN The following glyphs have semi-vertical/semi-horizontal lines: * uni06E9 (U+06E9): L<<1067.0,0.0>--<131.0,1.0>> * uni06E9 (U+06E9): L<<249.0,32.0>--<947.0,31.0>> * And uni06E9 (U+06E9): L<<429.0,112.0>--<769.0,111.0>> [code: found-semi-vertical] Result: WARN Total: ERROR: 0 FAIL: 1 WARN: 7 INFO: 2 SKIP: 29 PASS: 54 [PPPPPPPPPPPIFSPPPISSWWSPPPSPPSSSPPPPPPPPWPPPPPPPPPPSPPPPPPPPWPPPPSSSSSSSSSSSSSSSSSPPPPPWWWSSS] 100% 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!)