I created diffs for all derivations, from a their original form to b their mkFont version: https://gist.github.com/Valodim/d17a6bf89d6a52e56d493d3532c6fa30

For each derivation I output the file contents (just find) of the new package, and then a diff (git diff --no-index a/ b/) to the old one. It's fairly easy to spot differences in this format, but I'm sure I missed some issues :) Still, it's easy to see that the overall consistency is much better than before.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/guidelines-on-packaging-fonts/7683/3

There is a problem in that mkFont doesn't handle multiple outputs. Until Pango is released with a fix to this issue, putting bdf/pcf fonts in the same output as otb will effectively break both in most GTK applications.

That's exactly the type of input I've been looking for, thanks! Coincidentally, there was a comment on that thread yesterday saying it was fixed. Let's stay tuned on whether that's actually true.

Provided the bug is fixed, do you still think multiple outputs would be useful? I can think of a couple arguments for and against (short on time right now, gonna pick this up later).

Yes, they could still be useful. For example, there is pkgs.unscii which is huge: it contains rarely used formats live svg, woff and hex that I've split into an extra output.

Is this meant just for installing already built font files – I mean it does not make sense for fonts that have Makefiles.

Is this meant just for installing already built font files – I mean it does not make sense for fonts that have Makefiles.

It's not. It is essentially a specialized version of mkDerivation with a custom installPhase that works well for fonts. I disabled most phases by default as most font packages don't need them, but they can be enabled with no caveats and there are a couple of derivations in the second commit that do that already.

Yes, they could still be useful. For example, there is pkgs.unscii which is huge: it contains rarely used formats live svg, woff and hex that I've split into an extra output.

Right. At the moment, there are lots of derivations that package their woffs, eots, svgs, depending on which other derivation they were cargo-culted from. There are also txts or pdfs with various content, I even saw an xlsx in there.

The point here is to allow us to make decisions about font packaging ("where do ttfs go?", "what chmod should font files have?", "how is fontconfig called?", "should woffs go in a separate output?") as a policy, that can be encoded in mkFont and documented.

I don't particularly care what those policies are, but the more consistent we can be, the more stable assumptions can be made by packagers as well as users :) See also the related discourse thread.

Incidentally I had something very similar in my local repo (because I love using legible fonts)- would you mind adding a parameter, say- toDelete?[] and adding in installPhase, the following-

			for de in $toDelete
			do
				find -name $de | xargs rm
			done

This is because fontconfig is really bad in determining which fonts from within a family take prececdence (by default). For example, I use the following for Delicious font; if you don't use the toDelete field, then based on which stars align, you may get Delicious Small caps as the applicable font when you just say, "Delicious", or worse Delicious Heavy.

				generic-font-zip
				{
					name = "DeliciousRoman";
					url = "http://www.exljbris.com/dl/delicious-123.zip";
					sha256 = "1lhfnyzfaibz53syfghll3sjiys7x7hvppxx4wbm5gwdgj7cxmg9";
					toDelete = [ "Delicious-Heavy.otf" "Delicious-SmallCaps.otf" ];
				}

Btw, this must have been such a herculean undertaking- our collective eyes will thank you when we can use more legible fonts :).

I use the following for Delicious font; if you don't use the toDelete field, then based on which stars align, you may get Delicious Small caps as the applicable font when you just say, "Delicious", or worse Delicious Heavy.

What would this mean for people who actually want to use Delicious SmallCaps or Delicious Heavy? Would you put them in a completely separate package?

I was wondering whether a font package could have multiple-outputs, e.g. delicious.regular, delicious.heavy, delicious.smallcaps. As far as I'm aware output names are technically just arbitrary: the fact that many functions and derivations treat outputs like bin, lib, and dev specially doesn't stop you creating your own outputs. I don't know whether this would be considered undesirable abuse of multiple outputs.

However, I think only installing some of the styles available is at best a workaround. Ideally we should try to fix the actual issue. I found this, which is an interesting exploration of some of the complexities of fontconfig font matching. Maybe we can work out why fontconfig is choosing the wrong style from the delicious family and either patch the delicious files to correct the metadata (if that is the issue), or add something to /etc/fonts/conf.d/* to nudge fontconfig in the right direction.

This is not a Nix specific problem, I used to face this in Arch too. Fontconfig has a lot of problems. Specially so if you want to use non-latin fonts. There is no consistent theme underlying fontconfig configuration language is what I've concluded after I've spent a lot of hours on fontconfig, the best bet is to just get do what is needed and spend time doing work.

In this case, I think you could argue that it is an "upstream" problem/bug. Based on the appearance of the individual styles in the family, it looks like Delicious-Roman.otf should be the "normal"/regular/default variant, but the style data in the font files is as follows:

Delicious-Roman: family: "Delicious", style: "Roman"
Delicious-Heavy: family: "Delicious Heavy" "Delicious", style: "Regular" "Heavy"
Delicious-SmallCaps: family: "Delicious SmallCaps" "Delicious", style: "Regular" "SmallCaps"

It doesn't seem unreasonable that fontconfig favours the heavy and smallcaps styles, as they claim to be "Regular" fonts, which are in the "Delicious" family. Delicious-Roman, on the other hand, claims to be a "Roman" style, which nobody asked for.

I believe there are a few possible workarounds/fixes:

• Don't install the heavy and smallcaps styles: The simplest solution if it's just for you, but probably not suitable if packaging the font for other to use.
• Patch the font to make the style metadata better match the actual fonts and their intended usage: Plausible, but not trivial as we don't compile the fonts ourselves.
• Add a snippet to /etc/fonts/conf.d: NixOS already has things like fonts.fontconfig.localConf for users to add their own rules. If we are going to have something like mkFont, could it maybe allow font packages to specify fontconfig configuration snippets which get concatenated and written to a file with suitable priority in /etc/fonts/conf.d? This would mean that for problematic font families like this, you could write a short snippet to tell fontconfig that "Delicious Roman" is the preferred font in the "Delicious" family.

As you can probably tell, I'm leaning towards the last option, though I haven't tried to implement it yet, and I don't know how common fonts with messed-up metadata are yet.

I agree with your argument

Hello, how I can help you progress this PR?

"little" sad that somebody changed 189 files and rather than helping push this PR, people comments irrelevant comments about code style.

Now this PR is dead. Good job everyone. (some of the usual suspects obviously)

I marked this as stale due to inactivity. → More info

Hi!

I think this PR is very interesting, do you think you could refresh it so we can give it a review?