Re: [matplotlib-devel] Font searching

[Michael D. <md...@st...>]

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