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’t want to package every font we can find.
  • Whether it’s ok to not have a version, given that many fonts don’t 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’m 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’t 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’s nice to be told exactly what to do: you don’t want to be left wondering whether you’re doing the right thing).

Related discussion on these PRs:


I don’t know much about fonts, so I’ll 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).


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’ll 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.


Relevant PR:

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’re at it :slight_smile:


Not sure if it is related to this topic.

I recently encountered a font-related issue. LibreOffice Writer doesn’t 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’m packaging the some Chinese fonts (#93232) recently (by chmod 644 those *.ttf and put them into $out/share/fonts/), but they don’t 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