Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google Fonts compatibility? #49

Open
redbrain opened this issue Jul 23, 2023 · 3 comments
Open

Google Fonts compatibility? #49

redbrain opened this issue Jul 23, 2023 · 3 comments

Comments

@redbrain
Copy link

Would be nice to be able to easily use this font on the web.

@waldyrious
Copy link
Contributor

waldyrious commented Jul 23, 2023

See prior discussion regarding Linux Libertine / Libertinus at google/fonts#12, and more broadly about hosting Libertinus on a CDN at alerque/libertinus#362.

@StefanPeev
Copy link
Owner

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>

@StefanPeev
Copy link
Owner

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>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants