Dealing (gracefully?) with problematic fonts #3903
Comments
|
I thought that @jenshnielsen had a recent PR ##3853 that addressed something similar. Can you please post the full backtraces (or links to them?) |
|
This is all the console input and output: ( and this is the crash reporter's dump (sorry it's long!): |
|
I think this issue is different from the ones that I fixed. I haven't seen this one but I will try to have a look. How did you install python and matplotlib? Which version of freetype have you got ( |
|
Python and ferrotype are installed from unmodified sources (config files modified as necessary for freetype). Installed as super-user (
|
|
Just pinging because I still can't use matplotlib under MacOS 10.10.1 with Python 3.4.2. Latest (failing) configuration is freetype 2.5.5 (no modification) with matplotlib 174b126 . |
|
I tried reproducing the issue but can't reproduce it on Yosemite. I use homebrew python and freetype and tried modifying freetype to enable I have “/System/Library/Fonts/Apple Color Emoji.ttf” and fc-list shows the font as expected. Could you try to reproduce the issue with a more standard python build such as homebrew? |
|
As it turned out, this was not a matplotlib problem per se. An older instal of freetype had left a Still there remains, at least in my view, a problem of uncaught exceptions (the one I have encountered here and another when outputting to pdf), but that will be the topic of another discussion. Finally, I would rather not use homebrew (or fink, for that matter), unless as a last resort. That is no slight agains these endeavours, it is just that it adds yet another wrinkle in the complexity of which item will be invoqued, or linked against, or considered for inclusion etc.. And I would lose, I believe, the freedom to configure at will my components. Still, as the dependency trees have gotten increasingly long and intertwined as the years went by, using it would have certainly saved me a lot of time (but, hey, what would be life with less stress :-< ?), especially on the Mac platform with its recent invasion of doppelgängers… |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
[Reposted from matplotlib-devel, as it seems it never got out, and updated]
The transition to MacOS X 10.10 (and more precisely 10.10.1) is proving quite problematic. One problem I am currently stuck with prevents me from using matplotlib.
Whether using matplotlib 1.4.2 and freetype 2.3.12 (combination A), matplotlib 59eda22 and freetype 2.5.3 (combination B), or matplotlib 543a222 and freetype 2.5.4 (combination C) importing matplotlib.pylab results in a crash. I have not tried other combinations…
In the case of combination A, the crash occurs because FT_Set_Char_Size (ft2font.cpp, line 909) returns an error because of the font “/System/Library/Fonts/Apple Color Emoji.ttf” and an uncaught exception is then thrown on line 916.
In the case of combination B and combination C, the crash occurs because FT_Set_Char_Size (ft2font.cpp, line 508) returns an error because of an unidentified font (I could not quickly find a way, in this version of the file, to access the name of the font being tested…) and an uncaught exception is then thrown on line 510.
As the font “/System/Library/Fonts/Apple Color Emoji.ttf” is a system font, and therefore off-limits to most users, it would be unadvisable to mess with it (including removing it from the system), and even though I would personally be quite unlikely to use it in conjunction with matplotlib, our Japanese colleagues might see things differently. At any rate, it does not seem to be corrupt (it may be complex, though, as TypeTool displays it differently from Font Book, which is hardly surprising as it is a color font…).
Note that in the case of combination C, removing the font “/System/Library/Fonts/Apple Color Emoji.ttf” still results in a crash, at the same place, but after a more lengthy processing, which likely implies that at least another (unidentified) font is problematic.
Barring a more sophisticated treatment of such fonts, could it be possible to catch the exception, just not take these fonts into account, and move on to the rest of the work? I have not grasped the organisation of the source that well to know where to propose a patch. Any hint welcome!
The text was updated successfully, but these errors were encountered: