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:

1 Like

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 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: