Inconsolata v3.000 vs Google Fonts version

[m4rc1e]

Congrats @raphlinus, it looks great!

I've just diffed the fonts against the version we currently serve on Google. Here are some areas that could be improved before we push it to prod.

Rendering

The rendering diffs for OS X are the most minimal I've ever seen.

Safari 11

On Win Chrome, the word "BOLD" and metrics seem a little worse than the GF version.

Win 10 Chrome 69

I need to work out whether this is just FreeType or some settings in the font.

Font metadata

Remove the spaces in the width names. We currently have "Ultra Condensed ExtraLight" when we'd like "UltraCondensed ExtraLight"

Change the ExtraLight wght axis values to 200. This can be done by dropping the weightClass customParameter in each instance. I apologise if our tests seem conflicting on this issue. For static fonts we previous wanted 275 but we're happily accepting 200 now for ttfs.

Add a panose and set the bProportion so it's a monospace font. Without setting this, if users type a glyph which isn't in the font, they may get a fallback glyph from a proportional font.

Rename the filename to Inconsolata[wdth,wght].ttf. All our VFs are named in such a manner.

Add a dsig so the font will work correctly in older version of MS Office apps, https://github.com/googlefonts/fontmake/issues/431

I can happily make these changes for you next week if you'd like?

[m4rc1e]

AFAIK Google Fonts doesn't support multi axes VF atm. I'd like this to be our first one :-)

[raphlinus]

Thanks for the feedback. I'm curious and surprised to see such changes in the Chrome rendering (especially of bold). The hints are all generated by ttfautohint, using the default settings. My understanding is that it should be applying a very light touch with horizontal displacements, but from your comparison images this is clearly not so. I want to understand this so will dig into it; I have some interest and experience in font rendering :)

I'm happy for you to make the metadata/naming/signature changes, as you have a much clearer picture what the requirements are.

I'm also looking forward to Inconsolata being the first multi-axis Google Fonts VF. My understanding is that you'll likely push a weight-only axis first, then two-axis when the platform is ready.

[raphlinus]

I'm having trouble reproducing the quality issues. Attached is a screenshot I made on my Windows 7 test device, using Chrome 78. This shows a weight waterfall from 200 to 900, with sizes 10px, 11px, and 12px. These are made from the files in the fonts/ttf directory, ie made from fontmake using ttfautohint. To my eyes, the hinting quality and spacing are topnotch. I also looked at it in IE 11 and the rendering is basically identical.

What I think might be going on here is that the variable fonts rendering path in Chrome on Windows is seriously degrading spacing quality. I've observed this on other fonts, I don't think it's an issue with the font file. I'm happy to have a conversation with the Chrome team about how to improve this, but I think we're pretty far outside the scope of the font release on that one.

[m4rc1e]

My win screenshots were produced via Browserstack using Win 10 Chrome 69 at 1280x666 resolution. These specs are ancient but I always test on ridiculously low specs just to ensure we're safe.

I'm not testing the static fonts. I'm comparing the instances in the VFs against the static fonts we currently serve on Google Fonts. I'll try on newer Win browsers next week.

[m4rc1e]

Sorry, I never mentioned our testing tools. We have the following:

Fontbakery: Our linter GFRegression: compare local fonts against the same fonts on Google Fonts Font Diffenator: Compare 2 fonts against each other

Here's a GFR url which compares the VF in this repo against the static fonts on Google Fonts. View this url on your Win machine and see if you can replicate my results. If you can't, it means the rendering/FreeType has improved significantly in newer versions of Chrome.

The results from our QA tools are still quite noisy and open to interpretation. We hope to get cleaner results next year.

[raphlinus]

I've done some more testing, and, long story short, think we have a serious quality issue in Chrome in some but not all configs. Below is a screenshot of the GF regression page on the "after" setting taken on my main Windows 10 machine, connected to a low-dpi monitor (1920x1080) monitor. On my Windows 7 box, which I keep around for compatibility testing, all variable fonts are rendered with their spacing quantized to integer pixels, which causes terrible spacing quality problems. I'm not sure exactly what the variable is here to enable such quality degradation - my spidey sense is telling me that they use some extremely complicated heuristic. I don't think the Chrome version is the issue, both are 78.0.3904.108.

I looked to see if I could find a relevant Chromium bug. There's one possible explanation in https://bugs.chromium.org/p/chromium/issues/detail?id=824150. The interesting line is "The biggest change is on Linux with the advances now generally correct for hinted fonts, greatly improving the glyph spacing for users with system settings of 'medium' or 'full'." I don't know what these system settings are, whether it's a Linux-ism or also applies to Windows, but it would explain the discrepancies. That bug, however, doesn't explain why we're seeing good quality with static instances but not VF.

So here's my current analysis:

• The font file in the release is fine, and there's nothing we can do to improve this issue.

• Chrome disables subpixel positioning for VF for some users but not others. We do not yet know the criterion for this, but one hypothesis is that the system settings must be detected as at least 'medium'.

• Serving VF fonts to users in that unhappy bucket will cause a serious quality regression compared with static instances.

Should I file a bug against Chromium?

[m4rc1e]

I've been doing some further tests using ftview which is a FreeType test utility. You can find this in the freetype2-demos, https://www.freetype.org/download.html

I'm currently testing a multi axis version of Nunito which also suffers with the same rendering issue. It seems that having font hinting enabled is producing very bad spacing for multi axis VFs; possibly because it's snapping to whole pixels.

If I disable font hinting, the results are far better.

Open up both images in new browser tabs and toggle

@drott is Chrome enabling font hinting on some platforms and not enabling it on others?

[drott]

CC @bungeman