Guidelines on packaging fonts

[timokau]

I don’t know much about fonts, so I’ll only reply to general things I know answers to / have opinions on.

@Thra11

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.

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).

@Thra11

• Whether it’s ok to not have a version, given that many fonts don’t publish a version number.

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).

@Thra11

@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).

@Thra11

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.

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 It can always be changed in the future.