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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
