Jouni K. Seppänen wrote:
> No, that's exactly what I was thinking about - some newly-found font
> might break matplotlib, or might change somebody's output because of the
> font matching algorithm.
> Actually, the font matching system can
> sometimes break things:
>
> http://thread.gmane.org/gmane.comp.python.matplotlib.general/18255/focus=18260
>
Sorry that fell by the wayside. On further investigation, there are two
bugs here:
1) The "stretch" metric is not read from .afm files: it's always set to
"normal", therefore, when specifying "Helvetica" which exists in a
number of widths, it has an equal chance of choosing any of them
depending on dictionary ordering. Note that now {'family': 'Helvetica',
'stretch': 'narrow'} should and does return "Helvetica-Narrow". Both
"Helvetica" and "Helvetica-Narrow" are of the same font family, so that
in itself is not a bug (it's the same mechanism that makes {'family':
'Helvetica', 'weight': 'bold'} give "Helvetica-Bold").
2) When pdf.use14corefonts is True, it will actually pull an afm font
file from anywhere, not just from mpl-data/fonts/pdfcorefonts. There's
actually some logic in the FontManager to collect files from only that
directory when "pdf.use14corefonts" is True, but that's only triggered
at cache-build time. That's how bug 1) resulted in adding a font that
isn't a PDF core font to a PDF file. But it would be just as easy to
specify some other random "afm" font on the system and break things in
the same way.
Lastly, to support all this, the cache needs to be thrown away, so I
added support for versioning of the cache file -- if it doesn't match
what the currently-installed matplotlib expects, it's thrown away and
regenerated.
Mike
> Did that ever get fixed?
>
> Jouni
>
> Michael Droettboom <md...@stsci.edu> writes:
>
>
>> Sorry about that bug. Obviously it wasn't tested properly.
>>
>> It seems like the only side effect of this change is that matplotlib
>> will pull in fonts from non-standard locations defined in their
>> fontconfig configuration. (It's already pulling them from standard
>> locations that are hardcoded in font_manager.py). There's a chance that
>> some of these fonts will cause matplotlib to explode -- but no more so
>> than if there were in a standard location.
>>
>> I think it seems like a pretty benign change -- unless there's something
>> in particular you're thinking of that I'm not...
>>
>> Mike
>>
>> Jouni K. Seppänen wrote:
>>
>>> Because of the problem described here:
>>>
>>> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20328
>>>
>>> I modified font_manager.py to use subprocess.Popen instead of
>>> commands.getstatusoutput, since subprocess seems to deal with EINTR
>>> while the commands module does not. While looking at it, I changed the
>>> command being run from
>>>
>>> fc-list file
>>>
>>> to
>>>
>>> fc-list '' file
>>>
>>> because the former doesn't return any fonts on any system I have access
>>> to (maybe it would if I had a font whose name includes the word "file"),
>>> but the latter looks more like it is the intended command. Since the
>>> get_fontconfig_fonts function has not returned anything useful for some
>>> time (though presumably it has at some point in the past), this change
>>> might have big effects somewhere else.
>>>
>>> Would this change be appropriate for the bugfix branch?
>>>
>>>
>>>
>
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
