Freddie Witherden wrote: > Hi, > > On 3 Aug 2009, at 17:39, Michael Droettboom wrote: > >> Is there an additional step to install mathtex? I thought the goal >> was to make "python setup.py install" work out of the box. >> > > This was the goal and I got quite close to achieving it. This latter > parts of this thread deal with the specific issues (relating to the > directory structure chosen) > http://sourceforge.net/mailarchive/forum.php?thread_name=A97F3AC6-1434-4E6D-AF39-9DBD4653BCB4%40witherden.org&forum_name=matplotlib-devel > > So I was advised by John to just assume mathtex is installed. > Thankfully this is not hard to do -- and is covered in the INSTALL > file. It is basically a case of changing to lib/mathtext and running > python setup.py build && python setup.py install. > Sorry, I let that message slide through. I know John may not be, but I'm really concerned about the build being anything more than "python setup.py install" -- it's going to be hard for packagers and hard for end users.
This problem is actually rather straightforward to solve using the "package_dir" mapping in distutils. See here: http://docs.python.org/distutils/setupscript.html#listing-whole-packages By adding {'mathtex': 'lib/mathtex/mathtex'} to package_dir, it all seems to work as desired. I've committed this change on the branch so you can see what I mean. However, after doing that I run into another error importing mathtex from mathtext_demo.py: > >>> from mathtex.mathtex_main import Mathtex > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File > "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/mathtex_main.py", > line 2, in <module> > from mathtex.parser import MathtexParser > File > "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/parser.py", line > 7, in <module> > from mathtex.boxmodel import * > File > "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/boxmodel.py", > line 4, in <module> > from mathtex.fonts import * > File "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/fonts.py", > line 5, in <module> > from mathtex.ft2font import FT2Font, KERNING_DEFAULT > ImportError: No module named ft2font It looks like it's still looking for ft2font inside of mathtex, which, of course, isn't there in the context of building in inside of matplotlib. I thought you said that mathtex would use the ft2font from matplotlib if it were available -- maybe I misunderstood what you meant. These sorts of installation issues are hard to test given that installs don't clean up after themselves. Personally, I use virtualenv to create "clean" python environments, then install matplotlib in it, and then try running examples in that environment. It's real fast to just blitz the environment and create a new one each time for this kind of testing. I was able to work around this (by installing mathtex directly), but I ran into the following because I have "mathtext.fontset" set up "stixsans" in my matplotlibrc: > python mathtext_demo.py Traceback (most recent call last): File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", line 352, in expose_event self._render_figure(self._pixmap, w, h) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", line 75, in _render_figure FigureCanvasAgg.draw(self) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 327, in draw self.figure.draw(self.renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/artist.py", line 46, in draw_wrapper draw(artist, renderer, *kl) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 774, in draw for a in self.axes: a.draw(renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/artist.py", line 46, in draw_wrapper draw(artist, renderer, *kl) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1721, in draw a.draw(renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/artist.py", line 46, in draw_wrapper draw(artist, renderer, *kl) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axis.py", line 757, in draw self.label.draw(renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/text.py", line 515, in draw bbox, info = self._get_layout(renderer) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/text.py", line 279, in _get_layout clean_line, self._fontproperties, ismath=ismath) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", line 169, in get_text_width_height_descent self.dpi, rcParams['mathtext.default']) File "/home/mdroe/usr/lib/python2.5/site-packages/mathtex/mathtex_main.py", line 30, in __init__ fontset = self.fontset_mapping[fontset](default_style) KeyError: 'stixsans' > /home/mdroe/usr/lib/python2.5/site-packages/mathtex/mathtex_main.py(30)__init__() -> fontset = self.fontset_mapping[fontset](default_style) I haven't looked into this further, but it would be nice not to change the font selection API of matplotlib unless there's a good reason. > The branch handles the checking out of mathtex from its svn repo > (svn:externals) and any system that can build matplotlib can also > build mathtex. Currently the HEAD revision is checked out. This is > easy to change. > That's good for now while everything is in flux. Eventually, we may want to pin it to a particular revision so that updates of mathtex into matplotlib are explicitly tested. The Subversion manual makes a good argument for this: "You should seriously consider using explicit revision numbers in all of your externals definitions. Doing so means that you get to decide when to pull down a different snapshot of external information, and exactly which snapshot to pull. Besides avoiding the surprise of getting changes to third-party repositories that you might not have any control over, using explicit revision numbers also means that as you backdate your working copy to a previous revision, your externals definitions will also revert to the way they looked in that previous revision, which in turn means that the external working copies will be updated to match the way /they/ looked back when your repository was at that previous revision. For software projects, this could be the difference between a successful and a failed build of an older snapshot of your complex codebase." But I don't know if it matters to do this until the matplotlib/mathtex branch is merged back into the trunk. > There is a slight performance penalty associated with using mathtex -- > due to each expression being parsed twice -- where matplotlib caches > parsed expressions. If this is a problem let me know and I'll work on > something. > It would be great to preserve the caching behavior, even if that lives in the matplotlib side and not in the mathtex project itself. Where it matters is with interactive panning and zooming: if the tick labels use math, as in a log plot for example, they can get re-renderered many times. I recall benchmarking it at the time I did the big math re-write, and it was definitely worth worrying about at the time, though I can't find my notes. If you benchmark and come to a different conclusion (because things have become faster in other ways) just let us know. Cheers, Mike > Regards, Freddie. > > ------------------------------------------------------------------------------ > 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 > -- 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
