Hi all,
I have just finished going over the mathtex branch and it appears to be totally feature complete. Furthermore, by using the newest version of mathtex it also benefits from the recent rendering improvements.
I am therefore interested to hear peoples comments on it/what can be improved. Furthermore, would it be worthwhile back-porting some of the rendering changes/enhancements I've made to mathtex to matplotlib? (Which I am more than happy to do.)
Regards, Freddie.
I just did a clean install into a new virtualenv and I get the following when running mathtext_demo.py:
/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py:165: UserWarning: matplotlib was compiled without mathtex support. Math will not be rendered.
'Math will not be rendered.')
Is there an additional step to install mathtex? I thought the goal was to make "python setup.py install" work out of the box.
Cheers,
Mike
Freddie Witherden wrote:
Hi all,
I have just finished going over the mathtex branch and it appears to be totally feature complete. Furthermore, by using the newest version of mathtex it also benefits from the recent rendering improvements.
I am therefore interested to hear peoples comments on it/what can be improved. Furthermore, would it be worthwhile back-porting some of the rendering changes/enhancements I've made to mathtex to matplotlib? (Which I am more than happy to do.)
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
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Hi,
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) Thread: [matplotlib-devel] Including mathtex in matplotlib | matplotlib
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.
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.
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.
Regards, Freddie.
On 3 Aug 2009, at 17:39, Michael Droettboom wrote:
Freddie Witherden wrote:
Hi,
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) Thread: [matplotlib-devel] Including mathtex in matplotlib | matplotlibSo 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
On 3 Aug 2009, at 17:39, Michael Droettboom wrote:
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
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Hi,
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 ft2fontIt 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.
fonts.py seemed to slip the net, somehow, and will not try to fallback on matplotlib. Easy to fix.
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.
Yes, I've been bitten by that several times now. I'll look into virtualenv, might save me some headaches.
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:
I, for some reason, never ported stixsans over. Again easy to do and shouldn't take long. The stix and bakoma fonts currently work and unicode support is in mathtex, just needs some support code in matplotlib.
But I don't know if it matters to do this until the matplotlib/mathtex branch is merged back into the trunk.
It is probably wroth doing it as soon as mathtex has a couple of stable releases behind it.
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.
It is probably easiest if I add it to the Mathtex class itself. Parsing is currently the biggest bottle-neck even with packrat parsing enabled. I did try zooming around the mathtext demo plot and found there to be quite a lot of lag, so it does seem worth it.
Overall I think the best plan of action is to add caching support and stixsans into mathtex, fix the error with imports and then release version 0.2 of mathtex. Then matplotlib can be updated (and set to pull 0.2 from subversion).
Regards, Freddie.
On 4 Aug 2009, at 14:12, Michael Droettboom wrote: