Noto-fonts: switch to variable fonts

[Mathnerd314]

Describe the bug

This is a follow up to #166600 and the comment in

nixpkgs/pkgs/data/fonts/noto-fonts/default.nix

Line 34 in a0a77f1

# TODO: install OpenType, variable versions?

AFAICT, just like the variable fonts are best for CJK, they are the best version to use for all the other Noto fonts too. This is what Fedora thinks. The variable fonts save a lot of disk space (10.94MiB vs 1.02MiB for Sinhala) and provide all variations, as well as enabling custom font variations in software that supports them.

I was wondering about hinting but it seems that all that's happening is ttfautohint. ttfautohint is built into FreeType so I think it gets run on Linux regardless for TTF fonts.

Now, the Adobe CFF renderer for OTF is better than the TTF renderer, and ideally we would get OTF variable fonts like with CJK. But those aren't available at the moment.

unhinted/slim-variable-ttf is a variable font with only 400 (Regular) through 700 (Bold) on the weight axis, prepared for Android system UI use (script, doc note), it's smaller at 353 KB vs 1.03MB. Since we ship Light (300) in the main noto-fonts package I think we want the full range. Although Fedora chose the slim, the savings from removing weights seems small IMO.

I'm opening this now but I think we should wait a week or two before switching over the fonts, in case there is more fallout from the variable CJK switch.

Notify maintainers

cc @midchildan since you've been writing all the patches recently

[Mathnerd314]

OK, disk usage report on a download of https://github.com/googlefonts/noto-fonts:

755M    ./archive
483M    ./hinted/ttf
669M    ./unhinted
267M    ./unhinted/otf
336M    ./unhinted/ttf
47M     ./unhinted/variable-ttf
21M     ./unhinted/slim-variable-ttf

So sparse git checkout is the way to go, to avoid the archive directory.

Now, comparing the options:

Option	noto-fonts size	noto-extra size	Sum
Hinted TTF	71M	393M	464M
Unhinted TTF	52M	269M	321M
Pure OTF	38M	210M	248M
OTF+Slim VF, OTFs in noto-extra	41M	194M	235M
OTF+Slim VF, VF in noto-extra	41M	65M	106M
OTF + VF in noto-extra	38M	67M	105M
OTF + VF in noto	59M	26M	84M

edit: numbers redone with a Python script based on actual font family names. Discovered several bugs in the font files during this.

The VF options are all combined with (unhinted) OTF since the variable fonts cover only a subset of the fonts.

The slim VF doesn't have Light, so to keep the same font set noto-font would include Light and LightItalic OTFs (5M or so). As I thought, Slim seems like a loser. It's worse than shipping the individual OTF's, by 3M (because it includes Medium and SemiBold). And it duplicates the font weights with VFs in noto-extra, which save a lot of space.

The full variable fonts can either be in noto-fonts or noto-extra. If they are in noto-extra, we have to ship the normal OTF fonts NotoX-Regular; if in noto-fonts we can skip this. VF in noto-extra minimizes the size of noto-fonts, while VF in noto-fonts minimizes Hydra usage and avoids shipping fonts twice. Even with the VF in noto-fonts, it's still a savings versus the hinted TTF.

So overall this confirms my initial thoughts, ship the full VF set in noto-fonts. What do other people think?

[midchildan]

VF in noto sounds good to me 👍

[Mathnerd314]

Also, Light/LightItalic should be in the extra package IMO, and the main package should be limited to {Regular,Bold,Italic,BoldItalic}. Those are the "Microsoft 4 styles", and the split is also what Debian does (core extra). Looking at #31543 (comment) it seems Light was included in noto-fonts only because it was available in the 2016 git snapshot.

It's only a 1M difference though, not sure if important. 58M and 59M are both close to the current 60M.

[Mathnerd314]

Ah, they were included because KDE says they need Light for the calendar widget. And there's a vague sort of promise that that's all they'll use. So I guess Light stays in. Although, most of the relevant languages have VF's with all weights, so it's kind of a corner case.

[Mathnerd314]

Alright, the status now is to wait a few days to see if Google fixes https://github.com/googlefonts/noto-fonts/issues/2315, https://github.com/googlefonts/noto-fonts/issues/2316, https://github.com/googlefonts/noto-fonts/issues/2317, and https://github.com/googlefonts/noto-fonts/issues/2326, as fixing those will simplify the packaging. Worst case I'll have to special-case exclude the buggy fonts.

[Mathnerd314]

PR is up, #170355

[lhindir]

Only tangentially related, but since you're probably fairly familiar with the Noto packaging process now, I was wondering if you saw the new version of the monochrome Noto Emoji (as opposed to Noto Color Emoji).

I can't seem to find the source on GitHub (the noto-emoji repo still contains the old Noto Emoji, which is unmaintained and pending removal), but the new version is available from https://fonts.google.com/noto/specimen/Noto+Emoji/about under the SIL OFL. This bundle contains ttf's for five weights as well as a variable font; unfortunately, fc-query on the variable font indicates it only exposes three of these weights, so it might be best to hold off on the variable version for now.

What do you think about modifying the noto-fonts-emoji package to install this new version instead of the old one? The five weights weigh in under 5 MiB.

[Mathnerd314]

Hmm, it should at least be in https://github.com/google/fonts/tree/main/ofl. But it isn't. I think I will wait until it appears on GitHub somewhere, as the website link https://fonts.google.com/download?family=Noto%20Emoji looks like it will break when they update the font.

As far as packaging goes, we should probably have separate noto-emoji-color and noto-emoji packages.