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:
Did that ever get fixed?
Michael Droettboom <mdroe@...31...> 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...
Jouni K. Seppänen wrote:
Because of the problem described here:
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
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?
Jouni K. Seppänen