Local patching of fonts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
Paul Flo Williams
http://hisdeedsaredust.com

_______________________________________________
fonts mailing list
fonts@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/fonts
http://fonts.fedoraproject.org/





[Index of Archives]     [Fedora Users]     [Font Configuration]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux