v3.000 mastering

[m4rc1e]

This PR adds the following:

• Build instructions

• Almost automated builds Users still need to run 2 post processing scripts in glyphs. However, there's now a build.sh file which does all the font binary post processing.

• STAT tables Stat tables are automatically added using Dama's statmake. This means the fonts should work correctly in dtp apps (MS Office may not support STAT v1.2 yet). The stat table file isn't hardcoded. It gets generated from a python script. This means we can add more instances without needing to manually update it.

• Metadata complies with the GF spec. Cupcakes all round when running the font through fontbakery

  

• Fonts have been unhinted Due to #41, it may be best we release this family unhinted.

@raphlinus I'll gen some diffs now and see if the hinting looks better.

[m4rc1e]

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](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#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.

[5] Inconsolata[wdth,wght].ttf

⚠ WARN: Stricter unitsPerEm criteria for Google Fonts.

* [com.google.fonts/check/unitsperem_strict](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#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: Font contains .notdef as first glyph?

* [com.google.fonts/check/mandatory_glyphs](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#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: Checking correctness of monospaced metadata.

* [com.google.fonts/check/monospace](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/name.html#com.google.fonts/check/monospace)

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

* ⚠ **WARN** Font is monospaced but 57 glyphs (5.9128630705394185%) have a different width. You should check the widths of: ['hyphen_greater.dlig', 'exclam_equal_equal.dlig', 'equal_equal_equal.dlig', 'equal_greater.dlig', 'greater_equal.dlig', 'less_hyphen.dlig', 'less_equal.dlig', 'uni0308', 'uni0307', 'gravecomb', 'acutecomb', 'uni030B', 'uni030C.alt', 'uni0302', 'uni030C', 'uni0306', 'uni030A', 'tildecomb', 'uni0304', 'hookabovecomb', 'uni030F', 'uni0311', 'uni0312', 'uni031B', 'dotbelowcomb', 'uni0324', 'uni0326', 'uni0327', 'uni0328', 'uni032E', 'uni0331', 'uni0335', 'uni0336', 'uni0308.case', 'uni0307.case', 'gravecomb.case', 'acutecomb.case', 'uni030B.case', 'uni0302.case', 'uni030C.case', 'uni0306.case', 'uni030A.case', 'tildecomb.case', 'uni031B.case', 'tildecomb.i', 'uni03060301', 'uni03060300', 'uni03060309', 'uni03060303', 'uni03020301', 'uni03020300', 'uni03020309', 'uni03020303', 'uni03020301.case', 'uni03020300.case', 'uni03020309.case', 'uni03020303.case'] [code: mono-outliers]

⚠ WARN: Monospace font has hhea.advanceWidthMax equal to each glyph's advanceWidth?

* [com.google.fonts/check/monospace_max_advancewidth](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/hhea.html#com.google.fonts/check/monospace_max_advancewidth) * ⚠ **WARN** This seems to be a monospaced font, so advanceWidth value should be the same across all glyphs, but 99.59% of them have a different value: A, Aacute, Abreve, uni1EAE, uni1EB6, uni1EB0, uni1EB2, uni1EB4, Acircumflex, uni1EA4 and 950 more. [code: should-be-monospaced] * ⚠ **WARN** Double-width and/or zero-width glyphs were detected. These glyphs should be set to the same width as all others and then add GPOS single pos lookups that zeros/doubles the widths as needed: uni0308, uni0307, gravecomb, acutecomb, uni030B, uni030C.alt, uni0302, uni030C, uni0306, uni030A and 40 more. [code: variable-monospaced]

⚠ WARN: Does GPOS table have kerning information?

* [com.google.fonts/check/gpos_kerning_info](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/gpos.html#com.google.fonts/check/gpos_kerning_info) * ⚠ **WARN** GPOS table lacks kerning information. [code: lacks-kern-info]

Summary

💔 ERROR	🔥 FAIL	⚠ WARN	💤 SKIP	ℹ INFO	🍞 PASS	🔎 DEBUG
0	0	6	75	7	73	0
0%	0%	4%	47%	4%	45%	0%

Note: The following loglevels were omitted in this report:

• SKIP
• INFO
• PASS
• DEBUG

Diff images: inconsolata_qa1.zip

[m4rc1e]

@raphlinus Family looks better unhinted imo

Win 10 Chrome 69

OS X Safari 11

The pixel snapping we encountered in #41 doesn't seem to be present when the fonts are unhinted.

Only concern of mine seems to be the fi and fl ligs may have been removed.

[raphlinus]

One problem I'm seeing is that the version is still 3.000, and I think it should be 3.001.

Regarding the fi and fl ligatures, those are intentionally absent. In fact, I consider single width fi and fl ligatures in a monospace font to be a serious bug, as it breaks alignment. You can make an argument for U+FB01 and U+FB02 for compatibility, but I haven't seen a strong need for these.

Continuing to look over the rest of the PR.

[raphlinus]

I'm struggling to understand the hinting situation. I believe the individual instance files should be hinted, as unhinted rendering on Windows is expected to be poor. In fact, I just tested on my Windows 7 lo-dpi laptop, and I consider this a significant regression from v2, and from 3.000, which also has very good hinting.

I'm still trying to figure out the quality situation with the vf on Windows. I'm pretty sure it's a quality regression from the static instances in any case. In this PR, it looks unhinted both on my high-spec Windows 10 machine and the Win7 junker. (The 3.000 release looks unhinted on the former, but autohinted with snap-to-pixel behavior on the latter). This feels very much like a quality bug in Chrome. I believe the best behavior would be "light autohinting" on all Windows machines. My offer to raise a bug with Chromium still stands; in the current state, I would not feel comfortable shipping variable fonts to Chrome/Windows users (at least if intended to be used at text sizes, which Inconsolata certainly is).

[m4rc1e]

My offer to raise a bug with Chromium still stands; in the current state, I would not feel comfortable shipping variable fonts to Chrome/Windows users

Np. Let's keep this open until we fix the rendering. If you could file a bug, that would be most helpful.

[davelab6]

I'll see if we can get Mike Duggan to take a look

[dberlow]

Looks like we can help.

Will examine today, discuss with Mike and reply tomorrow.

[mikedug]

hi

enclosed is a very basic autohinted version, with (minor touchup) of Inconsolata VF font. Please only use for basic rendering testing of mostly the Regular font. if this more or less performs how you might expect, we can chat about moving forward with a more finished version of the font.

thanks mike Inconsolata-VF.zip

[m4rc1e]

Attached is a collection of img diffs which compare your vtt against the fonts we serve on Google Fonts. I've also attached img diffs which have used ttfautohint-vf.

Both have issues:

In the VTT font, we have many cap height and x-height jumps.

We've tried using vtt in the past to counteract these jumps but we've had little success. If you're able to do another round and get a closer match I'd be impressed.

In the TTFA font, we have accent collisions but there are no jumps.

If our aim is to "match" the fonts we currently serve, I think the TTFA results are better. However, I prefer the rendering from vtt. I still believe it doesn't justify the effort.

inconsolata_hinting_qa.zip

[mikedug]

thanks for testing Marc. I did not do any adjustments, to ensure no jumps, but that is pretty straightforward. I can send an updated test font, over the next day or two, that should solve that issue.

[dberlow]

I'd also like to add the observation in the rendering above, that there is an inconsistency between the size and overshoot of the apex of the A, and size and undershoot of the nadir of the V that proves difficult to hint/rasterize, and could better be rendered with more consistency.

[m4rc1e]

Thanks!

Feel free to use this site to compare your vtt efforts against the fonts we host on Google Fonts. It may take a few seconds to upload.

If we're going to hint match, it may make more sense to test on Firefox instead of Chrome. If we attempt it on Chrome it won't work because Chrome uses DW for statics and FreeType for VFs so we'll just end up fighting the rasterisers. I think Firefox uses DW for both statics and VFs (someone needs to check this) so it should work better. One day Chrome may also use DW on Win.

Looking forward to seeing what you come up with. I'm away from this evening till Tuesday. I can review updates next Wednesday.

[raphlinus]

I gave Michael's test font a spin on my Windows 7 and Windows 10 boxes. It's pretty good on both, taking into account the various criticisms that have already been expressed. Certainly, the grid snapping of vertical strokes is resolved, and stroke contrast is decent. That said, there's still a quantization of widths to integer pixels on Windows 7, which is a step down from the quality of the static instances. My gut feeling is that this something that will have to be fixed on the Chrome side, and there's probably no setting we can do on the font that will give nice fractional widths on that platform.

I would feel comfortable going forward with development along those lines.

[mikedug]

Hi Marc, Raph

this font should now have 100% match for heights to the shipping Inconsolata Regular, from 9 - 24ppem (Cap, x-height, Ascender, Descender, and figure heights)

there may still be some slight differences in the rounding of mid bars such as on HEF, etc. If this was also required to match 100%, that is also doable in the full hinting task.

I also completed another round of hinting, with fine tuning for Cap A-Z, Lowercase a-z, Figures 0-9, and some accent hinting. Any issues beyond those glyphs, would be addressed in the full hinting task, so please just review these base glyphs. I will write up some additional notes on a few issues I think could be changed in the main font, to make the hinting easier and to achieve better results on screen. (e.g, i and j are made as composites in the font. Because of the way composite hinting and rounding works, it would be better for hinting to have these glyphs made as uniques)

Marc please review, and let me know if this is closer now to what is expected of a matching font. thanks Inconsolata-VF.zip

Mike

[mikedug]

hi Marc I used the diff browser tool, and noticed one height difference. please use this updated file for testing, from 9-24ppem, or 7 - 18 point @ 96dpi (for testing purposes in this font please only look at Cap 'A' through 'Z', Lowercase 'a' through 'z' Figure 0 through 9)

You might note a difference in the cap Q. The hinting in the static font is strange, the baseline undershoot is below the baseline by one pixel at a few sizes, which seems incorrect. I have not replicated this behavior. Otherwise in this file the heights should be the same as the shipping Inconsolata Regular font.

thanks Mike reviseInconsolata-VF.zip

[m4rc1e]

Thanks Mike.

Can confirm the Regular is jump free on Chrome. FireFox 63+ still has jumps at 19 and 20.

I know we're only testing the Regular instance at the moment but I'm curious if the jumps can be eliminated in the Bold? The Bold doesn't have a master within the font, it's only an instance.

[mikedug]

thanks for testing Marc. The way the hinting is set up, is that the heights will be the same for Regular and Bold, so as long as they were the same in the shipping fonts, (ie regular v bold), then the heights should match for the shipping Bold also in the VF font. I only matched the heights until 24ppem, but that could be done for a higher range of sizes if that is required.

[dberlow]

Mark,

Great question on matching instances. Bold doesn't have a master within the font, but it's instance can be changed with additional instructions in the font program that "deltas" the lowercase height at the required ppm size and at a specific design space location, (using "get var").

So, we are dedicated to investigation and proof we can do it, but I suggest that making them compatible with the hinted legacy fonts will open up additional compatibility issues. The instruction capabilities we have are for deltas to instances at ppm values, which is no problem.

But I'm not sure how we would change the values of the surrounding instances. i.e. if we delta the lowercase of wght700, wdth100, ppm 24, plus one pixel height, then we should delta the lowercase of wght700, and all of the wdth axis at ppm 24, plus one pixel height too.

And, there is more design space to consider in the what range of weights immediately above and below bold, again at 24 ppm, could also need to be delta hinted plus 1 lowercase height.

This issue would repeat for each delta we add for height adjustments beyond the ppm space alone and into combinations of ppm and design space.

Our investigation should lay all of this out.

Best regards, David

[mikedug]

Thanks David. In the shipping Inconsolata fonts, when comparing Regular v Bold, there are differences in Rounded Heights, (see markup in red). So to match that, if that was required, we will need the Get Var and delta, as David commented. Mike

[mikedug]

this screenshot is from Word 2019, running on Windows 10. I also see the same issue, differences in the Heights of Inconsolata Regular v Bold, when I preview in Chrome at https://fonts.google.com/specimen/Inconsolata

[m4rc1e]

Thanks Mike. I hadn't realised our existing Bold and Regular fonts don't share the same vertical alignments. I also made quick test case and can confirm your findings.

It's probably a better idea to ensure that all instances have the same vertical alignment zones. I know this may cause regressions but I feel this is an improvement over what we currently serve. I take back my original stance of trying to match every instance 100%. Perhaps we should ensure the Regular is jump free and the other instances should share the same vertical alignment zones as the Regular?

For the time being, I don't mind us using VTT for the following families: Open Sans Roboto Montserrat Raleway Inconsolata

Due to their popularity, it's worth the extra effort imo.

We're anxious to release Raleway and Montserrat this quarter so this vtt approach may be the only way we can do this atm. I still don't believe we should use it for all the families we serve. It is too laborious and it means we'll need virtual machines.

@raphlinus I'll take a look at the Win 7 Chrome quantization issue. I'll see if there's a work around or see if we can get the settings changed. Another option is disabling variable fonts for Win 7 Chrome but this should be a last resort.

Open to any concerns/suggestions.

[mikedug]

thanks Marc, that is good. Making the Regular and the other instances share the same vertical alignment zones will work fine, if that is what is required.

[m4rc1e]

I've added Mike's hinting from #48 and I've also improved the stat table.

@raphlinus shall I bump the version to v3.001 and regenerate the fonts? Once this is done we should be good.

[raphlinus]

@m4rc1e Sounds good to me, thanks!

[m4rc1e]

Thanks @raphlinus.

I'm able to rebuild the fonts by following the readme. I'm happy for this pr to be merged.

It would be great one day to make this project a fully automated build.

[davelab6]

@raphlinus OK to merge? :)

[raphlinus]

@raphlinus OK to merge? :)

Lemme give it a quick spin, then I think so.

[m4rc1e]

@davelab6 are you able to merge this?

[m4rc1e]

Thanks Raph!

Inconsolata VF has been live on Google Fonts since Monday :-). Touch wood, no issues reported yet.

I guess the Condensed axis will be available sometime this year.

[raphlinus]

Great news!