Description of problem: As discussed here: http://permalink.gmane.org/gmane.comp.python.matplotlib.devel/12650 It appears that python-matplotlib needs to install the .ttf fonts that are shipped with matplotlib in order for stix math to work Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I do not recall all details, but there was some discussion at https://bugzilla.redhat.com/show_bug.cgi?id=885307 I remember upstream stix fonts changed file names, and not all projects adapted. Also, unless under very special circumstances, bundling is not allowed, so, the python-matplotlib package should not install its copy of the fonts. If you have some simple test case demonstrating the problem, some work could be done, e.g. I got it in a state that appears to satisfy all sagemath doctests...
The following example generates some stix (and other) font errors. $ python import pylab as p ax=p.subplot(111) xs=range(0,10) ys=range(0,10) ax.set_xscale('log') ax.set_yscale('log') p.plot(xs,ys) p.show() I will attach a file wiith the errors generated. These are the stix packages installed. $ rpm -qa | grep stix stix-math-fonts-1.1.0-5.fc20.noarch stix-fonts-1.1.0-5.fc20.noarch texlive-stix-svn29803.1.0-4.fc20.noarch
Created attachment 846735 [details] stix font errors
You didn't do anything except a basic plot here. The usual way I get stix font errors is use texmath. Something like: In matplotlibrc: mathtext.fontset: stix Then: plt.title ('$\alpha=2$') You should be able to get the same result as setting matplotlibrc by using programatic interface.
Actually, my patch to use fontconfig was dropped when updating from 1.2 to 1.3. You should not have any warnings if patching like this $ sudo vi /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py I did not notice this problem earlier and for quite some time I agree (very busy with other stuff)... - drop fontconfig patch (upstream) Thomas? :-)
> $ sudo vi /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py I meant $ sudo sed -i 's/\(USE_FONTCONFIG = \)False/\1True/' /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py
I can confirm that that fix works well for me. Can we get this fix in a package update for F20 please?
*** Bug 1050923 has been marked as a duplicate of this bug. ***
I created a bundling exception request for stix-fonts at https://fedorahosted.org/fpc/ticket/381
Can you explain why a bundling exception is required please, since the work around in comment 6 seems to work fine. Isn't it just this change to the package thats needed?
The patch originally was basically only to set USE_FONTCONFIG = True but that caused several side effects, that required a not so trivial patch, but trial&error is bad... And the patch was dropped "accidentally" because the non trivial part was added upstream and it took quite some time to notice that (required a fedora release and bug reports). Upstream also says it most likely will find several other problems in special cases. Upstream and AFAIK (almost) all other distros bundle the fonts (some probably by accident), so, upstream basically only tests with bundled fonts.
For now I set USE_FONTCONFIG to True in rawhide and wait until your bundling exception is completely done. With my recent commit to git, the proper backend is now used again and we have the most recent version in rawhide. I'll leave the font bundling issue up to you.
Created attachment 856342 [details] matplotlib.patch Source rpm: http://pcpa.fedorapeople.org/python-matplotlib-1.3.1-2.fc21.src.rpm I plan to commit this patch. It adds some Debian patches, as it is basically what I was thinking about when asked for a bundling exception, but now using theirs (Debian) tested approach. Changes are basically: o Previous %{python_sitearch}/matplotlib/mpl-data was duplicated for python2 and python3, now it was made noarch and shared. o matplotlibrc was moved from .../mpl-data to /etc, and again shared by both python (this one may have issues if one wants to install 32 and 64 bit packages, what I believe is not a big issue, would file conflicts but file with same contents). o Fixed and enabled %check Only problem I see is that one will need to "rm -fr ~/.matplotlib" or will get back the errors about fonts not found. Not sure if should add some README or write something in %post to stdout. Other issues could be python-matplotlib-data-fonts contents, so, here are the contents: $ rpm -ql python-matplotlib-data-fonts /usr/share/matplotlib/mpl-data/fonts /usr/share/matplotlib/mpl-data/fonts/afm /usr/share/matplotlib/mpl-data/fonts/afm/cmex10.afm /usr/share/matplotlib/mpl-data/fonts/afm/cmmi10.afm /usr/share/matplotlib/mpl-data/fonts/afm/cmr10.afm /usr/share/matplotlib/mpl-data/fonts/afm/cmsy10.afm /usr/share/matplotlib/mpl-data/fonts/afm/cmtt10.afm /usr/share/matplotlib/mpl-data/fonts/afm/pagd8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pagdo8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pagk8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pagko8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pbkd8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pbkdi8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pbkl8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pbkli8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pcrb8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pcrbo8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pcrr8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pcrro8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvb8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvb8an.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvbo8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvbo8an.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvl8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvlo8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvr8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvr8an.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvro8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/phvro8an.afm /usr/share/matplotlib/mpl-data/fonts/afm/pncb8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pncbi8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pncr8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pncri8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pplb8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pplbi8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pplr8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pplri8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/psyr.afm /usr/share/matplotlib/mpl-data/fonts/afm/ptmb8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/ptmbi8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/ptmr8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/ptmri8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/putb8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/putbi8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/putr8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/putri8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pzcmi8a.afm /usr/share/matplotlib/mpl-data/fonts/afm/pzdr.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Courier-Bold.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Courier-BoldOblique.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Courier-Oblique.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Courier.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Helvetica-Bold.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Helvetica-BoldOblique.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Helvetica-Oblique.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Helvetica.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Symbol.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Times-Bold.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Times-BoldItalic.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Times-Italic.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/Times-Roman.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/ZapfDingbats.afm /usr/share/matplotlib/mpl-data/fonts/pdfcorefonts/readme.txt /usr/share/matplotlib/mpl-data/fonts/ttf /usr/share/matplotlib/mpl-data/fonts/ttf/COPYRIGHT.TXT /usr/share/matplotlib/mpl-data/fonts/ttf/LICENSE_STIX /usr/share/matplotlib/mpl-data/fonts/ttf/README.TXT /usr/share/matplotlib/mpl-data/fonts/ttf/RELEASENOTES.TXT /usr/share/matplotlib/mpl-data/fonts/ttf/STIXGeneral.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXGeneralBol.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXGeneralBolIta.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXGeneralItalic.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXNonUni.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXNonUniBol.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXNonUniBolIta.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXNonUniIta.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXSizFiveSymReg.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXSizFourSymBol.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXSizFourSymReg.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXSizOneSymBol.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXSizOneSymReg.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXSizThreeSymBol.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXSizThreeSymReg.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXSizTwoSymBol.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/STIXSizTwoSymReg.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/Vera.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/VeraBI.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/VeraBd.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/VeraIt.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/VeraMoBI.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/VeraMoBd.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/VeraMoIt.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/VeraMono.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/VeraSe.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/VeraSeBd.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/cmb10.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/cmex10.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/cmr10.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/cmss10.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/cmsy10.ttf /usr/share/matplotlib/mpl-data/fonts/ttf/cmtt10.ttf If you have any comments, please let me know, otherwise I will "git push" and submit builds shortly.
(In reply to Paulo Andrade from comment #13) > I plan to commit this patch. > It adds some Debian patches, as it is basically what I was > thinking about when asked for a bundling exception, but now > using theirs (Debian) tested approach. Changes are basically: > > o Previous %{python_sitearch}/matplotlib/mpl-data was > duplicated for python2 and python3, now it was made > noarch and shared. > o matplotlibrc was moved from .../mpl-data to /etc, and > again shared by both python (this one may have issues > if one wants to install 32 and 64 bit packages, what > I believe is not a big issue, would file conflicts but > file with same contents). > o Fixed and enabled %check Thanks! > Only problem I see is that one will need to "rm -fr ~/.matplotlib" > or will get back the errors about fonts not found. Not sure if > should add some README or write something in %post to stdout. Why can this happen? It just worked over here without deleting my old config (but maybe I have too less in it...). > If you have any comments, please let me know, otherwise > I will "git push" and submit builds shortly. - It would be good to also require %{name}-data with a version, as data can change between versions. Currently both python*-matplotlib only require %{name}-data without a version. - Which default backend should we use? I'd vote for GTKAgg, as GTK should be spread among most users of us already. If someone wants to use the qt4agg, one can install manually the -qt4 package and all the qt dependencies. See also #1030396. - How about testing the same backend in %check as using then by default? Shouldn't that happen anyway, as you set MATPLOTLIBDATA?
(In reply to Thomas Spura from comment #14) > (In reply to Paulo Andrade from comment #13) > > I plan to commit this patch. > > It adds some Debian patches, as it is basically what I was > > thinking about when asked for a bundling exception, but now > > using theirs (Debian) tested approach. Changes are basically: > > > > o Previous %{python_sitearch}/matplotlib/mpl-data was > > duplicated for python2 and python3, now it was made > > noarch and shared. > > o matplotlibrc was moved from .../mpl-data to /etc, and > > again shared by both python (this one may have issues > > if one wants to install 32 and 64 bit packages, what > > I believe is not a big issue, would file conflicts but > > file with same contents). The conflict cannot happen, I changed the package to noarch to avoid these problems, as the data is really noarch, but confused myself... > > o Fixed and enabled %check > > Thanks! > > > Only problem I see is that one will need to "rm -fr ~/.matplotlib" > > or will get back the errors about fonts not found. Not sure if > > should add some README or write something in %post to stdout. > > Why can this happen? It just worked over here without deleting my old config > (but maybe I have too less in it...). I will add an workaround for it. The cache is regenerated if TRAVIS is in os.environ, or if fontManager.__version__ (reloaded from picked cache) is different. Since I had already regenerated my cache with your build using fontconfig, it did not regenerate the cache, so I am planning something like s/__version__ = 101/__version__ = 101.1/ in font_manager.py > > If you have any comments, please let me know, otherwise > > I will "git push" and submit builds shortly. > > - It would be good to also require %{name}-data with a version, as data can > change between versions. Currently both python*-matplotlib only require > %{name}-data without a version. I will fix it, after uploading the patch and sample srpm, also corrected the fact that python-matplotlib-data was was not requring python-matplotlib-data-fonts (my mistake on the first try of the new approach). > - Which default backend should we use? I'd vote for GTKAgg, as GTK should be > spread among most users of us already. If someone wants to use the qt4agg, > one can install manually the -qt4 package and all the qt dependencies. > See also #1030396. > - How about testing the same backend in %check as using then by default? > Shouldn't that happen anyway, as you set MATPLOTLIBDATA? Ok, I think the easiest approach, in case it is changed again, is to copy setup.cfg to matplotlibrc used during %%check
python-matplotlib-1.3.1-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/python-matplotlib-1.3.1-2.fc20
Package python-matplotlib-1.3.1-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-matplotlib-1.3.1-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1804/python-matplotlib-1.3.1-2.fc20 then log in and leave karma (feedback).
The update package did the job for python-matplotlib, but python3-matplotlib still complains.
python-matplotlib-1.3.1-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.