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
Did that ever get fixed?
Jouni
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...
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?
--
Jouni K. Seppänen
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 <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...
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