Re: [matplotlib-devel] Font searching

2007-08-27 Thread Michael Droettboom
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)

 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)

 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


Re: [matplotlib-devel] config with traits

2007-08-27 Thread Michael Droettboom
Michael Droettboom wrote:
> Darren Dale wrote:
>> On Wednesday 22 August 2007 4:20:08 pm Michael Droettboom wrote:
>>> Darren Dale wrote:
 If you want all that flexibility, why not do it in the usual way:

 #mathtext.it.family  : 'serif'
 #mathtext.it.style : 'oblique'
>>> That seems reasonable.  I think I had a mental block around this because
>>> of the verbosity (and seeing a font specification as a single unit), but
>>> it does seem to fit in much better with the existing options (i.e. a
>>> subset of font.*).
>>>
>>> *IF* fontconfig is ever adopted, we could use fontconfig patterns as an
>>> alternative, which are at least some kind of standard.
>>
>> Right:
>> mathtext.it : serif-12:italic # use the default serif, 12 pt italic
>> or
>> mathtext.it : times:italic # use the times italic font, default size
>>
>> Could this syntax be adopted, even without fontconfig? Then if we 
>> decided to use fontconfig in the future, the disruption would not be 
>> too great.
> 
> Sure, it's certainly an easy enough format to support.
> 
> Of course, the matching algorithm used by font_manager.py is different 
> from fontconfig.  font_manager.py essentially looks for an exact match 
> or falls back to a single default.  fontconfig does a nearest neighbor 
> search, so often finds a better alternative.  So even if they use the 
> same syntax, the results will be different (in some side cases) if we 
> ever move over to fontconfig.  (There are pros and cons to using 
> fontconfig already discussed on this list.  I'm not really advocating 
> for or against it myself.)
> 
> Still, IMHO, it's worth supporting this syntax now even though users may 
> need to change their font specifiers later -- those changes should be 
> more minor than if we go with
> 
> #mathtext.it.family  : 'serif'
> #mathtext.it.style : 'oblique'
> 
> now.

I just committed code to support fontconfig patterns on all of the 
mathtext.* fonts.  You can also use fontconfig patterns in the pylab and 
OO interfaces -- e.g.:

title("This is my title", fontproperties="Helvetica:italic")

(Note this doesn't actually use fontconfig -- I've just borrowed its 
font-specification syntax.)

I was thinking we probably want to collapse the following options down 
to one as well --->

#font.family : sans-serif
#font.style  : normal
#font.variant: normal
#font.weight : medium
#font.stretch: normal
# note that font.size controls default text sizes.  To configure
# special text sizes tick labels, axes, labels, title, etc, see the rc
# settings for axes and ticks. Special text sizes can be defined
# relative to font.size, using the following values: xx-small, x-small,
# small, medium, large, x-large, xx-large, larger, or smaller
#font.size   : 12.0

probably to "font.default" ?  For backward compatibility, we probably 
want to continue to support these, but "font.default" would override 
them if provided.  Any ideas on how to best do that?  I only have a 
rough sense of where the new traited config stuff is going wrt backward 
compatibility etc.

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