Open redbrain opened 1 year ago
See prior discussion regarding Linux Libertine / Libertinus at https://github.com/google/fonts/issues/12, and more broadly about hosting Libertinus on a CDN at https://github.com/alerque/libertinus/issues/362.
Here is what Fontbakery find in Common Serif (check-universal test):
Microsoft Windows [Version 10.0.22621.1992] (c) Microsoft Corporation. All rights reserved.
d:\Fonts\A Context Original\Common Serif\OTF>fontbakery check-universal --full-lists commonserif-regular.otf Start ... running 108 individual check executions.
com.google.fonts/check/family/win_ascent_and_descent Checking OS/2 usWinAscent & usWinDescent. with commonserif-regular.otf
Rationale:
A font's winAscent and winDescent values should be greater than or equal
to the head table's yMax, abs(yMin) values. If they are less than these
values, clipping can occur on Windows platforms
(https://github.com/RedHatBrand/Overpass/issues/33).
If the font includes tall/deep writing systems such as Arabic or
Devanagari, the winAscent and winDescent can be greater than the yMax and
abs(yMin) to accommodate vowel marks.
When the win Metrics are significantly greater than the upm, the
linespacing can appear too loose. To counteract this, enabling the OS/2
fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2
typo values instead. This means the font developer can control the
linespacing with the typo values, whilst avoiding clipping by setting the
win values to values greater than the yMax and abs(yMin).
FAIL OS/2.usWinAscent value should be equal or greater
than 1047, but got 894 instead [code: ascent]
FAIL OS/2.usWinDescent value should be equal or greater
than 305, but got 246 instead. [code: descent]
Result: FAIL
com.google.fonts/check/required_tables Font contains all required tables? with commonserif-regular.otf
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:
- GPOS
- GSUB
[code: optional-tables]
Result: INFO
com.google.fonts/check/superfamily/list List all superfamily filepaths with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/1487
INFO . [code: family-path]
Result: INFO
com.google.fonts/check/unreachable_glyphs Check font contains no unreachable glyphs with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/3160
WARN The following glyphs could not be reached by
codepoint or substitution rules:
- caron.cap
- eight.oldstyle
- uni03020300
- uni03020301
- uni03020303
- uni03020309
- uni03030301
- uni03030304
- uni03030308
- uni03040300
- uni03040301
- uni03040308
- uni0305.100
- uni0305.1000
- uni0305.1050
- uni0305.1100
- uni0305.1150
- uni0305.1200
- uni0305.1250
- uni0305.1300
- uni0305.1350
- uni0305.1450
- uni0305.150
- uni0305.1600
- uni0305.200
- uni0305.250
- uni0305.300
- uni0305.350
- uni0305.400
- uni0305.450
- uni0305.50
- uni0305.500
- uni0305.550
- uni0305.600
- uni0305.650
- uni0305.700
- uni0305.750
- uni0305.800
- uni0305.850
- uni0305.900
- uni0305.950
- uni0306.cyr
- uni0306.cyrcap
- uni03060300
- uni03060301
- uni03060303
- uni03060309
- uni03070301
- uni03070304
- uni03080300
- uni03080301
- uni03080304
- uni0308030C
- uni030C0307
- uni0332.100
- uni0332.1000
- uni0332.1050
- uni0332.1100
- uni0332.1150
- uni0332.1200
- uni0332.1250
- uni0332.1300
- uni0332.1350
- uni0332.1450
- uni0332.150
- uni0332.1600
- uni0332.200
- uni0332.250
- uni0332.300
- uni0332.350
- uni0332.400
- uni0332.450
- uni0332.50
- uni0332.500
- uni0332.550
- uni0332.600
- uni0332.650
- uni0332.700
- uni0332.750
- uni0332.800
- uni0332.850
- uni0332.900
- uni0332.950
[code: unreachable-glyphs]
Result: WARN
com.google.fonts/check/soft_hyphen Does the font contain a soft hyphen? with commonserif-regular.otf
Rationale:
The 'Soft Hyphen' character (codepoint 0x00AD) is used to mark a
hyphenation possibility within a word in the absence of or overriding
dictionary hyphenation.
It is sometimes designed empty with no width (such as a control
character), sometimes the same as the traditional hyphen, sometimes
double encoded with the hyphen.
That being said, it is recommended to not include it in the font at all,
because discretionary hyphenation should be handled at the level of the
shaping engine, not the font. Also, even if present, the software would
not display that character.
More discussion at:
https://typedrawers.com/discussion/2046
/special-dash-things-softhyphen-horizontalbar
More info: https://github.com/googlefonts/fontbakery/issues/4046
https://github.com/googlefonts/fontbakery/issues/3486
WARN This font has a 'Soft Hyphen' character. [code:
softhyphen]
Result: WARN
com.google.fonts/check/soft_dotted Ensure soft_dotted characters lose their dot when combined with marks that replace the dot. with commonserif-regular.otf
Rationale:
An accent placed on characters with a "soft dot", like i or j, causes the
dot to disappear. An explicit dot above can be added where required. See
"Diacritics on i and j" in Section 7.1, "Latin" in The Unicode Standard.
Characters with the Soft_Dotted property are listed in
https://www.unicode.org/Public/UCD/latest/ucd/PropList.txt
See also:
https://googlefonts.github.io/gf-guide/diacritics.html#soft-dotted-glyphs
More info: https://github.com/googlefonts/fontbakery/issues/4059
FAIL The dot of soft dotted characters used in
orthographies must disappear in the following strings: į̀ į́ į̂ į̃ į̄
į̌ ɨ̧̀ ɨ̧́
ɨ̧̂ ɨ̧̌ ɨ̱̀ ɨ̱́ ɨ̱̈ і́ ḭ̀ ḭ́ ḭ̄ ị̀ ị́ ị̂ ị̃ ị̄
The dot of soft dotted characters should disappear in other cases, for
example: i̅ i̽ i̾ i̿ i͂ i͆ i͊ i͋ i͌ i͐ i͒ i͛ iͣ iͤ iͥ iͦ iͧ iͨ iͩ iͪ
[code: soft-dotted]
Result: FAIL
com.google.fonts/check/math_signs_width Check math signs have the same width. with commonserif-regular.otf
Rationale:
It is a common practice to have math signs sharing the same width
(preferably the same width as tabular figures accross the entire font
family).
This probably comes from the will to avoid additional tabular math signs
knowing that their design can easily share the same width.
More info: https://github.com/googlefonts/fontbakery/issues/3832
WARN The most common width is 527 among a set of 14 math
glyphs. The following math glyphs have a different width, though:
Width = 550: uni2213, minus, congruent, multiply, equal, divide,
uni2214, plusminus, greater, less, plus
Width = 599: logicalnot
Width = 506: element, suchthat, notelement
Width = 501: uni220C
Width = 670: proportional
Width = 541: orthogonal
Width = 666: uni2222, uni2221, angle
Width = 522: notsubset, propersuperset, uni2285, propersubset
Width = 663: uni22A3, uni22A2
Width = 629: uni22A4, uni22A5
[code: width-outliers]
Result: WARN
com.google.fonts/check/name/no_copyright_on_description Description strings in the name table must not contain copyright info. with commonserif-regular.otf
FAIL Some namerecords with ID=10 (NameID.DESCRIPTION)
containing copyright info should be removed (perhaps these were added
by a longstanding FontLab Studio 5.x bug that copied copyright notices
to them.) [code: copyright-on-description]
Result: FAIL
com.google.fonts/check/dsig Does the font have a DSIG table? with commonserif-regular.otf
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.
As we approach the EOL date, it is now considered better to completely
remove the table.
But if you still want your font to support OpenType features on Office
2013, then you may find it handy to add a fake signature on a placeholder
DSIG table by running one of the helper scripts provided at
https://github.com/googlefonts/gftools
Reference: https://github.com/googlefonts/fontbakery/issues/1845
More info: https://github.com/googlefonts/fontbakery/issues/3398
WARN This font has a digital signature (DSIG table) which
is only required - even if only a placeholder - on old programs like
MS Office 2013 in order to work properly. The current recommendation
is to completely remove the DSIG table. [code: found-DSIG]
Result: WARN
com.google.fonts/check/gdef_spacing_marks Check glyphs in mark glyph class are non-spacing. with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/2877
WARN The following spacing glyphs may be in the GDEF mark
glyph class by mistake: uni0484 (U+0484), uni0487 (U+0487), uni2DE0
(U+2DE0), uni2DE1 (U+2DE1), uni2DE2 (U+2DE2), uni2DE3 (U+2DE3),
uni2DE4 (U+2DE4), uni2DE5 (U+2DE5), uni2DE6 (U+2DE6), uni2DE7
(U+2DE7), uni2DE8 (U+2DE8), uni2DE9 (U+2DE9), uni2DEA (U+2DEA),
uni2DEB (U+2DEB), uni2DEC (U+2DEC), uni2DED (U+2DED), uni2DEE
(U+2DEE), uni2DEF (U+2DEF), uni2DF0 (U+2DF0), uni2DF1 (U+2DF1),
uni2DF2 (U+2DF2), uni2DF3 (U+2DF3), uni2DF4 (U+2DF4), uni2DF5
(U+2DF5), uni2DF6 (U+2DF6), uni2DF7 (U+2DF7), uni2DF8 (U+2DF8),
uni2DF9 (U+2DF9), uni2DFA (U+2DFA), uni2DFB (U+2DFB), uni2DFC
(U+2DFC), uni2DFD (U+2DFD), uni2DFE (U+2DFE), uni2DFF (U+2DFF),
uniA66F (U+A66F), uniA674 (U+A674), uniA675 (U+A675), uniA676
(U+A676), uniA677 (U+A677), uniA678 (U+A678), uniA679 (U+A679),
uniA67A (U+A67A), uniA67B (U+A67B), uniA67C (U+A67C), uniA67D
(U+A67D), uniA69E (U+A69E), uniA69F (U+A69F), uniFE2E (U+FE2E) and
uniFE2F (U+FE2F) [code: spacing-mark-glyphs]
Result: WARN
com.google.fonts/check/gdef_mark_chars Check mark characters are in GDEF mark glyph class. with commonserif-regular.otf
Rationale:
Mark characters should be in the GDEF mark glyph class.
More info: https://github.com/googlefonts/fontbakery/issues/2877
WARN The following mark characters could be in the GDEF
mark glyph class: uni0488 (U+0488), uni0489 (U+0489), uniA670
(U+A670), uniA671 (U+A671) and uniA672 (U+A672) [code: mark-chars]
Result: WARN
com.google.fonts/check/outline_colinear_vectors Do any segments have colinear vectors? with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/pull/3088
WARN The following glyphs have colinear vectors:
* chi (U+03C7): L<<100.0,-235.0>--<157.0,-126.0>> ->
L<<157.0,-126.0>--<240.0,57.0>>
* chi (U+03C7): L<<276.0,130.0>--<417.0,332.0>> ->
L<<417.0,332.0>--<490.0,439.0>>
* eta (U+03B7): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* eta (U+03B7): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* etatonos (U+03AE): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* etatonos (U+03AE): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* iota (U+03B9): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* iotadieresis (U+03CA): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* iotadieresistonos (U+0390): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* iotatonos (U+03AF): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* kappa (U+03BA): L<<178.0,247.0>--<176.0,311.0>> ->
L<<176.0,311.0>--<176.0,350.0>>
* kappa (U+03BA): L<<96.0,317.0>--<96.0,137.0>> ->
L<<96.0,137.0>--<86.0,-10.0>>
* trademark (U+2122): L<<657.0,541.0>--<674.0,344.0>> ->
L<<674.0,344.0>--<674.0,337.0>>
* trademark (U+2122): L<<735.0,344.0>--<712.0,610.0>> ->
L<<712.0,610.0>--<712.0,616.0>>
* uni0258 (U+0258): L<<56.0,246.0>--<78.0,246.0>> ->
L<<78.0,246.0>--<320.0,248.0>>
* uni0269 (U+0269): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* uni03BC (U+03BC): L<<140.0,-220.0>--<130.0,-36.0>> ->
L<<130.0,-36.0>--<125.0,5.0>>
* uni03BC (U+03BC): L<<50.0,422.0>--<54.0,105.0>> ->
L<<54.0,105.0>--<40.0,-228.0>>
* uni04B5 (U+04B5): L<<128.0,-1.0>--<221.0,0.0>> ->
L<<221.0,0.0>--<547.0,0.0>>
* uni04B5 (U+04B5): L<<579.0,429.0>--<565.0,429.0>> ->
L<<565.0,429.0>--<481.0,431.0>>
* uni04B6 (U+04B6): L<<152.0,645.0>--<137.0,645.0>> ->
L<<137.0,645.0>--<29.0,646.0>>
* uni04B7 (U+04B7): L<<129.0,428.0>--<119.0,428.0>> ->
L<<119.0,428.0>--<34.0,431.0>>
* uni04B7 (U+04B7): L<<383.0,429.0>--<373.0,429.0>> ->
L<<373.0,429.0>--<291.0,431.0>>
* uni04BD (U+04BD): L<<227.0,248.0>--<475.0,246.0>> ->
L<<475.0,246.0>--<493.0,246.0>>
* uni04BF (U+04BF): L<<227.0,248.0>--<463.0,246.0>> ->
L<<463.0,246.0>--<493.0,246.0>>
* uni04CB (U+04CB): L<<152.0,645.0>--<137.0,645.0>> ->
L<<137.0,645.0>--<29.0,646.0>>
* uni04CB (U+04CB): L<<489.0,644.0>--<475.0,644.0>> ->
L<<475.0,644.0>--<375.0,646.0>>
* uni04CC (U+04CC): L<<129.0,428.0>--<119.0,428.0>> ->
L<<119.0,428.0>--<34.0,431.0>>
* uni04CC (U+04CC): L<<383.0,429.0>--<373.0,429.0>> ->
L<<373.0,429.0>--<291.0,431.0>>
* uni1F20 (U+1F20): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* uni1F20 (U+1F20): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* uni1F21 (U+1F21): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* uni1F21 (U+1F21): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* uni1F22 (U+1F22): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* uni1F22 (U+1F22): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* uni1F23 (U+1F23): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* uni1F23 (U+1F23): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* uni1F24 (U+1F24): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* uni1F24 (U+1F24): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* uni1F25 (U+1F25): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* uni1F25 (U+1F25): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* uni1F26 (U+1F26): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* uni1F26 (U+1F26): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* uni1F27 (U+1F27): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* uni1F27 (U+1F27): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* uni1F30 (U+1F30): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* uni1F31 (U+1F31): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* uni1F32 (U+1F32): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* uni1F33 (U+1F33): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* uni1F34 (U+1F34): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* uni1F35 (U+1F35): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* uni1F36 (U+1F36): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* uni1F37 (U+1F37): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* uni2120 (U+2120): L<<695.0,344.0>--<672.0,610.0>> ->
L<<672.0,610.0>--<672.0,616.0>>
* uni261B (U+261B): L<<24.0,48.0>--<171.0,39.0>> ->
L<<171.0,39.0>--<176.0,39.0>>
* uni2645 (U+2645): L<<443.0,104.0>--<457.0,105.0>> ->
L<<457.0,105.0>--<471.0,105.0>>
* uni2695 (U+2695): L<<255.0,-149.0>--<255.0,-147.0>> ->
L<<255.0,-147.0>--<254.0,-103.0>>
* uni2C74 (U+2C74): L<<353.0,356.0>--<262.0,135.0>> ->
L<<262.0,135.0>--<244.0,85.0>>
* uniA657 (U+A657): L<<579.0,264.0>--<493.0,243.0>> ->
L<<493.0,243.0>--<472.0,237.0>>
[code: found-colinear-vectors]
Result: WARN
com.google.fonts/check/outline_jaggy_segments Do outlines contain any jaggy segments? with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/3064
WARN The following glyphs have jaggy segments:
* uni049B (U+049B):
B<<356.0,157.0>-<337.0,206.0>-<286.0,227.0>-<246.0,227.0>>/B<<246.0,
7.0>-<282.0,232.0>-<320.0,269.0>-<347.0,320.0>> = 7.907162702958418
* uni049D (U+049D):
B<<423.0,157.0>-<403.0,206.0>-<364.0,227.0>-<310.0,227.0>>/B<<310.0,
7.0>-<361.0,235.0>-<387.0,285.0>-<403.0,323.0>> = 8.914926957147863
* uni049F (U+049F):
B<<354.0,157.0>-<333.0,206.0>-<294.0,227.0>-<240.0,227.0>>/B<<240.0,
7.0>-<291.0,235.0>-<317.0,285.0>-<333.0,323.0>> = 8.914926957147863
* uni05DC (U+05DC):
B<<71.0,719.0>-<63.0,721.0>-<43.0,728.0>-<41.0,746.0>>/B<<41.0,746.0
<41.0,745.0>-<11.0,743.0>-<11.0,698.0>> = 6.340191745909908
* uni2695 (U+2695):
L<<396.0,405.0>--<390.0,408.0>>/L<<390.0,408.0>--<404.0,403.0>> =
6.911227119024662
[code: found-jaggy-segments]
Result: WARN
com.google.fonts/check/outline_semi_vertical Do outlines contain any semi-vertical or semi-horizontal lines? with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/pull/3088
WARN The following glyphs have
semi-vertical/semi-horizontal lines:
* e (U+0065): L<<121.0,248.0>--<387.0,246.0>>
* eacute (U+00E9): L<<121.0,248.0>--<387.0,246.0>>
* ebreve (U+0115): L<<121.0,248.0>--<387.0,246.0>>
* ecaron (U+011B): L<<121.0,248.0>--<387.0,246.0>>
* ecircumflex (U+00EA): L<<121.0,248.0>--<387.0,246.0>>
* edieresis (U+00EB): L<<121.0,248.0>--<387.0,246.0>>
* edotaccent (U+0117): L<<121.0,248.0>--<387.0,246.0>>
* egrave (U+00E8): L<<121.0,248.0>--<387.0,246.0>>
* emacron (U+0113): L<<121.0,248.0>--<387.0,246.0>>
* eogonek (U+0119): L<<121.0,248.0>--<387.0,246.0>>
* uni0195 (U+0195): L<<164.0,358.0>--<165.0,583.0>>
* uni01B6 (U+01B6): L<<262.0,34.0>--<129.0,33.0>>
* uni01C5 (U+01C5): L<<963.0,34.0>--<830.0,33.0>>
* uni01C6 (U+01C6): L<<768.0,34.0>--<635.0,33.0>>
* uni01DD (U+01DD): L<<307.0,181.0>--<41.0,183.0>>
* uni01F2 (U+01F2): L<<963.0,34.0>--<830.0,33.0>>
* uni01F3 (U+01F3): L<<768.0,34.0>--<635.0,33.0>>
* uni0205 (U+0205): L<<121.0,248.0>--<387.0,246.0>>
* uni0207 (U+0207): L<<121.0,248.0>--<387.0,246.0>>
* uni0229 (U+0229): L<<121.0,248.0>--<387.0,246.0>>
* uni0247 (U+0247): L<<268.0,247.0>--<387.0,246.0>>
* uni0258 (U+0258): L<<78.0,246.0>--<320.0,248.0>>
* uni0259 (U+0259): L<<307.0,181.0>--<41.0,183.0>>
* uni02A3 (U+02A3): L<<653.0,34.0>--<520.0,33.0>>
* uni02AB (U+02AB): L<<442.0,35.0>--<309.0,34.0>>
* uni0435 (U+0435): L<<121.0,248.0>--<387.0,246.0>>
* uni043C (U+043C): L<<494.0,375.0>--<493.0,122.0>>
* uni0450 (U+0450): L<<121.0,248.0>--<387.0,246.0>>
* uni0451 (U+0451): L<<121.0,248.0>--<387.0,246.0>>
* uni045B (U+045B): L<<186.0,358.0>--<187.0,501.0>>
* uni049F (U+049F): L<<178.0,244.0>--<179.0,478.0>>
* uni04AD (U+04AD): L<<28.0,442.0>--<27.0,305.0>>
* uni04B5 (U+04B5): L<<35.0,456.0>--<34.0,317.0>>
* uni04BD (U+04BD): L<<227.0,248.0>--<475.0,246.0>>
* uni04BF (U+04BF): L<<227.0,248.0>--<463.0,246.0>>
* uni04D7 (U+04D7): L<<121.0,248.0>--<387.0,246.0>>
* uni04D9 (U+04D9): L<<307.0,181.0>--<41.0,183.0>>
* uni04DB (U+04DB): L<<307.0,181.0>--<41.0,183.0>>
* uni1D49 (U+1D49): L<<205.0,537.0>--<85.0,536.0>>
* uni1D4A (U+1D4A): L<<76.0,459.0>--<196.0,460.0>>
* uni1E15 (U+1E15): L<<121.0,248.0>--<387.0,246.0>>
* uni1E17 (U+1E17): L<<121.0,248.0>--<387.0,246.0>>
* uni1E19 (U+1E19): L<<121.0,248.0>--<387.0,246.0>>
* uni1E1B (U+1E1B): L<<121.0,248.0>--<387.0,246.0>>
* uni1E1D (U+1E1D): L<<121.0,248.0>--<387.0,246.0>>
* uni1E91 (U+1E91): L<<262.0,34.0>--<129.0,33.0>>
* uni1E93 (U+1E93): L<<262.0,34.0>--<129.0,33.0>>
* uni1E95 (U+1E95): L<<262.0,34.0>--<129.0,33.0>>
* uni1EB9 (U+1EB9): L<<121.0,248.0>--<387.0,246.0>>
* uni1EBB (U+1EBB): L<<121.0,248.0>--<387.0,246.0>>
* uni1EBD (U+1EBD): L<<121.0,248.0>--<387.0,246.0>>
* uni1EBF (U+1EBF): L<<121.0,248.0>--<387.0,246.0>>
* uni1EC1 (U+1EC1): L<<121.0,248.0>--<387.0,246.0>>
* uni1EC3 (U+1EC3): L<<121.0,248.0>--<387.0,246.0>>
* uni1EC5 (U+1EC5): L<<121.0,248.0>--<387.0,246.0>>
* uni1EC7 (U+1EC7): L<<121.0,248.0>--<387.0,246.0>>
* uni2091 (U+2091): L<<212.0,61.0>--<92.0,60.0>>
* uni2094 (U+2094): L<<91.0,-17.0>--<211.0,-16.0>>
* uni210D (U+210D): L<<251.0,608.0>--<252.0,36.0>>
* uni24D4 (U+24D4): L<<437.0,341.0>--<317.0,340.0>>
* uni2669 (U+2669): L<<267.0,689.0>--<270.0,165.0>>
* uni2669 (U+2669): L<<305.0,121.0>--<307.0,698.0>>
* uni266C (U+266C): L<<267.0,689.0>--<270.0,165.0>>
* uni266C (U+266C): L<<305.0,121.0>--<307.0,495.0>>
* uni266C (U+266C): L<<708.0,-80.0>--<710.0,493.0>>
* z (U+007A): L<<262.0,34.0>--<129.0,33.0>>
* zacute (U+017A): L<<262.0,34.0>--<129.0,33.0>>
* zcaron (U+017E): L<<262.0,34.0>--<129.0,33.0>>
* zdotaccent (U+017C): L<<262.0,34.0>--<129.0,33.0>>
[code: found-semi-vertical]
Result: WARN
Total:
ERROR: 0
FAIL: 3
WARN: 9
INFO: 2
SKIP: 47
PASS: 47
[PPPFPPPPPSPIPSPPPISSWSWSSSFPSPPSWPPPSPPPPPSPPSSPPSSPPSPPPFSPPPSSSPPWWWPPPSSSSSSSSSSSSSSSSSSSPSSSSPPPPPWWWSSS] 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!)
d:\Fonts\A Context Original\Common Serif\OTF>
Here is what Fontbakery find in Common Serif (check-googlefonts test):
d:\Fonts\A Context Original\Common Serif\OTF>fontbakery check-googlefonts commonserif-regular.otf Start ... running 246 individual check executions.
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.
More info: https://github.com/googlefonts/fontbakery/issues/3049
INFO From a total of 1 font files, 1 of them (100.00%)
lack a STAT table.
And these are the most common STAT axis orderings:
[code: summary]
Result: INFO
com.google.fonts/check/canonical_filename Checking file is named canonically. with commonserif-regular.otf
Rationale:
A font's filename must be composed as "<familyname>-<stylename>.ttf":
- Nunito-Regular.ttf
- Oswald-BoldItalic.ttf
Variable fonts must list the axis tags in alphabetical order in square
brackets and separated by commas:
- Roboto[wdth,wght].ttf
- Familyname-Italic[wght].ttf
FAIL Expected "CommonSerif-Regular.otf. Got
commonserif-regular.otf. [code: bad-filename]
Result: FAIL
com.google.fonts/check/vendor_id Checking OS/2 achVendID. with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/3943
WARN OS/2 VendorID value ' ' is not yet recognized. If
you registered it recently, then it's safe to ignore this warning
message. Otherwise, you should set it to your own unique 4 character
code, and register it with Microsoft at
https://www.microsoft.com/typography/links/vendorlist.aspx
[code: unknown]
Result: WARN
com.google.fonts/check/name/unwanted_chars Substitute copyright, registered and trademark symbols in name table entries. with commonserif-regular.otf
FAIL NAMEID #0 contains symbols that should be replaced by
'(c)'. [code: unwanted-chars]
FAIL NAMEID #10 contains symbols that should be replaced
by '(c)'. [code: unwanted-chars]
Result: FAIL
com.google.fonts/check/license/OFL_copyright Check license file has good copyright string. with commonserif-regular.otf
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)"
More info: https://github.com/googlefonts/fontbakery/issues/2764
FAIL First line in license file is:
"copyright 2022 common serif project authors"
which does not match the expected format, similar to:
"Copyright 2022 The Familyname Project Authors (git url)" [code:
bad-format]
Result: FAIL
com.google.fonts/check/license/OFL_body_text Check OFL body text is correct. with commonserif-regular.otf
Rationale:
Check OFL body text is correct. Often users will accidently delete parts
of the body text.
More info: https://github.com/googlefonts/fontbakery/issues/3352
FAIL The OFL.txt body text is incorrect. Please use
https://github.com/googlefonts/Unified-Font-Repository/blob/main/OFL.t
xt as a template. You should only modify the first line. [code:
incorrect-ofl-body-text]
Result: FAIL
com.google.fonts/check/name/license Check copyright namerecords match license file. with commonserif-regular.otf
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.
FAIL License file OFL.txt exists but NameID 13 (LICENSE
DESCRIPTION) value on platform 3 (WINDOWS) is not specified for that.
Value was: "This Font Software is licensed under the SIL Open Font
License, Version 1.1" Must be changed to "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" [code: wrong]
Result: FAIL
com.google.fonts/check/name/description_max_length Description strings in the name table must not exceed 200 characters. with commonserif-regular.otf
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.
WARN A few name table entries with ID=10
(NameID.DESCRIPTION) are longer than 200 characters. Please check
whether those entries are copyright notices mistakenly stored in the
description string entries by a bug in an old FontLab version. If
that's the case, then such copyright notices must be removed from
these entries. [code: too-long]
Result: WARN
com.google.fonts/check/hinting_impact Show hinting filesize impact. with commonserif-regular.otf
Rationale:
This check is merely informative, displaying and useful comparison of
filesizes of hinted versus unhinted font files.
INFO Hinting filesize impact:
commonserif-regular.otf
Dehinted Size 287.7kb
Hinted Size 347.2kb
Increase 59.6kb
Change 20.7 %
[code: size-impact]
Result: INFO
com.google.fonts/check/epar EPAR table present in font? with commonserif-regular.otf
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/
More info: https://github.com/googlefonts/fontbakery/issues/226
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/name/ascii_only_entries Are there non-ASCII characters in ASCII-only NAME table entries? with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/1663
FAIL Bad string at [nameID 0, 'utf_16_be']: 'b'Copyright ©
2022 The Common Serif Authors.'' [code: bad-string]
FAIL There are 1 strings containing non-ASCII characters
in the ASCII-only NAME table entries. [code: non-ascii-strings]
Result: FAIL
com.google.fonts/check/font_copyright Copyright notices match canonical pattern in fonts with commonserif-regular.otf
More info: https://github.com/googlefonts/fontbakery/pull/2383
FAIL Name Table entry: Copyright notices should match a
pattern similar to: "Copyright 2019 The Familyname Project Authors
(git url)" But instead we have got: "Copyright © 2022 The Common Serif
Authors." [code: bad-notice-format]
Result: FAIL
com.google.fonts/check/fontv Check for font-v versioning. with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/1563
INFO Version string is: "Version 1.028" 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/ligature_carets Are there caret positions declared for every ligature? with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/1225
WARN This font lacks caret position values for ligature
glyphs on its GDEF table. [code: lacks-caret-pos]
Result: WARN
com.google.fonts/check/kerning_for_non_ligated_sequences Is there kerning info for non-ligated sequences? with commonserif-regular.otf
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).
More info: https://github.com/googlefonts/fontbakery/issues/1145
WARN GPOS table lacks kerning info for the following
non-ligated sequences:
- T + uni200D
- uni200D + h
- c + uni200D
- h + uni200D
- uni200D + k
- f + f
- f + h
- h + f
- f + i
- i + f
- 26 more.
Use -F or --full-lists to disable shortening of long lists. [code:
lacks-kern-info]
Result: WARN
com.google.fonts/check/name/line_breaks Name table entries should not contain line-breaks. with commonserif-regular.otf
Rationale:
There are some entries on the name table that may include more than one
line of text. The Google Fonts team, though, prefers to keep the name
table entries short and simple without line breaks.
For instance, some designers like to include the full text of a font
license in the "copyright notice" entry, but for the GFonts collection
this entry should only mention year, author and other basic info in a
manner enforced by com.google.fonts/check/font_copyright
FAIL Name entry DESCRIPTION on platform WINDOWS contains a
line-break. [code: line-break]
Result: FAIL
com.google.fonts/check/repo/zip_files A font repository should not include ZIP files with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/2903
FAIL Please do not host ZIP files on the project
repository. These files were detected: * .\CommonSerif_v.1.027.zip and
.\CommonSerif_v.1.028.zip [code: zip-files]
Result: FAIL
com.google.fonts/check/vertical_metrics Check font follows the Google Fonts vertical metric schema with commonserif-regular.otf
Rationale:
This check generally enforces Google Fonts’ vertical metrics
specifications. In particular: * lineGap must be 0 * Sum of hhea ascender
+ abs(descender) + linegap must be between 120% and 200% of UPM * Warning
if sum is over 150% of UPM
The threshold levels 150% (WARN) and 200% (FAIL) are somewhat arbitrarily
chosen and may hint at a glaring mistake in the metrics calculations or
UPM settings.
Our documentation includes further information:
https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics
More info: https://github.com/googlefonts/fontbakery/pull/3762
https://github.com/googlefonts/fontbakery/pull/3921
FAIL The sum of hhea.ascender + abs(hhea.descender) +
hhea.lineGap is 1140 when it should be at least 1200 [code:
bad-hhea-range]
Result: FAIL
com.google.fonts/check/missing_small_caps_glyphs Check small caps glyphs are available. with commonserif-regular.otf
Rationale:
Ensure small caps glyphs are available if a font declares smcp or c2sc OT
features.
More info: https://github.com/googlefonts/fontbakery/issues/3154
ERROR Failed with TypeError: unhashable type: 'list'
↳ File
"C:\Users\AcerPC\AppData\Local\Packages\PythonSoftwareFoundation.Pytho
n.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages
\fontbakery\checkrunner.py", line 194, in _exec_check
for sub_result in result: # Might raise.
↳ File
"C:\Users\AcerPC\AppData\Local\Packages\PythonSoftwareFoundation.Pytho
n.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages
\fontbakery\profiles\googlefonts.py", line 5978, in
com_google_fonts_check_missing_small_caps_glyphs
smcp_glyphs = set(subtable.mapping.values())
Result: ERROR
com.google.fonts/check/meta/script_lang_tags Ensure fonts have ScriptLangTags declared on the 'meta' table. with commonserif-regular.otf
Rationale:
The OpenType 'meta' table originated at Apple. Microsoft added it to OT
with just two DataMap records:
- dlng: comma-separated ScriptLangTags that indicate which scripts, or
languages and scripts, with possible variants, the font is designed for.
- slng: comma-separated ScriptLangTags that indicate which scripts, or
languages and scripts, with possible variants, the font supports.
The slng structure is intended to describe which languages and scripts
the font overall supports. For example, a Traditional Chinese font that
also contains Latin characters, can indicate Hant,Latn, showing that it
supports Hant, the Traditional Chinese variant of the Hani script, and it
also supports the Latn script.
The dlng structure is far more interesting. A font may contain various
glyphs, but only a particular subset of the glyphs may be truly "leading"
in the design, while other glyphs may have been included for technical
reasons. Such a Traditional Chinese font could only list Hant there,
showing that it’s designed for Traditional Chinese, but the font would
omit Latn, because the developers don’t think the font is really
recommended for purely Latin-script use.
The tags used in the structures can comprise just script, or also
language and script. For example, if a font has Bulgarian Cyrillic
alternates in the locl feature for the cyrl BGR OT languagesystem, it
could also indicate in dlng explicitly that it supports bul-Cyrl. (Note
that the scripts and languages in meta use the ISO language and script
codes, not the OpenType ones).
This check ensures that the font has the meta table containing the slng
and dlng structures.
All families in the Google Fonts collection should contain the 'meta'
table. Windows 10 already uses it when deciding on which fonts to fall
back to. The Google Fonts API and also other environments could use the
data for smarter filtering. Most importantly, those entries should be
added to the Noto fonts.
In the font making process, some environments store this data in external
files already. But the meta table provides a convenient way to store this
inside the font file, so some tools may add the data, and unrelated tools
may read this data. This makes the solution much more portable and
universal.
More info: https://github.com/googlefonts/fontbakery/issues/3349
WARN This font file does not have a 'meta' table. [code:
lacks-meta-table]
Result: WARN
com.google.fonts/check/family/win_ascent_and_descent Checking OS/2 usWinAscent & usWinDescent. with commonserif-regular.otf
Rationale:
A font's winAscent and winDescent values should be greater than or equal
to the head table's yMax, abs(yMin) values. If they are less than these
values, clipping can occur on Windows platforms
(https://github.com/RedHatBrand/Overpass/issues/33).
If the font includes tall/deep writing systems such as Arabic or
Devanagari, the winAscent and winDescent can be greater than the yMax and
abs(yMin) to accommodate vowel marks.
When the win Metrics are significantly greater than the upm, the
linespacing can appear too loose. To counteract this, enabling the OS/2
fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2
typo values instead. This means the font developer can control the
linespacing with the typo values, whilst avoiding clipping by setting the
win values to values greater than the yMax and abs(yMin).
FAIL OS/2.usWinAscent value should be equal or greater
than 1047, but got 894 instead [code: ascent]
FAIL OS/2.usWinDescent value should be equal or greater
than 305, but got 246 instead. [code: descent]
Result: FAIL
com.google.fonts/check/required_tables Font contains all required tables? with commonserif-regular.otf
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:
- GPOS
- GSUB
[code: optional-tables]
Result: INFO
com.google.fonts/check/superfamily/list List all superfamily filepaths with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/1487
INFO . [code: family-path]
Result: INFO
com.google.fonts/check/unreachable_glyphs Check font contains no unreachable glyphs with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/3160
WARN The following glyphs could not be reached by
codepoint or substitution rules:
- caron.cap
- eight.oldstyle
- uni03020300
- uni03020301
- uni03020303
- uni03020309
- uni03030301
- uni03030304
- uni03030308
- uni03040300
- 73 more.
Use -F or --full-lists to disable shortening of long lists.
[code: unreachable-glyphs]
Result: WARN
com.google.fonts/check/soft_hyphen Does the font contain a soft hyphen? with commonserif-regular.otf
Rationale:
The 'Soft Hyphen' character (codepoint 0x00AD) is used to mark a
hyphenation possibility within a word in the absence of or overriding
dictionary hyphenation.
It is sometimes designed empty with no width (such as a control
character), sometimes the same as the traditional hyphen, sometimes
double encoded with the hyphen.
That being said, it is recommended to not include it in the font at all,
because discretionary hyphenation should be handled at the level of the
shaping engine, not the font. Also, even if present, the software would
not display that character.
More discussion at:
https://typedrawers.com/discussion/2046
/special-dash-things-softhyphen-horizontalbar
More info: https://github.com/googlefonts/fontbakery/issues/4046
https://github.com/googlefonts/fontbakery/issues/3486
WARN This font has a 'Soft Hyphen' character. [code:
softhyphen]
Result: WARN
com.google.fonts/check/soft_dotted Ensure soft_dotted characters lose their dot when combined with marks that replace the dot. with commonserif-regular.otf
Rationale:
An accent placed on characters with a "soft dot", like i or j, causes the
dot to disappear. An explicit dot above can be added where required. See
"Diacritics on i and j" in Section 7.1, "Latin" in The Unicode Standard.
Characters with the Soft_Dotted property are listed in
https://www.unicode.org/Public/UCD/latest/ucd/PropList.txt
See also:
https://googlefonts.github.io/gf-guide/diacritics.html#soft-dotted-glyphs
More info: https://github.com/googlefonts/fontbakery/issues/4059
FAIL The dot of soft dotted characters used in
orthographies must disappear in the following strings: į̀ į́ į̂ į̃ į̄
į̌ ɨ̧̀ ɨ̧́
ɨ̧̂ ɨ̧̌ ɨ̱̀ ɨ̱́ ɨ̱̈ і́ ḭ̀ ḭ́ ḭ̄ ị̀ ị́ ị̂ ị̃ ị̄
The dot of soft dotted characters should disappear in other cases, for
example: i̅ i̽ i̾ i̿ i͂ i͆ i͊ i͋ i͌ i͐ i͒ i͛ iͣ iͤ iͥ iͦ iͧ iͨ iͩ iͪ
[code: soft-dotted]
Result: FAIL
com.adobe.fonts/check/freetype_rasterizer:googlefonts Ensure that the font can be rasterized by FreeType. (derived from com.adobe.fonts/check/freetype_rasterizer) with commonserif-regular.otf
Rationale:
Malformed fonts can cause FreeType to crash.
FAIL FreeType is not available. To fix this, invoke the
'freetype' extra when installing Font Bakery: pip3 install -U
fontbakery[freetype] [code: freetype-not-installed]
Result: FAIL
com.google.fonts/check/math_signs_width Check math signs have the same width. with commonserif-regular.otf
Rationale:
It is a common practice to have math signs sharing the same width
(preferably the same width as tabular figures accross the entire font
family).
This probably comes from the will to avoid additional tabular math signs
knowing that their design can easily share the same width.
More info: https://github.com/googlefonts/fontbakery/issues/3832
WARN The most common width is 527 among a set of 14 math
glyphs. The following math glyphs have a different width, though:
Width = 550: multiply, equal, plusminus, divide, less, minus,
congruent, greater, uni2213, plus, uni2214
Width = 599: logicalnot
Width = 506: suchthat, notelement, element
Width = 501: uni220C
Width = 670: proportional
Width = 541: orthogonal
Width = 666: uni2222, angle, uni2221
Width = 522: uni2285, propersuperset, propersubset, notsubset
Width = 663: uni22A2, uni22A3
Width = 629: uni22A5, uni22A4
[code: width-outliers]
Result: WARN
com.google.fonts/check/name/no_copyright_on_description Description strings in the name table must not contain copyright info. with commonserif-regular.otf
FAIL Some namerecords with ID=10 (NameID.DESCRIPTION)
containing copyright info should be removed (perhaps these were added
by a longstanding FontLab Studio 5.x bug that copied copyright notices
to them.) [code: copyright-on-description]
Result: FAIL
com.google.fonts/check/dsig Does the font have a DSIG table? with commonserif-regular.otf
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.
As we approach the EOL date, it is now considered better to completely
remove the table.
But if you still want your font to support OpenType features on Office
2013, then you may find it handy to add a fake signature on a placeholder
DSIG table by running one of the helper scripts provided at
https://github.com/googlefonts/gftools
Reference: https://github.com/googlefonts/fontbakery/issues/1845
More info: https://github.com/googlefonts/fontbakery/issues/3398
WARN This font has a digital signature (DSIG table) which
is only required - even if only a placeholder - on old programs like
MS Office 2013 in order to work properly. The current recommendation
is to completely remove the DSIG table. [code: found-DSIG]
Result: WARN
com.google.fonts/check/gdef_spacing_marks Check glyphs in mark glyph class are non-spacing. with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/2877
WARN The following spacing glyphs may be in the GDEF mark
glyph class by mistake: uni0484 (U+0484), uni0487 (U+0487), uni2DE0
(U+2DE0), uni2DE1 (U+2DE1), uni2DE2 (U+2DE2), uni2DE3 (U+2DE3),
uni2DE4 (U+2DE4), uni2DE5 (U+2DE5), uni2DE6 (U+2DE6), uni2DE7 (U+2DE7)
and 39 more.
Use -F or --full-lists to disable shortening of long lists. [code:
spacing-mark-glyphs]
Result: WARN
com.google.fonts/check/gdef_mark_chars Check mark characters are in GDEF mark glyph class. with commonserif-regular.otf
Rationale:
Mark characters should be in the GDEF mark glyph class.
More info: https://github.com/googlefonts/fontbakery/issues/2877
WARN The following mark characters could be in the GDEF
mark glyph class: uni0488 (U+0488), uni0489 (U+0489), uniA670
(U+A670), uniA671 (U+A671) and uniA672 (U+A672) [code: mark-chars]
Result: WARN
com.google.fonts/check/outline_colinear_vectors Do any segments have colinear vectors? with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/pull/3088
WARN The following glyphs have colinear vectors:
* chi (U+03C7): L<<100.0,-235.0>--<157.0,-126.0>> ->
L<<157.0,-126.0>--<240.0,57.0>>
* chi (U+03C7): L<<276.0,130.0>--<417.0,332.0>> ->
L<<417.0,332.0>--<490.0,439.0>>
* eta (U+03B7): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* eta (U+03B7): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* etatonos (U+03AE): L<<185.0,0.0>--<175.0,311.0>> ->
L<<175.0,311.0>--<175.0,312.0>>
* etatonos (U+03AE): L<<95.0,317.0>--<95.0,137.0>> ->
L<<95.0,137.0>--<85.0,-10.0>>
* iota (U+03B9): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* iotadieresis (U+03CA): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* iotadieresistonos (U+0390): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* iotatonos (U+03AF): L<<153.0,99.0>--<153.0,134.0>> ->
L<<153.0,134.0>--<179.0,432.0>>
* 49 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 commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/issues/3064
WARN The following glyphs have jaggy segments:
* uni049B (U+049B):
B<<356.0,157.0>-<337.0,206.0>-<286.0,227.0>-<246.0,227.0>>/B<<246.0,
7.0>-<282.0,232.0>-<320.0,269.0>-<347.0,320.0>> = 7.907162702958418
* uni049D (U+049D):
B<<423.0,157.0>-<403.0,206.0>-<364.0,227.0>-<310.0,227.0>>/B<<310.0,
7.0>-<361.0,235.0>-<387.0,285.0>-<403.0,323.0>> = 8.914926957147863
* uni049F (U+049F):
B<<354.0,157.0>-<333.0,206.0>-<294.0,227.0>-<240.0,227.0>>/B<<240.0,
7.0>-<291.0,235.0>-<317.0,285.0>-<333.0,323.0>> = 8.914926957147863
* uni05DC (U+05DC):
B<<71.0,719.0>-<63.0,721.0>-<43.0,728.0>-<41.0,746.0>>/B<<41.0,746.0
<41.0,745.0>-<11.0,743.0>-<11.0,698.0>> = 6.340191745909908
* uni2695 (U+2695):
L<<396.0,405.0>--<390.0,408.0>>/L<<390.0,408.0>--<404.0,403.0>> =
6.911227119024662
[code: found-jaggy-segments]
Result: WARN
com.google.fonts/check/outline_semi_vertical Do outlines contain any semi-vertical or semi-horizontal lines? with commonserif-regular.otf
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.
More info: https://github.com/googlefonts/fontbakery/pull/3088
WARN The following glyphs have
semi-vertical/semi-horizontal lines:
* e (U+0065): L<<121.0,248.0>--<387.0,246.0>>
* eacute (U+00E9): L<<121.0,248.0>--<387.0,246.0>>
* ebreve (U+0115): L<<121.0,248.0>--<387.0,246.0>>
* ecaron (U+011B): L<<121.0,248.0>--<387.0,246.0>>
* ecircumflex (U+00EA): L<<121.0,248.0>--<387.0,246.0>>
* edieresis (U+00EB): L<<121.0,248.0>--<387.0,246.0>>
* edotaccent (U+0117): L<<121.0,248.0>--<387.0,246.0>>
* egrave (U+00E8): L<<121.0,248.0>--<387.0,246.0>>
* emacron (U+0113): L<<121.0,248.0>--<387.0,246.0>>
* eogonek (U+0119): L<<121.0,248.0>--<387.0,246.0>>
* 59 more.
Use -F or --full-lists to disable shortening of long lists. [code:
found-semi-vertical]
Result: WARN
Total:
ERROR: 1
FAIL: 14
WARN: 14
INFO: 6
SKIP: 141
PASS: 70
[SSSPISFSSSSSSSSSSSSSPWPSSFPSFFFSWIPPSSISPFSSSSSSSSSSSSSSSSSSSSSSFSSSSSSSSSSSSPSSSPSSPPISSSSPPSSSSWWPFPPSSPSFFSSSSSSSSSSSSSSSSEPPWPSPSSPPPSPPPFPPPPPSPIPSPPPISSWSWSSSFPFPPSWPPPSPPPSPSPPSSPPSSPPSPPPFSPPPSSSPPWWWPPPSSSSSSSSSSSSSSSSSSSPSSSSPPPPPWWWSSS] 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!)
d:\Fonts\A Context Original\Common Serif\OTF>
Would be nice to be able to easily use this font on the web.