[WIP] noto-fonts: build from source

[jopejoe1]

Description of changes

This is a work in progress of building noto-fonts from source, the main thing still to-do is adding the rest of the noto fonts from https://github.com/notofonts, but before doing that I wanted to gather some feed back on this.

cc @emilazy @Mathnerd314 as the ones currently maintaining noto-fonts together with me.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

Some scattered thoughts:

1. I got the impression on Matrix recently that people kind of hate from‐source font builds because they tend to be really slow and don’t necessarily produce tangible benefits. I like them, though, because after all, fonts are software. lib.sourceTypes.fromSource for life.

2. We had an issue recently where updating ICU caused some tests in an emoji font to fail because it was checking for the presence of glyphs in a new version of Unicode. That kind of thing is annoying, though I don’t know if it’ll apply here.

3. State of Text Rendering 2024 implied that there’s industry work on a new all‐Rust end‐to‐end font toolchain to replace the current tangled mess of Python. Do you know if that’s going to happen soon enough to drastically change the packaging (and perhaps performance) here?

[Mathnerd314]

Am I correct in thinking that this approach requires one package per font? So we would have to write a script to parse https://github.com/notofonts/notofonts.github.io/blob/main/fontrepos.json (or whatever the right file is), and generate a package set, like how we have Hackage embedded into Nixpkgs?

I agree with emilazy that this approach is likely to be slow and have no tangible benefits, but it is still the right approach, kudos for working on it. ;-)

[jopejoe1]

1. I got the impression on Matrix recently that people kind of hate from‐source font builds because they tend to be really slow and don’t necessarily produce tangible benefits. I like them, though, because after all, fonts are software. lib.sourceTypes.fromSource for life.

A font can contain web-assembly so i would only but as much trust in a font as i put in any pre compiled binary.

2. We had an issue recently where updating ICU caused some tests in an emoji font to fail because it was checking for the presence of glyphs in a new version of Unicode. That kind of thing is annoying, though I don’t know if it’ll apply here.

Currently this does not have any tests, but probably not because most of these have set number characters which does not really change.

3. [State of Text Rendering 2024](https://behdad.org/text2024/) implied that there’s industry work on a new all‐Rust end‐to‐end font toolchain to replace the current tangled mess of Python. Do you know if that’s going to happen soon enough to drastically change the packaging (and perhaps performance) here?

I sadly do not know the current state of the rust font tool-chain.

Am I correct in thinking that this approach requires one package per font?

Yes

So we would have to write a script to parse notofonts/notofonts.github.io@main/fontrepos.json (or whatever the right file is), and generate a package set, like how we have Hackage embedded into Nixpkgs?

I was intending to create a package that symlinks all the noto packages into one and than check that against https://github.com/notofonts/notofonts.github.io/tree/main/fonts in the check phase to see if anything is missing.

I agree with emilazy that this approach is likely to be slow and have no tangible benefits, but it is still the right approach, kudos for working on it. ;-)

Definitely slower than just downloading font, but better than trusting random binary's from the internet.

[fgaz]

fix header files

what does this fix specifically? isn't $prefix/include/$pname the conventional location? not that it should change anything when pkgconfig is used...

[jopejoe1]

From what I know only the /include dir get added to the include flags and not /include/$pname, but what is common is that some library's put their headers under /include/$name_chosen_by_lib, but in this case, the include statement would need to look something like #INCLUDE </$name_chosen_by_lib/a_header.h>

[eclairevoyant]

Not sure this change is a great idea, I know e.g. some browsers use skia. Changing this package over a font seems backwards to me.

[jopejoe1]

I tried compiling ladybird with that change, and it still worked, I don't know any other package that currently uses our variant of skia and not a vendored one.

But properly going to drop the skia stuff from this pr as it is not strictly necessary for building these fonts and currently doesn't work for skia-python correctly due to some undefined symbols.

[fgaz]

From what I know only the /include dir get added to the include flags and not /include/$pname, but what is common is that some library's put their headers under /include/$name_chosen_by_lib, but in this case, the include statement would need to look something like #INCLUDE </$name_chosen_by_lib/a_header.h>

I see what you mean, you're right on the convention. It would be nice if skia headers were namespaced (#include <skia/...>), but they aren't.

Still, other distros put skia header files under include/skia anyway. I think it's because skia headers include generic directory names ("core", "config", "docs", "svg"...) that would pollute the FHS (not sure about guix). We are not restricted by the FHS, but I'd still like to maintain consistency with other distros if possible.

Not sure this change is a great idea, I know e.g. some browsers use skia.

I tried compiling ladybird with that change, and it still worked

Indeed ladybird uses pkg-config, so it's going to work regardless of the headers' location. Other browsers vendor it.

[jopejoe1]

We can always append to the include dir to cflags like we do with harfbuzz for skia, so I'm not really set to what i did in that commit.

[Mathnerd314]

Definitely slower than just downloading font, but better than trusting random binary's from the internet.

Well, to get into a long digression, they are from Google, so not "random". I sure wish I didn't have to trust binary drivers to use my phone either, but that's life. For me it is more about transparency in the toolchain. If you can't build it you can't reproduce it or make changes. Whereas, if there is a Nix script, I know pretty much exactly what I have to do: nix-shell -A noto-fonts.

[jopejoe1]

Definitely slower than just downloading font, but better than trusting random binary's from the internet.

Well, to get into a long digression, they are from Google, so not "random". I sure wish I didn't have to trust binary drivers to use my phone either, but that's life. For me it is more about transparency in the toolchain. If you can't build it you can't reproduce it or make changes. Whereas, if there is a Nix script, I know pretty much exactly what I have to do: nix-shell -A noto-fonts.

For me, it pretty much all of those too, and just because I don't trust something it doesn't mean I'm not making use of it.