davelab6
commented
6 years ago Open cssobral2013 opened 6 years ago
davelab6
commented
6 years ago 
laerm0
commented
6 years ago I was talking with the designer earlier this year and I think I am going to use some free time later this year to variableize these fonts, FYI.
davelab6
commented
3 years ago @RosaWagner this would be good to prioritize in Q1
RosaWagner
commented
3 years ago @davelab6 I started to get into this.
Fontbakery version: 0.7.37
--- Rationale --- Dave C Lemon (Adobe Type Team) recommends setting the underline thickness to be consistent across the family. If thicknesses are not family consistent, words set on the same line which have different styles look strange. See also: https://twitter.com/typenerd1/status/690361887926697986* 🔥 **FAIL** Thickness of the underline is not the same across this family. In order to fix this, please make sure that the underlineThickness value is the same in the 'post' table of all of this family font files. Detected underlineThickness values are: Go-Bold-Italic.ttf: 100 Go-Bold.ttf: 100 Go-Italic.ttf: 50 Go-Regular.ttf: 50 [code: inconsistent-underline-thickness]
--- Rationale --- A font's filename must be composed in the following manner: <familyname>-<stylename>.ttf - Nunito-Regular.ttf, - Oswald-BoldItalic.ttf Variable fonts must list the axis tags in alphabetical order in square brackets and separated by commas: - Roboto[wdth,wght].ttf - Familyname-Italic[wght].ttf* 🔥 **FAIL** Style name used in "Go-Bold-Italic.ttf" is not canonical. You should rebuild the font using any of the following style names: "Thin", "ExtraLight", "Light", "Regular", "Medium", "SemiBold", "Bold", "ExtraBold", "Black", "Thin Italic", "ExtraLight Italic", "Light Italic", "Italic", "Medium Italic", "SemiBold Italic", "Bold Italic", "ExtraBold Italic", "Black Italic". [code: bad-static-filename]
--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.* 🔥 **FAIL** Missing required codepoints: 0x2074 (SUPERSCRIPT FOUR) [code: missing-codepoints]
--- Rationale --- Google Fonts expects variable fonts, static ttfs and static otfs to have differing OS/2 usWeightClass values. For Variable Fonts, Thin-Black must be 100-900 For static ttfs, Thin-Black can be 100-900 or 250-900 For static otfs, Thin-Black must be 250-900 If static otfs are set lower than 250, text may appear blurry in legacy Windows applications. Glyphsapp users can change the usWeightClass value of an instance by adding a 'weightClass' customParameter.* 🔥 **FAIL** OS/2 usWeightClass is '600' when it should be '400'. [code: bad-value]
--- Rationale --- The 'post' table italicAngle property should be a reasonable amount, likely not more than -20°, never more than -30°, and never greater than 0°. Note that in the OpenType specification, the value is negative for a lean rightwards. https://docs.microsoft.com/en-us/typography/opentype/spec/post* 🔥 **FAIL** Font is not italic, so post.italicAngle should be equal to zero. [code: non-zero-normal]
--- Rationale --- The values of the flags on the macStyle entry on the 'head' OpenType table that describe whether a font is bold and/or italic must be coherent with the actual style of the font as inferred by its filename.* 🔥 **FAIL** head macStyle ITALIC bit should be unset. [code: bad-ITALIC]
--- Rationale --- Requirements for the FULL_FONT_NAME entries in the 'name' table.* 🔥 **FAIL** [FULL_FONT_NAME(4):MACINTOSH(1)] Expected: "Go Bold" But got: "Go Bold Italic" [code: bad-entry] * 🔥 **FAIL** [FULL_FONT_NAME(4):WINDOWS(3)] Expected: "Go Bold" But got: "Go Bold Italic" [code: bad-entry]
--- Rationale --- Requirements for the POSTSCRIPT_NAME entries in the 'name' table.* 🔥 **FAIL** [POSTSCRIPT_NAME(6):MACINTOSH(1)] Expected: "Go-Bold" But got: "Go-BoldItalic" [code: bad-entry] * 🔥 **FAIL** [POSTSCRIPT_NAME(6):WINDOWS(3)] Expected: "Go-Bold" But got: "Go-BoldItalic" [code: bad-entry]
--- 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 LICENSE_DESCRIPTION on platform MACINTOSH contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]
--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).* 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 2193, but got 1935 instead [code: ascent] * 🔥 **FAIL** OS/2.usWinDescent value should be equal or greater than 543, but got 432 instead. [code: descent]
--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.* 🔥 **FAIL** OS/2 sTypoAscender (1579) and hhea ascent (1935) must be equal. [code: ascender]
--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845* 🔥 **FAIL** This font lacks a digital signature (DSIG table). Some applications may require one (even if only a dummy placeholder) in order to work properly. You can add a DSIG table by running the `gftools fix-dsig` script. [code: lacks-signature]
--- 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.* ⚠ **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]
--- 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]
--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.* ⚠ **WARN** ttfautohint used in font = 1.6; installed = 1.8.3; Need to re-run with the newer version! [code: old-ttfa]
--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.* ⚠ **WARN** This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 [code: contour-count]
--- Rationale --- This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lower case Latin letters), cap-height, ascender and descender Y coordinates. Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * dollar: X=775.0,Y=1479.0 (should be at cap-height 1480?) * dollar: X=935.0,Y=1479.0 (should be at cap-height 1480?) * f: X=1051.0,Y=1578.0 (should be at ascender 1579?) * t: X=665.0,Y=1.0 (should be at baseline 0?) * Aring: X=1056.0,Y=1577.0 (should be at ascender 1579?) * Aring: X=1056.0,Y=1577.0 (should be at ascender 1579?) * atilde: X=1063.0,Y=1478.0 (should be at cap-height 1480?) * ntilde: X=1055.0,Y=1478.0 (should be at cap-height 1480?) * otilde: X=1045.0,Y=1478.0 (should be at cap-height 1480?) * itilde: X=725.0,Y=1478.0 (should be at cap-height 1480?) and 30 more. [code: found-misalignments]
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.* ⚠ **WARN** The following glyphs have colinear vectors: * Atilde: L<<1082.0,1892.0>--<1114.0,1866.0>> -> L<<1114.0,1866.0>--<1141.0,1844.0>> * Eng: L<<1601.0,1480.0>--<1306.0,0.0>> -> L<<1306.0,0.0>--<1296.0,-46.0>> * Itilde: L<<806.0,1892.0>--<838.0,1866.0>> -> L<<838.0,1866.0>--<865.0,1844.0>> * Ntilde: L<<1100.0,1892.0>--<1132.0,1866.0>> -> L<<1132.0,1866.0>--<1159.0,1844.0>> * Otilde: L<<1139.0,1892.0>--<1171.0,1866.0>> -> L<<1171.0,1866.0>--<1198.0,1844.0>> * S: L<<763.0,972.0>--<868.0,928.0>> -> L<<868.0,928.0>--<1025.0,865.0>> * S: L<<945.0,546.0>--<818.0,598.0>> -> L<<818.0,598.0>--<667.0,660.0>> * Sacute: L<<763.0,972.0>--<868.0,928.0>> -> L<<868.0,928.0>--<1025.0,865.0>> * Sacute: L<<945.0,546.0>--<818.0,598.0>> -> L<<818.0,598.0>--<667.0,660.0>> * Scaron: L<<763.0,972.0>--<868.0,928.0>> -> L<<868.0,928.0>--<1025.0,865.0>> and 53 more. [code: found-colinear-vectors]
--- Rationale --- This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.* ⚠ **WARN** The following glyphs have jaggy segments: * club: B<<1029.0,241.0>-<830.0,241.0>-<716.0,514.0>>/L<<716.0,514.0>--<806.0,0.0>> = 12.732904114987004 * club: L<<537.0,0.0>--<626.0,514.0>>/B<<626.0,514.0>-<513.0,241.0>-<315.0,241.0>> = 12.662149957057041 * gopher: B<<407.5,668.0>-<371.0,664.0>-<314.0,654.0>>/B<<314.0,654.0>-<326.0,655.0>-<337.0,662.5>> = 5.186984997225381 * gopher: B<<595.0,824.5>-<640.0,816.0>-<689.0,806.0>>/B<<689.0,806.0>-<648.0,813.0>-<601.0,817.5>> = 1.8458340932778838 and lslash: L<<302.0,829.0>--<302.0,825.0>>/L<<302.0,825.0>--<453.0,1579.0>> = 11.324545016297893 [code: found-jaggy-segments]
--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.* 🔥 **FAIL** Missing required codepoints: 0x2074 (SUPERSCRIPT FOUR) [code: missing-codepoints]
--- Rationale --- Google Fonts expects variable fonts, static ttfs and static otfs to have differing OS/2 usWeightClass values. For Variable Fonts, Thin-Black must be 100-900 For static ttfs, Thin-Black can be 100-900 or 250-900 For static otfs, Thin-Black must be 250-900 If static otfs are set lower than 250, text may appear blurry in legacy Windows applications. Glyphsapp users can change the usWeightClass value of an instance by adding a 'weightClass' customParameter.* 🔥 **FAIL** OS/2 usWeightClass is '600' when it should be '700'. [code: bad-value]
--- 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 LICENSE_DESCRIPTION on platform MACINTOSH contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]
--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).* 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 2193, but got 1935 instead [code: ascent] * 🔥 **FAIL** OS/2.usWinDescent value should be equal or greater than 543, but got 432 instead. [code: descent]
--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.* 🔥 **FAIL** OS/2 sTypoAscender (1579) and hhea ascent (1935) must be equal. [code: ascender]
--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845* 🔥 **FAIL** This font lacks a digital signature (DSIG table). Some applications may require one (even if only a dummy placeholder) in order to work properly. You can add a DSIG table by running the `gftools fix-dsig` script. [code: lacks-signature]
--- 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.* ⚠ **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]
--- 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]
--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.* ⚠ **WARN** ttfautohint used in font = 1.6; installed = 1.8.3; Need to re-run with the newer version! [code: old-ttfa]
--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.* ⚠ **WARN** This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 [code: contour-count]
--- Rationale --- This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lower case Latin letters), cap-height, ascender and descender Y coordinates. Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * dollar: X=480.0,Y=1479.0 (should be at cap-height 1480?) * dollar: X=640.0,Y=1479.0 (should be at cap-height 1480?) * f: X=736.0,Y=1578.0 (should be at ascender 1579?) * t: X=665.0,Y=1.0 (should be at baseline 0?) * Aring: X=741.0,Y=1577.0 (should be at ascender 1579?) * Aring: X=741.0,Y=1577.0 (should be at ascender 1579?) * atilde: X=700.0,Y=1478.0 (should be at cap-height 1480?) * ntilde: X=772.0,Y=1478.0 (should be at cap-height 1480?) * otilde: X=762.0,Y=1478.0 (should be at cap-height 1480?) * itilde: X=432.0,Y=1478.0 (should be at cap-height 1480?) and 28 more. [code: found-misalignments]
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.* ⚠ **WARN** The following glyphs have colinear vectors: * Atilde: L<<716.0,1892.0>--<754.0,1866.0>> -> L<<754.0,1866.0>--<785.0,1844.0>> * Eng: L<<1306.0,1480.0>--<1306.0,0.0>> -> L<<1306.0,0.0>--<1306.0,-46.0>> * Itilde: L<<440.0,1912.0>--<478.0,1886.0>> -> L<<478.0,1886.0>--<509.0,1864.0>> * Ntilde: L<<734.0,1892.0>--<772.0,1866.0>> -> L<<772.0,1866.0>--<803.0,1844.0>> * Otilde: L<<773.0,1892.0>--<811.0,1866.0>> -> L<<811.0,1866.0>--<842.0,1844.0>> * S: L<<569.0,972.0>--<683.0,928.0>> -> L<<683.0,928.0>--<853.0,865.0>> * S: L<<836.0,546.0>--<699.0,598.0>> -> L<<699.0,598.0>--<536.0,660.0>> * Sacute: L<<569.0,972.0>--<683.0,928.0>> -> L<<683.0,928.0>--<853.0,865.0>> * Sacute: L<<836.0,546.0>--<699.0,598.0>> -> L<<699.0,598.0>--<536.0,660.0>> * Scaron: L<<569.0,972.0>--<683.0,928.0>> -> L<<683.0,928.0>--<853.0,865.0>> and 53 more. [code: found-colinear-vectors]
--- Rationale --- This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.* ⚠ **WARN** The following glyphs have jaggy segments: * club: B<<1029.0,241.0>-<830.0,241.0>-<716.0,514.0>>/L<<716.0,514.0>--<806.0,0.0>> = 12.732904114987004 * club: L<<537.0,0.0>--<626.0,514.0>>/B<<626.0,514.0>-<513.0,241.0>-<315.0,241.0>> = 12.662149957057041 and lslash: L<<137.0,829.0>--<138.0,825.0>>/L<<138.0,825.0>--<138.0,1579.0>> = 14.036243467926484 [code: found-jaggy-segments]
--- Rationale --- This check detects line segments which are nearly, but not quite, exactly horizontal or vertical. Sometimes such lines are created by design, but often they are indicative of a design error. This check is disabled for italic styles, which often contain nearly-upright lines.* ⚠ **WARN** The following glyphs have semi-vertical/semi-horizontal lines: * alpha: L<<1214.0,2.0>--<960.0,0.0>> * alphatonos: L<<1214.0,2.0>--<960.0,0.0>> * uni0429: L<<2036.0,210.0>--<2037.0,-395.0>> and uni2113: L<<510.0,925.0>--<509.0,793.0>> [code: found-semi-vertical]
--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.* 🔥 **FAIL** Missing required codepoints: 0x2074 (SUPERSCRIPT FOUR) [code: missing-codepoints]
--- 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 LICENSE_DESCRIPTION on platform MACINTOSH contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]
--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).* 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 2193, but got 1935 instead [code: ascent] * 🔥 **FAIL** OS/2.usWinDescent value should be equal or greater than 543, but got 432 instead. [code: descent]
--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.* 🔥 **FAIL** OS/2 sTypoAscender (1579) and hhea ascent (1935) must be equal. [code: ascender]
--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845* 🔥 **FAIL** This font lacks a digital signature (DSIG table). Some applications may require one (even if only a dummy placeholder) in order to work properly. You can add a DSIG table by running the `gftools fix-dsig` script. [code: lacks-signature]
--- 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.* ⚠ **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]
--- 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]
--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.* ⚠ **WARN** ttfautohint used in font = 1.6; installed = 1.8.3; Need to re-run with the newer version! [code: old-ttfa]
--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.* ⚠ **WARN** This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 [code: contour-count]
--- Rationale --- This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lower case Latin letters), cap-height, ascender and descender Y coordinates. Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * f: X=956.0,Y=1578.0 (should be at ascender 1579?) * j: X=-152.0,Y=-397.0 (should be at descender -395?) * j: X=-152.0,Y=-397.0 (should be at descender -395?) * ij: X=282.0,Y=-397.0 (should be at descender -395?) * ij: X=282.0,Y=-397.0 (should be at descender -395?) * jcircumflex: X=-152.0,Y=-397.0 (should be at descender -395?) * jcircumflex: X=-152.0,Y=-397.0 (should be at descender -395?) * Lcaron: X=977.0,Y=1481.0 (should be at cap-height 1480?) * Lcaron: X=1174.0,Y=1481.0 (should be at cap-height 1480?) * uni0163: X=307.0,Y=-2.0 (should be at baseline 0?) and 29 more. [code: found-misalignments]
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.* ⚠ **WARN** The following glyphs have colinear vectors: * Gamma: L<<566.0,827.0>--<535.0,672.0>> -> L<<535.0,672.0>--<401.0,0.0>> * Gamma: L<<665.0,1323.0>--<566.0,827.0>> -> L<<566.0,827.0>--<535.0,672.0>> * approxequal: L<<616.0,549.0>--<675.0,517.0>> -> L<<675.0,517.0>--<745.0,481.0>> * approxequal: L<<675.0,517.0>--<745.0,481.0>> -> L<<745.0,481.0>--<814.0,445.0>> * approxequal: L<<701.0,315.0>--<644.0,347.0>> -> L<<644.0,347.0>--<574.0,383.0>> * approxequal: L<<705.0,993.0>--<764.0,961.0>> -> L<<764.0,961.0>--<833.0,925.0>> * approxequal: L<<764.0,961.0>--<833.0,925.0>> -> L<<833.0,925.0>--<903.0,889.0>> * approxequal: L<<790.0,759.0>--<733.0,791.0>> -> L<<733.0,791.0>--<663.0,827.0>> * asciitilde: L<<720.0,703.0>--<817.0,626.0>> -> L<<817.0,626.0>--<873.0,580.0>> * asciitilde: L<<734.0,481.0>--<637.0,558.0>> -> L<<637.0,558.0>--<579.0,604.0>> and 32 more. [code: found-colinear-vectors]
--- Rationale --- This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.* ⚠ **WARN** The following glyphs have jaggy segments: * Aring: B<<1157.0,1547.0>-<1085.0,1487.0>-<999.0,1480.0>>/L<<999.0,1480.0>--<1084.0,1480.0>> = 4.653351587268329 * Aring: L<<876.0,1480.0>--<957.0,1480.0>>/B<<957.0,1480.0>-<881.0,1488.0>-<836.0,1547.0>> = 6.009005957494474 * club: B<<1040.0,241.0>-<841.0,241.0>-<727.0,514.0>>/L<<727.0,514.0>--<817.0,0.0>> = 12.732904114987004 * club: L<<548.0,0.0>--<637.0,514.0>>/B<<637.0,514.0>-<524.0,241.0>-<326.0,241.0>> = 12.662149957057041 * gopher: B<<407.5,668.0>-<371.0,664.0>-<314.0,654.0>>/B<<314.0,654.0>-<326.0,655.0>-<337.0,662.5>> = 5.186984997225381 * gopher: B<<595.0,824.5>-<640.0,816.0>-<689.0,806.0>>/B<<689.0,806.0>-<648.0,813.0>-<601.0,817.5>> = 1.8458340932778838 and uni043C: L<<1225.0,825.0>--<1229.0,831.0>>/L<<1229.0,831.0>--<805.0,74.0>> = 4.4366318994291625 [code: found-jaggy-segments]
--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.* 🔥 **FAIL** Missing required codepoints: 0x2074 (SUPERSCRIPT FOUR) [code: missing-codepoints]
--- Rationale --- Requirements for the POSTSCRIPT_NAME entries in the 'name' table.* 🔥 **FAIL** [POSTSCRIPT_NAME(6):MACINTOSH(1)] Expected: "Go-Regular" But got: "GoRegular" [code: bad-entry] * 🔥 **FAIL** [POSTSCRIPT_NAME(6):WINDOWS(3)] Expected: "Go-Regular" But got: "GoRegular" [code: bad-entry]
--- 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 LICENSE_DESCRIPTION on platform MACINTOSH contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]
--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).* 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 2193, but got 1935 instead [code: ascent] * 🔥 **FAIL** OS/2.usWinDescent value should be equal or greater than 543, but got 432 instead. [code: descent]
--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.* 🔥 **FAIL** OS/2 sTypoAscender (1579) and hhea ascent (1935) must be equal. [code: ascender]
--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845* 🔥 **FAIL** This font lacks a digital signature (DSIG table). Some applications may require one (even if only a dummy placeholder) in order to work properly. You can add a DSIG table by running the `gftools fix-dsig` script. [code: lacks-signature]
--- 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.* ⚠ **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]
--- 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]
--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.* ⚠ **WARN** ttfautohint used in font = 1.6; installed = 1.8.3; Need to re-run with the newer version! [code: old-ttfa]
--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.* ⚠ **WARN** This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 [code: contour-count]
--- Rationale --- This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lower case Latin letters), cap-height, ascender and descender Y coordinates. Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * f: X=630.0,Y=1578.0 (should be at ascender 1579?) * j: X=-84.0,Y=-397.0 (should be at descender -395?) * j: X=-84.0,Y=-397.0 (should be at descender -395?) * eth: X=108.0,Y=1580.0 (should be at ascender 1579?) * eth: X=533.0,Y=1478.0 (should be at cap-height 1480?) * aogonek: X=860.0,Y=-2.0 (should be at baseline 0?) * itilde: X=239.0,Y=1479.0 (should be at cap-height 1480?) * ij: X=351.0,Y=-397.0 (should be at descender -395?) * ij: X=351.0,Y=-397.0 (should be at descender -395?) * jcircumflex: X=-84.0,Y=-397.0 (should be at descender -395?) and 30 more. [code: found-misalignments]
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.* ⚠ **WARN** The following glyphs have colinear vectors: * Gamma: L<<390.0,1323.0>--<390.0,827.0>> -> L<<390.0,827.0>--<390.0,672.0>> * Gamma: L<<390.0,827.0>--<390.0,672.0>> -> L<<390.0,672.0>--<390.0,0.0>> * approxequal: L<<496.0,549.0>--<561.0,517.0>> -> L<<561.0,517.0>--<638.0,481.0>> * approxequal: L<<496.0,993.0>--<561.0,961.0>> -> L<<561.0,961.0>--<638.0,925.0>> * approxequal: L<<561.0,517.0>--<638.0,481.0>> -> L<<638.0,481.0>--<715.0,445.0>> * approxequal: L<<561.0,961.0>--<638.0,925.0>> -> L<<638.0,925.0>--<715.0,889.0>> * approxequal: L<<628.0,315.0>--<564.0,347.0>> -> L<<564.0,347.0>--<487.0,383.0>> * approxequal: L<<628.0,759.0>--<564.0,791.0>> -> L<<564.0,791.0>--<487.0,827.0>> * asciitilde: L<<569.0,703.0>--<681.0,626.0>> -> L<<681.0,626.0>--<747.0,580.0>> * asciitilde: L<<627.0,481.0>--<515.0,558.0>> -> L<<515.0,558.0>--<448.0,604.0>> and 33 more. [code: found-colinear-vectors]
--- Rationale --- This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.* ⚠ **WARN** The following glyphs have jaggy segments: * Aring: B<<848.0,1547.0>-<788.0,1487.0>-<704.0,1480.0>>/L<<704.0,1480.0>--<789.0,1480.0>> = 4.763641690726144 * Aring: L<<581.0,1480.0>--<662.0,1480.0>>/B<<662.0,1480.0>-<584.0,1488.0>-<527.0,1547.0>> = 5.856013585428907 * club: B<<1029.0,241.0>-<830.0,241.0>-<716.0,514.0>>/L<<716.0,514.0>--<806.0,0.0>> = 12.732904114987004 * club: L<<537.0,0.0>--<626.0,514.0>>/B<<626.0,514.0>-<513.0,241.0>-<315.0,241.0>> = 12.662149957057041 and uni043C: L<<1050.0,825.0>--<1052.0,831.0>>/L<<1052.0,831.0>--<780.0,74.0>> = 1.3290777191376548 [code: found-jaggy-segments]
--- Rationale --- This check detects line segments which are nearly, but not quite, exactly horizontal or vertical. Sometimes such lines are created by design, but often they are indicative of a design error. This check is disabled for italic styles, which often contain nearly-upright lines.* ⚠ **WARN** The following glyphs have semi-vertical/semi-horizontal lines: * m: L<<1367.0,0.0>--<1366.0,759.0>> * phi: L<<754.0,549.0>--<753.0,138.0>> * uni041B: L<<556.0,1293.0>--<555.0,1163.0>> * uni043C: L<<1052.0,0.0>--<1050.0,825.0>> and uni043C: L<<316.0,805.0>--<314.0,0.0>> [code: found-semi-vertical]
| 💔 ERROR | 🔥 FAIL | ⚠ WARN | 💤 SKIP | ℹ INFO | 🍞 PASS | 🔎 DEBUG |
|---|---|---|---|---|---|---|
| 0 | 37 | 39 | 419 | 29 | 247 | 0 |
| 0% | 5% | 5% | 54% | 4% | 32% | 0% |
Note: The following loglevels were omitted in this report:
Fontbakery version: 0.7.37
--- Rationale --- Dave C Lemon (Adobe Type Team) recommends setting the underline thickness to be consistent across the family. If thicknesses are not family consistent, words set on the same line which have different styles look strange. See also: https://twitter.com/typenerd1/status/690361887926697986* 🔥 **FAIL** Thickness of the underline is not the same across this family. In order to fix this, please make sure that the underlineThickness value is the same in the 'post' table of all of this family font files. Detected underlineThickness values are: Go-Mono-Bold-Italic.ttf: 100 Go-Mono-Bold.ttf: 100 Go-Mono-Italic.ttf: 50 Go-Mono.ttf: 50 [code: inconsistent-underline-thickness]
--- Rationale --- A font's filename must be composed in the following manner: <familyname>-<stylename>.ttf - Nunito-Regular.ttf, - Oswald-BoldItalic.ttf Variable fonts must list the axis tags in alphabetical order in square brackets and separated by commas: - Roboto[wdth,wght].ttf - Familyname-Italic[wght].ttf* 🔥 **FAIL** Style name used in "Go-Mono-Bold-Italic.ttf" is not canonical. You should rebuild the font using any of the following style names: "Thin", "ExtraLight", "Light", "Regular", "Medium", "SemiBold", "Bold", "ExtraBold", "Black", "Thin Italic", "ExtraLight Italic", "Light Italic", "Italic", "Medium Italic", "SemiBold Italic", "Bold Italic", "ExtraBold Italic", "Black Italic". [code: bad-static-filename]
--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.* 🔥 **FAIL** Missing required codepoints: 0x2074 (SUPERSCRIPT FOUR) [code: missing-codepoints]
--- Rationale --- Google Fonts expects variable fonts, static ttfs and static otfs to have differing OS/2 usWeightClass values. For Variable Fonts, Thin-Black must be 100-900 For static ttfs, Thin-Black can be 100-900 or 250-900 For static otfs, Thin-Black must be 250-900 If static otfs are set lower than 250, text may appear blurry in legacy Windows applications. Glyphsapp users can change the usWeightClass value of an instance by adding a 'weightClass' customParameter.* 🔥 **FAIL** OS/2 usWeightClass is '600' when it should be '400'. [code: bad-value]
--- 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 LICENSE_DESCRIPTION on platform MACINTOSH contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]
--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).* 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 2227, but got 1935 instead [code: ascent]
--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.* 🔥 **FAIL** OS/2 sTypoAscender (1579) and hhea ascent (1935) must be equal. [code: ascender]
--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845* 🔥 **FAIL** This font lacks a digital signature (DSIG table). Some applications may require one (even if only a dummy placeholder) in order to work properly. You can add a DSIG table by running the `gftools fix-dsig` script. [code: lacks-signature]
--- 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.* ⚠ **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]
--- 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]
--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.* ⚠ **WARN** ttfautohint used in font = 1.6; installed = 1.8.3; Need to re-run with the newer version! [code: old-ttfa]
--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.* ⚠ **WARN** This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: amacron Contours detected: 4 Expected: 3 Glyph name: Uogonek Contours detected: 2 Expected: 1 Glyph name: uogonek Contours detected: 2 Expected: 1 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: Uogonek Contours detected: 2 Expected: 1 Glyph name: amacron Contours detected: 4 Expected: 3 Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: uogonek Contours detected: 2 Expected: 1 [code: contour-count]
--- Rationale --- This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lower case Latin letters), cap-height, ascender and descender Y coordinates. Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * braceleft: X=404.0,Y=-1.0 (should be at baseline 0?) * paragraph: X=908.0,Y=1482.0 (should be at cap-height 1480?) * Aring: X=930.0,Y=1577.0 (should be at ascender 1579?) * atilde: X=1026.0,Y=1478.0 (should be at cap-height 1480?) * ntilde: X=1010.0,Y=1478.0 (should be at cap-height 1480?) * otilde: X=1035.0,Y=1478.0 (should be at cap-height 1480?) * itilde: X=1011.0,Y=1478.0 (should be at cap-height 1480?) * utilde: X=1013.0,Y=1478.0 (should be at cap-height 1480?) * tilde: X=1035.0,Y=1478.0 (should be at cap-height 1480?) * alphatonos: X=540.5,Y=1.0 (should be at baseline 0?) and 10 more. [code: found-misalignments]
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.* ⚠ **WARN** The following glyphs have colinear vectors: * Atilde: L<<957.0,1892.0>--<989.0,1866.0>> -> L<<989.0,1866.0>--<1000.0,1858.0>> * Atilde: L<<958.0,1657.0>--<924.0,1683.0>> -> L<<924.0,1683.0>--<901.0,1702.0>> * Itilde: L<<933.0,1683.0>--<923.0,1691.0>> -> L<<923.0,1691.0>--<916.0,1697.0>> * Itilde: L<<966.0,1892.0>--<998.0,1866.0>> -> L<<998.0,1866.0>--<1009.0,1858.0>> * Itilde: L<<967.0,1657.0>--<933.0,1683.0>> -> L<<933.0,1683.0>--<923.0,1691.0>> * Ntilde: L<<920.0,1683.0>--<910.0,1691.0>> -> L<<910.0,1691.0>--<903.0,1697.0>> * Ntilde: L<<954.0,1657.0>--<920.0,1683.0>> -> L<<920.0,1683.0>--<910.0,1691.0>> * Otilde: L<<957.0,1892.0>--<989.0,1866.0>> -> L<<989.0,1866.0>--<1000.0,1858.0>> * Psi: L<<1038.0,939.0>--<1069.0,1029.0>> -> L<<1069.0,1029.0>--<1102.0,1126.0>> * Psi: L<<580.0,1126.0>--<576.0,1029.0>> -> L<<576.0,1029.0>--<571.0,939.0>> and 58 more. [code: found-colinear-vectors]
--- Rationale --- This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.* ⚠ **WARN** The following glyphs have jaggy segments: * trademark: L<<1154.0,740.0>--<1277.0,1356.0>>/L<<1277.0,1356.0>--<1058.0,790.0>> = 9.860695262404851 and trademark: L<<965.0,790.0>--<963.0,1349.0>>/L<<963.0,1349.0>--<841.0,740.0>> = 11.533016942832205 [code: found-jaggy-segments]
--- Rationale --- A font's filename must be composed in the following manner: <familyname>-<stylename>.ttf - Nunito-Regular.ttf, - Oswald-BoldItalic.ttf Variable fonts must list the axis tags in alphabetical order in square brackets and separated by commas: - Roboto[wdth,wght].ttf - Familyname-Italic[wght].ttf* 🔥 **FAIL** Style name used in "Go-Mono-Bold.ttf" is not canonical. You should rebuild the font using any of the following style names: "Thin", "ExtraLight", "Light", "Regular", "Medium", "SemiBold", "Bold", "ExtraBold", "Black", "Thin Italic", "ExtraLight Italic", "Light Italic", "Italic", "Medium Italic", "SemiBold Italic", "Bold Italic", "ExtraBold Italic", "Black Italic". [code: bad-static-filename]
--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.* 🔥 **FAIL** Missing required codepoints: 0x2074 (SUPERSCRIPT FOUR) [code: missing-codepoints]
--- Rationale --- Google Fonts expects variable fonts, static ttfs and static otfs to have differing OS/2 usWeightClass values. For Variable Fonts, Thin-Black must be 100-900 For static ttfs, Thin-Black can be 100-900 or 250-900 For static otfs, Thin-Black must be 250-900 If static otfs are set lower than 250, text may appear blurry in legacy Windows applications. Glyphsapp users can change the usWeightClass value of an instance by adding a 'weightClass' customParameter.* 🔥 **FAIL** OS/2 usWeightClass is '600' when it should be '400'. [code: bad-value]
--- 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 LICENSE_DESCRIPTION on platform MACINTOSH contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]
--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).* 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 2227, but got 1935 instead [code: ascent]
--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.* 🔥 **FAIL** OS/2 sTypoAscender (1579) and hhea ascent (1935) must be equal. [code: ascender]
--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845* 🔥 **FAIL** This font lacks a digital signature (DSIG table). Some applications may require one (even if only a dummy placeholder) in order to work properly. You can add a DSIG table by running the `gftools fix-dsig` script. [code: lacks-signature]
--- 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.* ⚠ **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]
--- 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]
--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.* ⚠ **WARN** ttfautohint used in font = 1.6; installed = 1.8.3; Need to re-run with the newer version! [code: old-ttfa]
--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.* ⚠ **WARN** This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: Uogonek Contours detected: 2 Expected: 1 Glyph name: uogonek Contours detected: 2 Expected: 1 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: Uogonek Contours detected: 2 Expected: 1 Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: uogonek Contours detected: 2 Expected: 1 [code: contour-count]
--- Rationale --- This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lower case Latin letters), cap-height, ascender and descender Y coordinates. Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * braceleft: X=405.0,Y=-1.0 (should be at baseline 0?) * paragraph: X=612.0,Y=1482.0 (should be at cap-height 1480?) * Aring: X=615.0,Y=1577.0 (should be at ascender 1579?) * atilde: X=743.0,Y=1478.0 (should be at cap-height 1480?) * itilde: X=728.0,Y=1478.0 (should be at cap-height 1480?) * utilde: X=730.0,Y=1478.0 (should be at cap-height 1480?) * tilde: X=752.0,Y=1478.0 (should be at cap-height 1480?) * alphatonos: X=540.5,Y=1.0 (should be at baseline 0?) * alphatonos: X=300.5,Y=-1.0 (should be at baseline 0?) * alpha: X=540.5,Y=1.0 (should be at baseline 0?) and 7 more. [code: found-misalignments]
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.* ⚠ **WARN** The following glyphs have colinear vectors: * Atilde: L<<591.0,1892.0>--<629.0,1866.0>> -> L<<629.0,1866.0>--<641.0,1858.0>> * Atilde: L<<639.0,1657.0>--<600.0,1683.0>> -> L<<600.0,1683.0>--<573.0,1702.0>> * Itilde: L<<590.0,1892.0>--<628.0,1866.0>> -> L<<628.0,1866.0>--<640.0,1858.0>> * Itilde: L<<599.0,1683.0>--<588.0,1691.0>> -> L<<588.0,1691.0>--<579.0,1697.0>> * Itilde: L<<638.0,1657.0>--<599.0,1683.0>> -> L<<599.0,1683.0>--<588.0,1691.0>> * Ntilde: L<<596.0,1683.0>--<585.0,1691.0>> -> L<<585.0,1691.0>--<576.0,1697.0>> * Ntilde: L<<635.0,1657.0>--<596.0,1683.0>> -> L<<596.0,1683.0>--<585.0,1691.0>> * Otilde: L<<591.0,1892.0>--<629.0,1866.0>> -> L<<629.0,1866.0>--<641.0,1858.0>> * Psi: L<<356.0,1126.0>--<371.0,1029.0>> -> L<<371.0,1029.0>--<384.0,939.0>> * Psi: L<<851.0,939.0>--<864.0,1029.0>> -> L<<864.0,1029.0>--<878.0,1126.0>> and 55 more. [code: found-colinear-vectors]
--- Rationale --- This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.* ⚠ **WARN** The following glyphs have jaggy segments: * trademark: L<<1007.0,740.0>--<1007.0,1356.0>>/L<<1007.0,1356.0>--<901.0,790.0>> = 10.607430872774763 and trademark: L<<808.0,790.0>--<694.0,1349.0>>/L<<694.0,1349.0>--<694.0,740.0>> = 11.52658787818817 [code: found-jaggy-segments]
--- Rationale --- This check detects line segments which are nearly, but not quite, exactly horizontal or vertical. Sometimes such lines are created by design, but often they are indicative of a design error. This check is disabled for italic styles, which often contain nearly-upright lines.* ⚠ **WARN** The following glyphs have semi-vertical/semi-horizontal lines: * Lslash: L<<542.0,744.0>--<543.0,185.0>> * Lslash: L<<543.0,1308.0>--<542.0,938.0>> * arrowleft: L<<391.0,753.0>--<1145.0,754.0>> and arrowright: L<<84.0,754.0>--<838.0,753.0>> [code: found-semi-vertical]
--- Rationale --- A font's filename must be composed in the following manner: <familyname>-<stylename>.ttf - Nunito-Regular.ttf, - Oswald-BoldItalic.ttf Variable fonts must list the axis tags in alphabetical order in square brackets and separated by commas: - Roboto[wdth,wght].ttf - Familyname-Italic[wght].ttf* 🔥 **FAIL** Style name used in "Go-Mono-Italic.ttf" is not canonical. You should rebuild the font using any of the following style names: "Thin", "ExtraLight", "Light", "Regular", "Medium", "SemiBold", "Bold", "ExtraBold", "Black", "Thin Italic", "ExtraLight Italic", "Light Italic", "Italic", "Medium Italic", "SemiBold Italic", "Bold Italic", "ExtraBold Italic", "Black Italic". [code: bad-static-filename]
--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.* 🔥 **FAIL** Missing required codepoints: 0x2074 (SUPERSCRIPT FOUR) [code: missing-codepoints]
--- 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 LICENSE_DESCRIPTION on platform MACINTOSH contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]
--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).* 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 2227, but got 1935 instead [code: ascent]
--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.* 🔥 **FAIL** OS/2 sTypoAscender (1579) and hhea ascent (1935) must be equal. [code: ascender]
--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845* 🔥 **FAIL** This font lacks a digital signature (DSIG table). Some applications may require one (even if only a dummy placeholder) in order to work properly. You can add a DSIG table by running the `gftools fix-dsig` script. [code: lacks-signature]
--- 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.* ⚠ **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]
--- 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]
--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.* ⚠ **WARN** ttfautohint used in font = 1.6; installed = 1.8.3; Need to re-run with the newer version! [code: old-ttfa]
--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.* ⚠ **WARN** This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 [code: contour-count]
--- Rationale --- This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lower case Latin letters), cap-height, ascender and descender Y coordinates. Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * Q: X=788.0,Y=-2.0 (should be at baseline 0?) * g: X=688.5,Y=-396.5 (should be at descender -395?) * paragraph: X=920.0,Y=1482.0 (should be at cap-height 1480?) * germandbls: X=913.0,Y=1481.0 (should be at cap-height 1480?) * gcircumflex: X=688.5,Y=-396.5 (should be at descender -395?) * gbreve: X=688.5,Y=-396.5 (should be at descender -395?) * gdotaccent: X=688.5,Y=-396.5 (should be at descender -395?) * uni0123: X=688.5,Y=-396.5 (should be at descender -395?) * Aringacute: X=815.0,Y=1479.0 (should be at cap-height 1480?) * dieresistonos: X=497.0,Y=1478.0 (should be at cap-height 1480?) and 34 more. [code: found-misalignments]
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.* ⚠ **WARN** The following glyphs have colinear vectors: * Euro: L<<287.0,815.0>--<293.0,840.0>> -> L<<293.0,840.0>--<298.0,857.0>> * Psi: L<<1336.0,1201.0>--<1308.0,1130.0>> -> L<<1308.0,1130.0>--<1263.0,1004.0>> * Psi: L<<366.0,1004.0>--<371.0,1130.0>> -> L<<371.0,1130.0>--<371.0,1201.0>> * asciitilde: L<<729.0,728.0>--<831.0,651.0>> -> L<<831.0,651.0>--<891.0,605.0>> * asciitilde: L<<747.0,506.0>--<645.0,583.0>> -> L<<645.0,583.0>--<584.0,629.0>> * asterisk: L<<886.0,785.0>--<887.0,788.0>> -> L<<887.0,788.0>--<888.0,792.0>> * delta: L<<767.0,1169.0>--<850.0,1115.0>> -> L<<850.0,1115.0>--<945.0,1049.0>> * exclam: L<<1041.0,1480.0>--<963.0,1086.0>> -> L<<963.0,1086.0>--<800.0,459.0>> * exclam: L<<649.0,459.0>--<738.0,1086.0>> -> L<<738.0,1086.0>--<816.0,1480.0>> * exclamdbl: L<<1230.0,1480.0>--<1171.0,1184.0>> -> L<<1171.0,1184.0>--<994.0,419.0>> and 32 more. [code: found-colinear-vectors]
--- Rationale --- This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.* ⚠ **WARN** The following glyphs have jaggy segments: * Aring: B<<1085.0,1544.0>-<1019.0,1489.0>-<942.0,1480.0>>/L<<942.0,1480.0>--<1004.0,1480.0>> = 6.666659890901314 * Aring: L<<815.0,1480.0>--<877.0,1480.0>>/B<<877.0,1480.0>-<816.0,1489.0>-<776.0,1532.0>> = 8.392925187392485 and Upsilontonos: B<<863.5,1306.5>-<964.0,1133.0>-<910.0,843.0>>/B<<910.0,843.0>-<1033.0,1138.0>-<1197.0,1296.0>> = 12.085589127589483 [code: found-jaggy-segments]
--- Rationale --- A font's filename must be composed in the following manner: <familyname>-<stylename>.ttf - Nunito-Regular.ttf, - Oswald-BoldItalic.ttf Variable fonts must list the axis tags in alphabetical order in square brackets and separated by commas: - Roboto[wdth,wght].ttf - Familyname-Italic[wght].ttf* 🔥 **FAIL** Style name used in "Go-Mono.ttf" is not canonical. You should rebuild the font using any of the following style names: "Thin", "ExtraLight", "Light", "Regular", "Medium", "SemiBold", "Bold", "ExtraBold", "Black", "Thin Italic", "ExtraLight Italic", "Light Italic", "Italic", "Medium Italic", "SemiBold Italic", "Bold Italic", "ExtraBold Italic", "Black Italic". [code: bad-static-filename]
--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.* 🔥 **FAIL** Missing required codepoints: 0x2074 (SUPERSCRIPT FOUR) [code: missing-codepoints]
--- 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 LICENSE_DESCRIPTION on platform MACINTOSH contains a line-break. [code: line-break] * 🔥 **FAIL** Name entry LICENSE_DESCRIPTION on platform WINDOWS contains a line-break. [code: line-break]
--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).* 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 2227, but got 1935 instead [code: ascent]
--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.* 🔥 **FAIL** OS/2 sTypoAscender (1579) and hhea ascent (1935) must be equal. [code: ascender]
--- Rationale --- Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products. This checks verifies that this signature is available in the font. A fake signature is enough to address this issue. If needed, a dummy table can be added to the font with the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845* 🔥 **FAIL** This font lacks a digital signature (DSIG table). Some applications may require one (even if only a dummy placeholder) in order to work properly. You can add a DSIG table by running the `gftools fix-dsig` script. [code: lacks-signature]
--- 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.* ⚠ **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]
--- 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]
--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.* ⚠ **WARN** ttfautohint used in font = 1.6; installed = 1.8.3; Need to re-run with the newer version! [code: old-ttfa]
--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.* ⚠ **WARN** This check inspects the glyph outlines and detects the total number of contours in each of them. The expected values are infered from the typical ammounts of contours observed in a large collection of reference font families. The divergences listed below may simply indicate a significantly different design on some of your glyphs. On the other hand, some of these may flag actual bugs in the font such as glyphs mapped to an incorrect codepoint. Please consider reviewing the design and codepoint assignment of these to make sure they are correct. The following glyphs do not have the recommended number of contours: Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: SF190000 Contours detected: 1 Expected: 2 Glyph name: SF210000 Contours detected: 1 Expected: 2 Glyph name: SF220000 Contours detected: 1 Expected: 2 Glyph name: SF270000 Contours detected: 1 Expected: 2 Glyph name: SF280000 Contours detected: 1 Expected: 2 Glyph name: SF360000 Contours detected: 1 Expected: 2 Glyph name: SF490000 Contours detected: 1 Expected: 2 Glyph name: SF500000 Contours detected: 1 Expected: 2 Glyph name: SF510000 Contours detected: 1 Expected: 2 Glyph name: SF520000 Contours detected: 1 Expected: 2 Glyph name: asterisk Contours detected: 5 Expected: 1 or 4 Glyph name: dkshade Contours detected: 19 Expected: 73 Glyph name: ltshade Contours detected: 18 Expected: 46 Glyph name: shade Contours detected: 36 Expected: 85 [code: contour-count]
--- Rationale --- This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lower case Latin letters), cap-height, ascender and descender Y coordinates. Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.* ⚠ **WARN** The following glyphs have on-curve points which have potentially incorrect y coordinates: * Q: X=789.0,Y=-2.0 (should be at baseline 0?) * g: X=768.0,Y=-396.5 (should be at descender -395?) * paragraph: X=624.0,Y=1482.0 (should be at cap-height 1480?) * germandbls: X=618.0,Y=1481.0 (should be at cap-height 1480?) * ntilde: X=599.0,Y=1479.0 (should be at cap-height 1480?) * gcircumflex: X=768.0,Y=-396.5 (should be at descender -395?) * gbreve: X=768.0,Y=-396.5 (should be at descender -395?) * gdotaccent: X=768.0,Y=-396.5 (should be at descender -395?) * uni0123: X=768.0,Y=-396.5 (should be at descender -395?) * Aringacute: X=520.0,Y=1479.0 (should be at cap-height 1480?) and 34 more. [code: found-misalignments]
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.* ⚠ **WARN** The following glyphs have colinear vectors: * Euro: L<<125.0,815.0>--<126.0,840.0>> -> L<<126.0,840.0>--<127.0,857.0>> * Psi: L<<1097.0,1201.0>--<1083.0,1130.0>> -> L<<1083.0,1130.0>--<1063.0,1004.0>> * Psi: L<<166.0,1004.0>--<146.0,1130.0>> -> L<<146.0,1130.0>--<132.0,1201.0>> * asciitilde: L<<584.0,728.0>--<701.0,651.0>> -> L<<701.0,651.0>--<771.0,605.0>> * asciitilde: L<<646.0,506.0>--<529.0,583.0>> -> L<<529.0,583.0>--<459.0,629.0>> * asterisk: L<<730.0,785.0>--<730.0,788.0>> -> L<<730.0,788.0>--<730.0,792.0>> * delta: L<<534.0,1169.0>--<628.0,1115.0>> -> L<<628.0,1115.0>--<736.0,1049.0>> * eight: L<<499.0,990.0>--<597.0,915.0>> -> L<<597.0,915.0>--<682.0,862.0>> * exclam: L<<558.0,459.0>--<521.0,1086.0>> -> L<<521.0,1086.0>--<521.0,1480.0>> * exclam: L<<746.0,1480.0>--<746.0,1086.0>> -> L<<746.0,1086.0>--<709.0,459.0>> and 33 more. [code: found-colinear-vectors]
--- Rationale --- This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.* ⚠ **WARN** The following glyphs have jaggy segments: * Aring: B<<777.0,1544.0>-<722.0,1489.0>-<647.0,1480.0>>/L<<647.0,1480.0>--<709.0,1480.0>> = 6.842773412630916 * Aring: L<<520.0,1480.0>--<582.0,1480.0>>/B<<582.0,1480.0>-<519.0,1489.0>-<470.0,1532.0>> = 8.13010235415596 and Upsilontonos: B<<603.0,1306.5>-<738.0,1133.0>-<742.0,843.0>>/B<<742.0,843.0>-<806.0,1138.0>-<938.5,1296.0>> = 13.030817784392735 [code: found-jaggy-segments]
--- Rationale --- This check detects line segments which are nearly, but not quite, exactly horizontal or vertical. Sometimes such lines are created by design, but often they are indicative of a design error. This check is disabled for italic styles, which often contain nearly-upright lines.* ⚠ **WARN** The following glyphs have semi-vertical/semi-horizontal lines: * W: L<<557.0,1247.0>--<706.0,1248.0>> * Wacute: L<<557.0,1247.0>--<706.0,1248.0>> * Wdieresis: L<<557.0,1247.0>--<706.0,1248.0>> * Wgrave: L<<557.0,1247.0>--<706.0,1248.0>> * eng: L<<1043.0,722.0>--<1044.0,11.0>> * franc: L<<833.0,1356.0>--<329.0,1357.0>> * peseta: L<<25.0,1480.0>--<281.0,1481.0>> * uni0417: L<<136.0,1150.0>--<135.0,1459.0>> * uni043C: L<<249.0,856.0>--<243.0,123.0>> and uni0446: L<<1054.0,963.0>--<1053.0,123.0>> [code: found-semi-vertical]
| 💔 ERROR | 🔥 FAIL | ⚠ WARN | 💤 SKIP | ℹ INFO | 🍞 PASS | 🔎 DEBUG |
|---|---|---|---|---|---|---|
| 0 | 35 | 34 | 453 | 29 | 220 | 0 |
| 0% | 5% | 4% | 59% | 4% | 29% | 0% |
Note: The following loglevels were omitted in this report:
davelab6
commented
3 years ago I seem to recall this was blocked on licensing, they had MIT instead of OFL, and as you say no source provision. Your investigation is excellent to restart the conversation, I seem to recall the foundry emailed me to say they were now willing to go OFL and I didn't really respond. So I'll put you in touch with them.
davelab6
commented
3 years ago Ok I checked and, bad news, this is still blocked on licensing. So, you'll have to park this one for now. Maybe next year...
davelab6
commented
3 years ago Your review was very helpful for moving the conversation forwards with the foundry though, thank you for that!
can you add a link to the repository?