Jouni K. Sepp�nen wrote:
On OS X, using the pdf backend, I get the exception "RuntimeError:
TrueType font is missing table" when running examples/fonts_demo_kw.py,
because ttconv is trying to load /System/Library/Fonts/Times.dfont as a
TrueType font, which it of course is not.
A simple solution would be to limit the font searching algorithm to only
look for files matching *.ttf, but that would unnecessarily limit the
Agg-based backends, since freetype does understand and render dfont
files. The best solution would be to implement dfont support in the pdf
backend, but I have no idea how complicated that would be.
Unfortunately, .dfont files aren't used *correctly* by the font manager at present, either. .dfont files can contain multiple ttf files -- so as a .ttf file always contains a single weight/angle/stretch etc., a .dfont usually contains a number of different versions of the same font family. The FT2Font class underlying the font manager is hardcoded to always look at only the first ttf in the .dfont file. That can probably be fixed, of course, but .dfont files will have to be treated differently from .ttf files in the font manager anyway.
FWIW, fontconfig 2.4.2 (what MacPorts gives me) doesn't seem to handle .dfonts correctly either.
$ fc-match -v HelveticaNeue:italic
Pattern has 28 elts (size 32)
family: "Helvetica Neue"(s)
<snip>
file: "/Library/Fonts/HelveticaNeue.dfont"(s)
index: 0(i)(s)
$ fc-match -v HelveticaNeue:bold
Pattern has 28 elts (size 32)
family: "Helvetica Neue"(s)
<snip>
file: "/Library/Fonts/HelveticaNeue.dfont"(s)
index: 0(i)(s)
I would have expected the index value to be different. But maybe I'm just misusing/misunderstanding fontconfig...
What would be a reasonable interim solution? Perhaps the font manager
should identify the file type of each font file it knows about, so e.g.
the pdf backend could request a list of just the TrueType fonts.
(See also:
http://article.gmane.org/gmane.comp.python.matplotlib.general/10069 )
I definitely agree with what you're saying. Taking a step back, though, I worry about the user needing to know about the surprises in the font-compatibility space. Say a user develops a plot using an interactive backend (with Agg), and then decides to publish the plot using PDF and is surprised when it picks up completely different fonts. At the very least we should find a way to inform the user that the first choice font (a dfont) was bypassed in favor of a ttf font, since the backend doesn't support it.
Part of me is thinking that for simplicity, we should only support .ttf fonts everywhere (excluding text.usetex == True), as that is the lowest common denominator, but I know that might be limited and disappointing to some. Mac users could run fondu over their fonts to get .ttfs from .dfonts.
Cheers,
Mike