I've recently been looking at the prospect of locally patching font files for Fedora, prompted by two things:
1. Petr Vobornik raised the issue of fonts having an fsType flag that prevented embedding, even though they are licensed under terms which allow distribution and modification.[1]
2. Bug 706559, "Font variants not used correctly"[2], refers to a font family that contains more than just the R,B,I,BI styles and shows that they are not well-treated by applications including LibreOffice. It appears that this may be because the various weights and styles are not well named, but we can't quite get to the bottom of this bug because the family under discussion, Neo Sans Intel, is proprietary (i.e. not packaged).
However, we can see bugs like 706559 in fonts that we have already packaged. If you install chisholm-letterslaughing-fonts, you'll find that you have three font files but only one is accessible in LibreOffice. Close examination will show that all three have the Family name set to "Letters Laughing", but the Subfamily (Style) names are "at Their Execution", "by Quantized and Calibrated" and "Dissection and Destruction". You can see why LO might be confused.[#]
In other cases, we have had to adopt rather awkward Fontconfig configurations in order to rename fonts.
Now, we either fix font problems like these locally, or we push them back upstream. We are supposed to do the latter, but we know how many fonts are pushed out into the world as a one off. When font problems are raised during review and the packager is asked to push the comments back upstream, how often do we see little response and no new release?
Being practical, if we wish to fix problems locally, I'm aware of three options:
1. FontTools/TTX, which can convert a font into XML and back again. However, Petr reports that it currently crashes on Open Sans[3], and we have no smart way of verifying that the "To XML, patch, compile to TTF" cycle produces a font that performs at least as well as the original.
2. FontForge can be scripted to perform changes on fonts, but in this case we compile a completely new font, which is subject to any number of quirks introduced by local FontForge preferences, unstated in the script file, and FF's well-known stability issues.
3. Fontconfig scripts, which most of us just hack from the templates provided by Nicolas Mailhot because ... well, I certainly couldn't write the DejaVu ones from scratch. There is the additional problem that not all applications might use Fontconfig. (I might be misremembering but doesn't Firefox do something special?)
The problem of embedding flags is now being addressed by the packaging of a simple tool called "ttembed" which just touches OS/2.fsType and checksums, nothing else.[4]
I was considering the construction of another, more general, tool that would perform adjustments to other OS/2 or name table fields in-place[*], adjusting checksums as necessary in order to keep the font consistent, but specifically not decompiling the font or attempting to do glyph or GPOS type changes.
The proposed method would be to write a very simple recipe for the font changes, like this:
recipe.txt:
OS/2.fsType=0 OS/2.panose=4,0,0,0,0,0,0,0,0,0 name.1.0.0.1="Letters Laughing at Their Execution" name.1.0.0.2="Regular" name.1.0.0.4="Letters Laughing at Their Execution" name.3.1.1033.1="Letters Laughing at Their Execution" name.3.1.1033.2="Regular" name.3.1.1033.4="Letters Laughing at Their Execution"
and apply it with:
$ ttpatch recipe.txt LettersLaughing.ttf
With simple recipes like these, we could correct the entire Letters Laughing family and any others that don't follow WWS naming. With local testing for correct behaviour, we would even have a complete set of corrections to suggest to upstream (with the expectation that they'd apply them in their font editor, of course, rather than ttpatch.)
Note that the patch recipe contains deliberately almost-duplicated lines; I'd suggest that it's better to repeat the name record lines for Mac and Windows compatibility rather than try to build a cleverer ttpatch that would try to keep the names consistent across platforms and fail in the case of localisation differences, for instance.
I think that this would be a step forward from just packaging fonts and accepting their quirks towards more careful curation. I'd like to hear of any other problems with fonts in common applications that could be addressed in this fashion, or any other thoughts?
[*] OK, "in-place" is stretching it when considering the name table, which might grow or shrink as required, but I'm saying that this tool should definitely not re-order tables or touch anything other than the tables required to do the patch, which will be the touched tables, offset table and the head.checkSumAdjustment field. This makes verifying the changes much simpler.
[#] This issue came up during package review[5], and upstream refused to rename the styles. I'm proposing to adjust the fonts so that their quirky names remain unchanged, but redistributed amongst the name table fields so that all variants are accessible. I doubt upstream really wanted 2 out of 3 designs to be unusable in our major office application.
[1] https://lists.fedoraproject.org/pipermail/devel/2013-November/192501.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=706559 [3] https://lists.fedoraproject.org/pipermail/devel/2013-November/192540.html [4] https://bugzilla.redhat.com/show_bug.cgi?id=1036754 [5] https://bugzilla.redhat.com/show_bug.cgi?id=491530