josefinsans: v2.000 added.

[m4rc1e]

Taken from the upstream repo https://github.com/googlefonts/josefinsans at commit googlefonts/josefinsans@132fdfd

[gf-bot]

Fontbakery report

Fontbakery version: 0.7.15

[1] Family checks

⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available?

• com.google.fonts/check/ftxvalidator_is_available

--- 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.

[11] JosefinSans-Italic[wght].ttf

🔥 FAIL: Checking OS/2 usWeightClass matches weight specified at METADATA.pb.

• com.google.fonts/check/metadata/os2_weightclass

• 🔥 FAIL OS/2 usWeightClass (100:"bad Google Fonts API weight value") does not match weight specified at METADATA.pb (400:"Regular"). [code: mismatch]

🔥 FAIL: METADATA.pb weight matches postScriptName.

• com.google.fonts/check/metadata/match_weight_postscript

• 🔥 FAIL METADATA.pb: Mismatch between postScriptName ("JosefinSans-ThinItalic") and weight value (400). The name must be ended with "Regular" or "Italic".

⚠ WARN: Checking OS/2 achVendID.

• com.google.fonts/check/vendor_id

• ⚠ WARN OS/2 VendorID value 'NONE' is not a known registered id. You should set it to your own 4 character code, and register that code with Microsoft at https://www.microsoft.com/typography/links/vendorlist.aspx [code: unknown]

⚠ WARN: Checking OS/2 usWeightClass.

• com.google.fonts/check/usweightclass

• ⚠ WARN Thin Italic:100 is OK on TTFs, but OTF files with those values will cause bluring on Windows. GlyphsApp users must set an Instance Custom Parameter for the Thin and ExtraLight styles to 250 and 275, so that if OTFs are exported then it will not blur on Windows. [code: blur-on-windows]

⚠ WARN: METADATA.pb: Fontfamily is listed on Google Fonts API?

• com.google.fonts/check/metadata/listed_on_gfonts

• ⚠ WARN Family not found via Google Fonts API. [code: not-found]

⚠ WARN: Copyright notice on METADATA.pb should not contain 'Reserved Font Name'.

• com.google.fonts/check/metadata/reserved_font_name

• ⚠ WARN METADATA.pb: copyright field ("Copyright 2010 The Josefin Sans Project Authors (https://github.com/ThomasJockin/JosefinSansFont-master), with Reserved Font Name "Josefin Sans".") contains "Reserved Font Name". This is an error except in a few specific rare cases. [code: rfn]

⚠ WARN: Stricter unitsPerEm criteria for Google Fonts.

• com.google.fonts/check/unitsperem_strict

--- 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]

⚠ WARN: Are there caret positions declared for every ligature?

• com.google.fonts/check/ligature_carets

--- 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]

⚠ WARN: Is there kerning info for non-ligated sequences?

• com.google.fonts/check/kerning_for_non_ligated_sequences

--- 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).

• ⚠ WARN GPOS table lacks kerning info for the following non-ligated sequences:

  • f + i
  • i + l

  [code: lacks-kern-info]

⚠ WARN: Font contains .notdef as first glyph?

• com.google.fonts/check/mandatory_glyphs

--- 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.

• ⚠ WARN Font should contain the .notdef glyph as the first glyph, it should not have a Unicode value assigned and should contain a drawing.

⚠ WARN: Name table strings must not contain the string 'Reserved Font Name'.

• com.google.fonts/check/name/rfn

• ⚠ WARN Name table entry ("Copyright 2010 The Josefin Sans Project Authors (https://github.com/ThomasJockin/JosefinSansFont-master), with Reserved Font Name "Josefin Sans".") contains "Reserved Font Name". This is an error except in a few specific rare cases. [code: rfn]

[11] JosefinSans[wght].ttf

🔥 FAIL: Checking OS/2 usWeightClass matches weight specified at METADATA.pb.

• com.google.fonts/check/metadata/os2_weightclass

• 🔥 FAIL OS/2 usWeightClass (100:"bad Google Fonts API weight value") does not match weight specified at METADATA.pb (400:"Regular"). [code: mismatch]

🔥 FAIL: METADATA.pb weight matches postScriptName.

• com.google.fonts/check/metadata/match_weight_postscript

