Closed eliheuer closed 4 years ago
I spent several hours reviewing and improving the rationale texts of the entire collection of checks.
I cleaned them up, fixed typos, converted a few docstrings into rationale entries, tweaked the syntax and wrote a pice of code that does the 80 column formating for us. We now store the paragraphs as long lines instead of breaking them into smaller lines manually. This will make editing the text easier and will allow the actual text-box width to be chosen per-reporter (such as ghmarkdown, text terminal, readthedocs, etc)
All the work is at https://github.com/felipesanches/fontbakery/commit/8e02c0aebdf37abee0f3b44407beb947306511b6 but I' ll probably still implement similar post-processing of the rationale entries on the other reporters as well. And at some point we will have to hook up a proper markdown parser/renderer to provide richer formating for each of these.
--- Rationale --- Tabular figures need to have the same metrics in all styles in order to allow tables to be set with proper typographic control, but to maintain the placement of decimals and numeric columns between rows. Here's a good explanation of this: https://www.typography.com/techniques/fonts-for-financials/#tabular-figs* š **PASS** OK
--- Rationale --- If the set of font files passed in the command line is not all in the same directory, then we warn the user since the tool will interpret the set of files as belonging to a single family (and it is unlikely that the user would store the files from a single family spreaded in several separate directories).* š **PASS** All files are in the same directory.
--- Rationale --- We want all fonts within a family to have the same vertical metrics so their line spacing is consistent across the family.* š **PASS** Vertical metrics are the same across the family
--- Rationale --- Per the OpenType spec: name ID 1 'is used in combination with Font Subfamily name (name ID 2), and should be shared among at most four fonts that differ only in weight or style... This four-way distinction should also be reflected in the OS/2.fsSelection field, using bits 0 and 5.* š **PASS** The OS/2.fsSelection bold & italic settings were unique within each compatible family group.
--- Rationale --- Dave C Lemon (Adobe Type Team) recommends setting the underline thickness to be consistent across the family. If thicknesses are not family consistent, words set on the same line which have different styles look strange. See also: https://twitter.com/typenerd1/status/690361887926697986* š **PASS** Fonts have consistent underline thickness.
--- Rationale --- Per the OpenType spec: 'The Font Family name ... should be shared among at most four fonts that differ only in weight or style ...'* š **PASS** There were no more than 4 fonts per family name.
--- Rationale --- The purpose of this check is to ensure that the METADATA.pb file is not malformed.* š¤ **SKIP** Font family at '/usr/share/fonts/opentype/cantarell' lacks a METADATA.pb file.
--- Rationale --- We must use commas instead of forward slashes because the server-side code at the fonts.google.com directory will segment the string on the commas into a list of names and display the first item in the list as the "principal designer" while the remaining names are identified as "contributors". See eg https://fonts.google.com/specimen/Rubik* š¤ **SKIP** Unfulfilled Conditions: family_metadata
--- Rationale --- The set of font binaries available must match exactly those declared on the METADATA.pb file. Also, to avoid confusion, we expect that font files are not placed on subdirectories.* š¤ **SKIP** Unfulfilled Conditions: family_metadata
--- Rationale --- Use of some unacceptable control characters in the U+0000 - U+001F range can lead to rendering issues on some platforms. Acceptable control characters are defined as .null (U+0000) and CR (U+000D) for this test.* š¤ **SKIP** Unfulfilled Conditions: are_ttf
--- Rationale --- There's no reasonable (and legal) way to run the command `ftxvalidator` of the Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc. If Font Bakery is not running on an OSX machine, the machine running Font Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call (rpc). There's an ssh example implementation at: https://github.com/googlefonts/fontbakery/blob/master/prebuilt/workarounds/ftxvalidator/ssh-implementation/ftxvalidator* ā **WARN** ftxvalidator is not available.
--- Rationale --- We need to check names are not already used, and today the best place to check that is http://namecheck.fontdata.com* š **ERROR** Failed to access: http://namecheck.fontdata.com. Please report this issue at: https://github.com/googlefonts/fontbakery/issues [code: namecheck-service]
--- Rationale --- If the family already exists on Google Fonts, we need to ensure that the checked family's vertical metrics are similar. This check will test the following schema which was outlined in Fontbakery issue #1162 [1]: - The family should visually have the same vertical metrics as the Regular style hosted on Google Fonts. - If the family on Google Fonts has differing hhea and typo metrics, the family being checked should use the typo metrics for both the hhea and typo entries. - If the family on Google Fonts has use typo metrics not enabled and the family being checked has it enabled, the hhea and typo metrics should use the family on Google Fonts winAscent and winDescent values. - If the upms differ, the values must be scaled so the visual appearance is the same. [1] https://github.com/googlefonts/fontbakery/issues/1162* š **ERROR** The condition
--- Rationale --- The fsType in the OS/2 table is a legacy DRM-related field. Fonts in the Google Fonts collection must have it set to zero (also known as "Installable Embedding"). This setting indicates that the fonts can be embedded in documents and permanently installed by applications on remote systems. More detailed info is available at: https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fstype* š„ **FAIL** In this font fsType is set to 8 meaning that: The font may be embedded but must only be installed temporarily on other systems. No such DRM restrictions can be enabled on the Google Fonts collection, so the fsType field must be set to zero (Installable Embedding) instead. [code: drm]
--- 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: 0x000D (CARRIAGE RETURN) [code: missing-codepoints]
--- 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 1101, but got 983 instead [code: ascent] * š„ **FAIL** OS/2.usWinDescent value should be equal or greater than 256, but got 217 instead [code: descent]
--- Rationale --- 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 (739) and hhea ascent (983) must be equal. [code: ascender]
--- Rationale --- Microsoft's recommendations for OpenType Fonts states the following: 'NOTE: The PostScript glyph name must be no longer than 31 characters, include only uppercase or lowercase English letters, European digits, the period or the underscore, i.e. from the set [A-Za-z0-9_.] and should start with a letter, except the special glyph name ".notdef" which starts with a period.' https://docs.microsoft.com/en-us/typography/opentype/spec/recom#post-table* š„ **FAIL** The following glyph names do not comply with naming conventions: brevecomb-cy, descender-cy, brevecomb-cy.case, descender-cy.case, descender-cy.strait, circumflexcomb_hookabovecomb.case, descenderreversed-cy, _bar-cy, _descender-cy.case.straight and descenderreverse-cy.case A glyph name may be up to 31 characters in length, must be entirely comprised of characters from the following set: A-Z a-z 0-9 .(period) _(underscore). and must not start with a digit or period. There are a few exceptions such as the special character ".notdef". The glyph names "twocents", "a1", and "_" are all valid, while "2cents" and ".twocents" are not. [code: found-invalid-names]
--- Rationale --- Some programs expect fonts to have a digital signature declared in their DSIG table in order to work properly. This checks verifies that such signature is available in the font. Typically, even a fake signature would be enough to make the fonts work. If needed, such dummy-placeholder can be added to the font by using the `gftools fix-dsig` script available at https://github.com/googlefonts/gftools* š„ **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 --- Even though the OpenType spec allows unitsPerEm to be any value between 16 and 16384, the Google Fonts project aims at a narrower set of reasonable values. The spec suggests usage of powers of two in order to get some performance improvements on legacy renderers, so those values are acceptable. But value of 500 or 1000 are also acceptable, with the added benefit that it makes upm math easier for designers, while the performance hit of not using a power of two is most likely negligible nowadays. Another acceptable value is 2000. Since TT outlines are all integers (no floats), then instances in a VF suffer rounding compromises, and therefore a 1000 UPM is to small because it forces too many such compromises. Therefore 2000 is a good 'new VF standard', because 2000 is a simple 2x conversion from existing fonts drawn on a 1000 UPM, and anyone who knows what 10 units can do for 1000 UPM will know what 20 units does too. Additionally, values above 2048 would result in filesize increases with not much added benefit.* ā **WARN** Even though unitsPerEm (1000) in this font is reasonable. It is strongly advised to consider changing it to 2000, since it will likely improve the quality of Variable Fonts by avoiding excessive rounding of coordinates on interpolations. [code: legacy-value]
--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering.* ā **WARN** This font lacks caret position values for ligature glyphs on its GDEF table. [code: lacks-caret-pos]
--- Rationale --- The snippet of HTML in the DESCRIPTION.en_us.html file is added to the font family webpage on the Google Fonts website. For that reason, all hyperlinks in it must be properly working.* š¤ **SKIP** Unfulfilled Conditions: description
--- Rationale --- The contents of the DESCRIPTION.en-us.html file are displayed on the Google Fonts website in the about section of each font family specimen page. Since all of the Google Fonts collection is composed of libre-licensed fonts, this check enforces a policy that there must be a hypertext link in that page directing users to the repository where the font project files are made available. Such hosting is typically done on sites like Github, Gitlab, GNU Savannah or any other git-based version control service.* š¤ **SKIP** Unfulfilled Conditions: description
--- Rationale --- Families with variable fonts do not always mention that in their descriptions. Therefore, this check ensures that a standard boilerplate sentence is present in the DESCRIPTION.en_us.html files for all those families which are available as variable fonts.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font, description
--- Rationale --- When packaging families for being pushed to the `google/fonts` git repo, if there is no DESCRIPTION.en_us.html file, some older versions of the `add_font.py` tool insert a dummy description file which contains invalid html. This file needs to either be replaced with an existing description file or edited by hand.* š¤ **SKIP** Unfulfilled Conditions: descfile
--- Rationale --- This check is merely informative, displaying and useful comparison of filesizes after ttfautohint usage versus unhinted font files.* š¤ **SKIP** Unfulfilled Conditions: is_ttf, ttfautohint_stats
--- 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.* š¤ **SKIP** Unfulfilled Conditions: is_ttf
--- Rationale --- Traditionally version 0 'gasp' tables were set so that font sizes below 8 ppem had no grid fitting but did have antialiasing. From 9-16 ppem, just grid fitting. And fonts above 17ppem had both antialiasing and grid fitting toggled on. The use of accelerated graphics cards and higher resolution screens make this approach obsolete. Microsoft's DirectWrite pushed this even further with much improved rendering built into the OS and apps. In this scenario it makes sense to simply toggle all 4 flags ON for all font sizes.* š¤ **SKIP** Unfulfilled Conditions: is_ttf
--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.* š¤ **SKIP** Unfulfilled Conditions: is_ttf
--- Rationale --- Google Fonts may serve static fonts which have been generated from variable fonts. This test will attempt to generate a static ttf using fontTool's varLib mutator. The target font will be the mean of each axis e.g: **VF font axes** - min weight, max weight = 400, 800 - min width, max width = 50, 100 **Target Instance** - weight = 600 - width = 75* š¤ **SKIP** Unfulfilled Conditions: is_variable_font
--- Rationale --- Not having a HVAR table can lead to costly text-layout operations on some platforms, which we want to avoid. So, all variable fonts on the Google Fonts collection should have an HVAR with valid values. More info on the HVAR table can be found at: https://docs.microsoft.com/en-us/typography/opentype/spec/otvaroverview#variation-data-tables-and-miscellaneous-requirements* š¤ **SKIP** Unfulfilled Conditions: is_variable_font
--- Rationale --- This setup is meant to ensure consistent rendering quality for fonts across all devices (with different rendering/hinting capabilities). Below is the snippet of instructions we expect to see in the fonts: B8 01 FF PUSHW 0x01FF 85 SCANCTRL (unconditinally turn on dropout control mode) B0 04 PUSHB 0x04 8D SCANTYPE (enable smart dropout control) "Smart dropout control" means activating rules 1, 2 and 5: Rule 1: If a pixel's center falls within the glyph outline, that pixel is turned on. Rule 2: If a contour falls exactly on a pixel's center, that pixel is turned on. Rule 5: If a scan line between two adjacent pixel centers (either vertical or horizontal) is intersected by both an on-Transition contour and an off-Transition contour and neither of the pixels was already turned on by rules 1 and 2, turn on the pixel which is closer to the midpoint between the on-Transition contour and off-Transition contour. This is "Smart" dropout control. For more detailed info (such as other rules not enabled in this snippet), please refer to the TrueType Instruction Set documentation.* š¤ **SKIP** Unfulfilled Conditions: is_ttf
--- Rationale --- The purpose of this check is to make sure that all name entries referenced by variable font instances do exist in the name table.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font
--- Rationale --- Named instances must be present in all variable fonts in order not to frustrate the users' typical expectations of a traditional static font workflow.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font
--- Rationale --- The named instances on the weight axis of a variable font must have coordinates that are multiples of 100 on the design space.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font
--- Rationale --- Hinted fonts must have head table flag bit 3 set. Per https://docs.microsoft.com/en-us/typography/opentype/spec/head, bit 3 of Head::flags decides whether PPEM should be rounded. This bit should always be set for hinted fonts. Note: Bit 3 = Force ppem to integer values for all internal scaler math; May use fractional ppem sizes if this bit is clear;* š¤ **SKIP** Unfulfilled Conditions: is_hinted
--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).* š¤ **SKIP** Unfulfilled Conditions: has_kerning_info
--- Rationale --- Depending on the typeface and coverage of a font, certain tables are recommended for optimum quality. For example, the performance of a non-linear font is improved if the VDMX, LTSH, and hdmx tables are present. Non-monospaced Latin fonts should have a kern table. A gasp table is necessary if a designer wants to influence the sizes at which grayscaling is used under Windows. A DSIG table containing a digital signature helps ensure the integrity of the font file. Etc.* š¤ **SKIP** Unfulfilled Conditions: is_ttf
--- Rationale --- Per "The CFF2 CharString Format", the "Subr nesting, stack limit" is 10.* š¤ **SKIP** Unfulfilled Conditions: is_cff2
--- Rationale --- There are various metadata in the OpenType spec to specify if a font is monospaced or not. If the font is not trully monospaced, then no monospaced metadata should be set (as sometimes they mistakenly are...) Monospace fonts must: * post.isFixedWidth "Set to 0 if the font is proportionally spaced, non-zero if the font is not proportionally spaced (monospaced)" www.microsoft.com/typography/otspec/post.htm * hhea.advanceWidthMax must be correct, meaning no glyph's width value is greater. www.microsoft.com/typography/otspec/hhea.htm * OS/2.panose.bProportion must be set to 9 (monospace). Spec says: "The PANOSE definition contains ten digits each of which currently describes up to sixteen variations. Windows uses bFamilyType, bSerifStyle and bProportion in the font mapper to determine family type. It also uses bProportion to determine if the font is monospaced." www.microsoft.com/typography/otspec/os2.htm#pan monotypecom-test.monotype.de/services/pan2 * OS/2.xAverageWidth must be set accurately. "OS/2.xAverageWidth IS used when rendering monospaced fonts, at least by Windows GDI" http://typedrawers.com/discussion/comment/15397/#Comment_15397 Also we should report an error for glyphs not of average width* š¤ **SKIP** Unfulfilled Conditions: is_ttf
--- Rationale --- The PostScript name entries in the font's 'name' table should be consistent across platforms. This is the TTF/CFF2 equivalent of the CFF 'postscript_name_cff_vs_name' check.* š¤ **SKIP** Unfulfilled Conditions: not is_cff
--- Rationale --- According to the Open-Type spec's registered design-variation tag 'wght' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wght If a variable font has a 'wght' (Weight) axis, then the coordinate of its 'Regular' instance is required to be 400.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font, regular_wght_coord
--- Rationale --- According to the Open-Type spec's registered design-variation tag 'wdth' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wdth If a variable font has a 'wdth' (Width) axis, then the coordinate of its 'Regular' instance is required to be 100.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font, regular_wdth_coord
--- Rationale --- According to the Open-Type spec's registered design-variation tag 'slnt' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_slnt If a variable font has a 'slnt' (Slant) axis, then the coordinate of its 'Regular' instance is required to be zero.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font, regular_slnt_coord
--- Rationale --- According to the Open-Type spec's registered design-variation tag 'ital' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_ital If a variable font has a 'ital' (Italic) axis, then the coordinate of its 'Regular' instance is required to be zero.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font, regular_ital_coord
--- Rationale --- According to the Open-Type spec's registered design-variation tag 'opsz' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_opsz If a variable font has a 'opsz' (Optical Size) axis, then the coordinate of its 'Regular' instance is recommended to be a value in the range 9 to 13.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font, regular_opsz_coord
--- Rationale --- The Open-Type spec's registered design-variation tag 'wght' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wght does not specify a required value for the 'Bold' instance of a variable font. But Dave Crossland suggested that we should enforce a required value of 700 in this case.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font, bold_wght_coord
--- Rationale --- According to the Open-Type spec's registered design-variation tag 'wght' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wght On the 'wght' (Weight) axis, the valid coordinate range is 1-1000.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font
--- Rationale --- According to the Open-Type spec's registered design-variation tag 'wdth' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wdth On the 'wdth' (Width) axis, the valid coordinate range is 1-1000* š¤ **SKIP** Unfulfilled Conditions: is_variable_font
--- Rationale --- The OpenType spec says at https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_slnt that: [...] the scale for the Slant axis is interpreted as the angle of slant in counter-clockwise degrees from upright. This means that a typical, right-leaning oblique design will have a negative slant value. This matches the scale used for the italicAngle field in the post table.* š¤ **SKIP** Unfulfilled Conditions: is_variable_font, slnt_axis
--- Rationale --- The EPAR table is/was a way of expressing common licensing permissions and restrictions in metadata; while almost nothing supported it, Dave Crossland wonders that adding it to everything in Google Fonts could help make it more popular. More info is available at: https://davelab6.github.io/epar/* ā¹ **INFO** EPAR table not present in font. To learn more see https://github.com/googlefonts/fontbakery/issues/818 [code: lacks-EPAR]
--- Rationale --- The git sha1 tagging and dev/release features of Source Foundry `font-v` tool are awesome and we would love to consider upstreaming the approach into fontmake someday. For now we only emit a WARN if a given font does not yet follow the experimental versioning style, but at some point we may start enforcing it.* ā¹ **INFO** Version string is: "Version 0.111" The version string must ideally include a git commit hash and either a "dev" or a "release" suffix such as in the example below: "Version 1.3; git-0d08353-release" [code: bad-format]
--- 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* š **PASS** /usr/share/fonts/opentype/cantarell/Cantarell-Regular.otf is named canonically.
--- Rationale --- An old FontLab version had a bug which caused it to store copyright notices in nameID 10 entries. In order to detect those and distinguish them from actual legitimate usage of this name table entry, we expect that such strings do not exceed a reasonable length of 200 chars. Longer strings are likely instances of the FontLab bug.* š **PASS** All description name records have reasonably small lengths.
--- Rationale --- Font family names which start with a numeral are often not discoverable in Windows applications.* š **PASS** Font family name first character is not a digit.
--- Rationale --- The OpenType spec requires ASCII for the POSTSCRIPT_NAME (nameID 6). For COPYRIGHT_NOTICE (nameID 0) ASCII is required because that string should be the same in CFF fonts which also have this requirement in the OpenType spec. Note: A common place where we find non-ASCII strings is on name table entries with NameID > 18, which are expressly for localising the ASCII-only IDs into Hindi / Arabic / etc.* š **PASS** None of the ASCII-only NAME table entries contain non-ASCII characteres.
--- 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* š **PASS** Value of post.italicAngle is 0.0 with style="Regular".
--- 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.* š **PASS** head macStyle ITALIC bit is properly set. * š **PASS** head macStyle BOLD bit is properly set.
--- Rationale --- Checks that the family name infered from the font filename matches the string at nameID 1 (NAMEID_FONT_FAMILY_NAME) if it conforms to RIBBI and otherwise checks that nameID 1 is the family name + the style name.* š **PASS** FONT_FAMILY_NAME entries are all good. [code: ok]
--- Rationale --- This is an arbitrary max lentgh for the copyright notice field of the name table. We simply don't want such notices to be too long. Typically such notices are actually much shorter than this with a lenghth of roughtly 70 or 80 characters.* š **PASS** All copyright notice name entries on the 'name' table are shorter than 500 characters.
--- Rationale --- The goal here is to reduce filesizes and improve pageloading when dealing with webfonts. The VTT Talk sources are not necessary at runtime and endup being just dead weight when left embedded in the font binaries. The sources should be kept on the project files but stripped out when building release binaries.* š **PASS** There are no tables with VTT Talk sources embedded in the font.
--- Rationale --- Apple's TrueType reference manual [1] describes SFNT tables not in the Microsoft OpenType specification [2] and these can sometimes sneak into final release files, but Google Fonts should only have OpenType tables. [1] https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html [2] https://docs.microsoft.com/en-us/typography/opentype/spec/* š **PASS** There are no unwanted AAT tables.
--- Rationale --- According to a GlyphsApp tutorial [1], in order to make sure all versions of Windows recognize it as a valid font file, we must make sure that the concatenated length of the familyname (NameID.FONT_FAMILY_NAME) and style (NameID.FONT_SUBFAMILY_NAME) strings in the name table do not exceed 20 characters. After discussing the problem in more detail at `FontBakery issue #2179 [2] we decided that allowing up to 27 chars would still be on the safe side, though. [1] https://glyphsapp.com/tutorials/multiple-masters-part-3-setting-up-instances [2] https://github.com/googlefonts/fontbakery/issues/2179* š **PASS** All name entries are good.
--- Rationale --- The OpenType specification v1.8.2 recommends that the first glyph is the .notdef glyph without a codepoint assigned and with a drawing. https://docs.microsoft.com/en-us/typography/opentype/spec/recom#glyph-0-the-notdef-glyph Pre-v1.8, it was recommended that a font should also contain a .null, CR and space glyph. This might have been relevant for applications on MacOS 9.* š **PASS** Font contains the .notdef glyph as the first glyph, it does not have a Unicode value assigned and contains a drawing.
--- Rationale --- Some font editors store source data in their own SFNT tables, and these can sometimes sneak into final release files, which should only have OpenType spec tables.* š **PASS** There are no unwanted tables.
--- Rationale --- Duplicate glyph names prevent font installation on Mac OS X.* š **PASS** Font contains unique glyph names.
--- Rationale --- Per "The Type 2 Charstring Format, Technical Note #5177", the "Subr nesting, stack limit" is 10.* š **PASS** Maximum call depth not exceeded.
--- Rationale --- According to the OpenType spec: The value of unitsPerEm at the head table must be a value between 16 and 16384. Any value in this range is valid. In fonts that have TrueType outlines, a power of 2 is recommended as this allows performance optimizations in some rasterizers. But 1000 is a commonly used value. And 2000 may become increasingly more common on Variable Fonts.* š **PASS** The unitsPerEm value (1000) on the 'head' table is reasonable.
--- Rationale --- The bold and italic bits in OS/2.fsSelection must match the bold and italic bits in head.macStyle per the OpenType spec.* š **PASS** The OS/2.fsSelection and head.macStyle bold and italic settings match.
--- Rationale --- At least some programs (such as Word and Sublime Text) under Windows 7 do not recognize fonts unless code page bits are properly set on the ulCodePageRange1 (and/or ulCodePageRange2) fields of the OS/2 table. More specifically, the fonts are selectable in the font menu, but whichever Windows API these applications use considers them unsuitable for any character set, so anything set in these fonts is rendered with a fallback font of Arial. This check currently does not identify which code pages should be set. Auto-detecting coverage is not trivial since the OpenType specification leaves the interpretation of whether a given code page is "functional" or not open to the font developer to decide. So here we simply detect as a FAIL when a given font has no code page declared at all.* š **PASS** At least one code page is defined.
--- Rationale --- Check the name table for empty records, as this can cause problems in Adobe apps.* š **PASS** No empty name table records found.
--- Rationale --- The PostScript name entries in the font's 'name' table should match the FontName string in the 'CFF ' table. The 'CFF ' table has a lot of information that is duplicated in other tables. This information should be consistent across tables, because there's no guarantee which table an app will get the data from.* š **PASS** Name table PostScript name matches CFF table FontName.
--- Rationale --- Even though, all fonts should have their kerning implemented in the GPOS table, there may be kerning info at the kern table as well. Some applications such as MS PowerPoint require kerning info on the kern table. More specifically, they require a format 0 kern subtable from a kern table version 0, which is the only one that Windows understands (and which is also the simplest and more limited of all the kern subtables). Google Fonts ingests fonts made for download and use as desktops, and does all web font optimizations in the serving pipeline (using libre libraries that anyone can replicate.) Ideally, TTFs intended for desktop users (and thus the ones intended for Google Fonts) should have both KERN and GPOS tables. Given all of the above, we currently treat kerning on a v0 kern table as a good-to-have (but optional) feature.* š **PASS** Font does not declare an optional "kern" table.
Awesome work! The monospace rationale in the markdown looks great IMO.
This also seems like a big improvement to me:
tweaked the syntax and wrote a pice of code that does the 80 column formating for us. We now store the paragraphs as long lines instead of breaking them into smaller lines manually.
here' s what we got on the terminal output now:
I hope you like it ;-)
Observed behaviour
While using the command-line interface the rationales appear to be formatted in an inconsistent and arbitrary way. See the screenshot below for an example.
Expected behaviour
The rationales should all align with the preceding purple doc string and be prefaced with an indicator explaining what the text is. For example:
Ideally the
Check Rationale:
preface would be in a color that sets it apart from the rest of the rationale text, like the green used forPASS
.Finally, the line length of the rationale text should be consistent, note that it isn't in the above screenshot. I suggest keeping all the rationale text as close to 80 character wide as possible.
Resources and exact process needed to replicate
Use Fontbakery from the
b138b9e6
commit onward.