Guidelines on packaging fonts

Having recently tried to package a font for the first time, I found myself with many questions and, despite looking in the manual, no answers.

  • Should font variants be packaged individually or together (common to have serif and sans versions, as in this PR) (Perhaps they should even be grouped by foundry?)
  • Where multiple formats are available (e.g. otf, ttf, woff), should we choose a format or package all of them? If the latter, should they all be in a single package? or separated into fontname-ttf, fontname-otf, etc.?
  • What should the package name be? Just the font name? fontname-font? fontname-tff?
  • Any guidelines on what makes a font a good candidate for inclusion in nixpkgs. Only a tiny percentage of fonts are packaged at the moment, but I assume we don鈥檛 want to package every font we can find.
  • Whether it鈥檚 ok to not have a version, given that many fonts don鈥檛 publish a version number.

@puzzlewolf also kindly brought to my attention that despite many of the existing font packages just using fetchzip, it is preferable to use mkDerivation (with fetchzip for the src inside it if necessary).

I propose adding a section to the nixpkgs manual detailing how to package fonts in nixpkgs. I鈥檓 happy to try and write the section myself if no-one else wants to, but I will first need to know the right answers.

I know sometimes things are left unspecified because people haven鈥檛 yet worked out or agreed on the correct way to do something, but I think guidelines make new contributors feel more confident, and thus more welcome (when you start a new job, it鈥檚 nice to be told exactly what to do: you don鈥檛 want to be left wondering whether you鈥檙e doing the right thing).

Related discussion on these PRs:
https://github.com/NixOS/nixpkgs/pull/83537
https://github.com/NixOS/nixpkgs/pull/90245

4 Likes

I don鈥檛 know much about fonts, so I鈥檒l only reply to general things I know answers to / have opinions on.

There are no clear guidelines, same as for package inclusion. The defacto guideline is: At least one person (you) cares enough about it to package it and let the PR be nitpicked until a reviewer is happy. Bonus points if there is some indication of popularity (like a couple of stars on github or whatever the font equivalent is).

You should use whatever upstream uses to differentiate the different versions of the fonts. If they do not use anything, use a date as the version (version = "2020-06-15"; if it was last changed on 2020-06-15).

:+1:

Thats a good idea! I suggest you just start writing whatever you think is best. I have found that the best way to move forward in open source projects is just getting started on something. People will then come and nitpick it / provide suggestions. If you want to resolve all open questions first, you鈥檒l probably never get started.

Long story short: Write the manual entry, post it here, rely on xkcd: Duty Calls. If nobody complains, your opinion is now fact :wink: It can always be changed in the future.

6 Likes

Relevant PR: mkFont derivation for unified font packaging by Valodim 路 Pull Request #91518 路 NixOS/nixpkgs 路 GitHub

I unified a lot of derivations by introducing a common mkFont one. If you planned to write some documentation, perhaps we can collaborate on that and think not just about how packaging de facto works, but how it should work while we鈥檙e at it :slight_smile:

7 Likes

Not sure if it is related to this topic.

I recently encountered a font-related issue. LibreOffice Writer doesn鈥檛 seem to get some fonts like wqy_zenhei, but it gets source-han-serif-traditional-chinese without problem. (#93396)

Not sure if it is the output path of the font that cause the problem.

I鈥檓 packaging the some Chinese fonts (#93232) recently (by chmod 644 those *.ttf and put them into $out/share/fonts/), but they don鈥檛 appear in LibreOffice Writer, either.

1 Like

I have a similar PR that also adds a test: Add buildFontPackage with test by davidak 路 Pull Request #93533 路 NixOS/nixpkgs 路 GitHub