• 🔥 FAIL METADATA.pb: Mismatch between postScriptName ("JosefinSans-Thin") and weight value (400). The name must be ended with "Regular" or "Italic".

⚠ WARN: Checking OS/2 achVendID.

• com.google.fonts/check/vendor_id

• ⚠ WARN OS/2 VendorID value 'NONE' is not a known registered id. You should set it to your own 4 character code, and register that code with Microsoft at https://www.microsoft.com/typography/links/vendorlist.aspx [code: unknown]

⚠ WARN: Checking OS/2 usWeightClass.

• com.google.fonts/check/usweightclass

• ⚠ WARN Thin:100 is OK on TTFs, but OTF files with those values will cause bluring on Windows. GlyphsApp users must set an Instance Custom Parameter for the Thin and ExtraLight styles to 250 and 275, so that if OTFs are exported then it will not blur on Windows. [code: blur-on-windows]

⚠ WARN: METADATA.pb: Fontfamily is listed on Google Fonts API?

• com.google.fonts/check/metadata/listed_on_gfonts

• ⚠ WARN Family not found via Google Fonts API. [code: not-found]

⚠ WARN: Copyright notice on METADATA.pb should not contain 'Reserved Font Name'.

• com.google.fonts/check/metadata/reserved_font_name

• ⚠ WARN METADATA.pb: copyright field ("Copyright 2010 The Josefin Sans Project Authors (https://github.com/ThomasJockin/JosefinSansFont-master), with Reserved Font Name "Josefin Sans".") contains "Reserved Font Name". This is an error except in a few specific rare cases. [code: rfn]

⚠ WARN: Stricter unitsPerEm criteria for Google Fonts.

• com.google.fonts/check/unitsperem_strict

--- 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]

⚠ WARN: Are there caret positions declared for every ligature?

• com.google.fonts/check/ligature_carets

--- 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]

⚠ WARN: Is there kerning info for non-ligated sequences?

• com.google.fonts/check/kerning_for_non_ligated_sequences

--- 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).

• ⚠ WARN GPOS table lacks kerning info for the following non-ligated sequences:

  • f + f
  • f + i
  • i + f
  • f + l
  • l + f
  • i + l

  [code: lacks-kern-info]

⚠ WARN: Font contains .notdef as first glyph?

• com.google.fonts/check/mandatory_glyphs

--- 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.

• ⚠ WARN Font should contain the .notdef glyph as the first glyph, it should not have a Unicode value assigned and should contain a drawing.

⚠ WARN: Name table strings must not contain the string 'Reserved Font Name'.

• com.google.fonts/check/name/rfn

• ⚠ WARN Name table entry ("Copyright 2010 The Josefin Sans Project Authors (https://github.com/ThomasJockin/JosefinSansFont-master), with Reserved Font Name "Josefin Sans".") contains "Reserved Font Name". This is an error except in a few specific rare cases. [code: rfn]

Summary

💔 ERROR	🔥 FAIL	⚠ WARN	💤 SKIP	ℹ INFO	🍞 PASS	🔎 DEBUG
0	4	19	67	16	187	0
0%	1%	6%	23%	5%	64%	0%

Note: The following loglevels were omitted in this report:

• SKIP
• INFO
• PASS
• DEBUG

Diff images: qa.zip

[thlinard]

@m4rc1e : JosefinSans-Italic.ttf and JosefinSans-SemiBoldItalic.ttf are missing in the static files.

[m4rc1e]

Thanks, I'll push an update once I've seen why all the statics are not generating.

[m4rc1e]

Issue posted upstream, I'll see what they say,

[davelab6]

Thanks @m4rc1e - took a quick look at the qa.zip images, and

qa/Diffbrowsers/LightItalic_Regular_SemiBold_SemiBoldItalic/waterfall/before/Desktop_Windows_10_firefox_62.0_.jpg
qa/Diffbrowsers/LightItalic_Regular_SemiBold_SemiBoldItalic/waterfall/after/Desktop_Windows_10_firefox_62.0_.jpg

look like there are changes to v metrics apparent on Windows due what I guess is a switch from ttfautohinit to non-hinting - but the changes make the resulting pixel rendering truer to the design, and more even both in x height across glyphs, and stem thicknesses, so I approve this PR as a "C" grade change, "Shapes & metrics change but not in a way anticipated to cause major issues (e.g. not significantly wider)" :)