matplotlib-devel Mailing List for matplotlib

On Thu, Jul 23, 2009 at 8:36 AM, Freddie Witherden <fr...@wi...>wrote:

> Hi all,
>
> With the integration of mathtex into matplotlib nearing completion
> (just bug fixes really) I think now is a good time to be considering
> the best way to include mathtex into matplotlib.
>
> This has already been discussed on the mathtex mailing list, with
> Michael proposing a few ways of doing this. However, I am not an
> expert by any means when it comes to Python set-up/configuring. (As
> anyone who has looked at setup.py in mathtex will have seen.)
>
> While including the source is not difficult (it can be done directly
> or using svn:external) getting it built/configured is. Lets say that
> mathtex was dumped into lib/, how would one go about configuring and
> installing it from setup.py in matplotlib.
>
> Although I am sure that just executing a shell command would do it I
> am sure there must be a 'better' option for this type of 'package
> chaining'.
>
> Does anyone have any suggestions or recommendations?
>
> Regards, Freddie.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Could you please the advantages of using mathtext? How does it compare and
contrast to the existing interface?

Any pointers to read before getting more lost?

Thanks,

-- 
Gökhan

There may be a setuptools solution here, but if there is, I'm not the 
one to know ;)  matplotlib is for the most part ignorant of setuptools, 
and it's probably reasonable to keep it that way.

Anyway, since the mathtex setup infrastructure is based on what 
matplotlib was already doing, there's a common convention we can 
exploit.  Essentially, the matplotlib setup.py builds up a list of 
extension modules (ext_modules) and packages and then passes those lists 
to distutils for building.  So, in theory, all mathtex needs to do is 
provide a function that will add extension modules and packages to those 
lists (basically like all of the build_* methods in setupext.py).  So 
basically, matplotlib's setup.py would import lib/mathtex/setupext.py 
(by filename) and call a method in it.  Lots of details I'm missing, but 
that should provide a general framework.

Another issue this raises is whether to build the FT2Font and png 
modules twice, once as part of matplotlib, and once as part of mathtex.  
Once mathtex is a truly external dependency for matplotlib, I don't see 
a way around this, so maybe we should just pretend we're already there, 
despite the duplication.  If we want to be clever, I could see mathtex 
being smart about imports: try importing its local copies of its 
libraries and failing that import matplotlib's.  I'm not entirely sure 
about that idea, but I sort of feel "hacky-if-you-do, 
hacky-if-you-don't" here ;) 

I see the code maintenance problem of this duplication (i.e. making sure 
bugfixes to FT2Font make it into matplotlib and mathtex) almost as a 
separate issue.  We know the solution to that: break out the freetype 
wrappers into its own project (which then both matplotlib and mathtex 
would rely on) -- but that's probably outside of the scope of this GSoC 
project.

Please try to use svn:externals if you can -- that will make pulling 
updates from mathtex easier.  I've never used it cross-repository like 
this, so there may be unforeseen issues.

It also just occurred to me that we might want to take another step in 
preparation for mathtex as an external dependency: make it optional.  
That is, if importing mathtex fails, be able to render regular text, and 
warn if trying to render math text.

Mike

Freddie Witherden wrote:
> Hi all,
>
> With the integration of mathtex into matplotlib nearing completion  
> (just bug fixes really) I think now is a good time to be considering  
> the best way to include mathtex into matplotlib.
>
> This has already been discussed on the mathtex mailing list, with  
> Michael proposing a few ways of doing this. However, I am not an  
> expert by any means when it comes to Python set-up/configuring. (As  
> anyone who has looked at setup.py in mathtex will have seen.)
>
> While including the source is not difficult (it can be done directly  
> or using svn:external) getting it built/configured is. Lets say that  
> mathtex was dumped into lib/, how would one go about configuring and  
> installing it from setup.py in matplotlib.
>
> Although I am sure that just executing a shell command would do it I  
> am sure there must be a 'better' option for this type of 'package  
> chaining'.
>
> Does anyone have any suggestions or recommendations?
>
> Regards, Freddie.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> 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

Hi all,

With the integration of mathtex into matplotlib nearing completion  
(just bug fixes really) I think now is a good time to be considering  
the best way to include mathtex into matplotlib.

This has already been discussed on the mathtex mailing list, with  
Michael proposing a few ways of doing this. However, I am not an  
expert by any means when it comes to Python set-up/configuring. (As  
anyone who has looked at setup.py in mathtex will have seen.)

While including the source is not difficult (it can be done directly  
or using svn:external) getting it built/configured is. Lets say that  
mathtex was dumped into lib/, how would one go about configuring and  
installing it from setup.py in matplotlib.

Although I am sure that just executing a shell command would do it I  
am sure there must be a 'better' option for this type of 'package  
chaining'.

Does anyone have any suggestions or recommendations?

Regards, Freddie.

Hi,

On 23 Jul 2009, at 03:34, John Hunter wrote:
> If experience is any guide, you won't hear from the people who depend
> on it until you remove support (plaintive pleas to the mailing list
> notwithstanding).  The old timers love their small PS files, and we
> support this because many people have asked for it.  I hesitate to
> remove support lacking compelling justification, though I prefer the
> embedded solution myself.

I am just pondering if it is a compelling enough reason to add support  
for it to mathtex -- as the only use for AFM support would be  
specifically for embedded PS/PDF fonts.

Would this be a valid alternative: bundling fonts with similar metrics  
as the PS fonts (we already have some unicode fonts in mathtex) and  
then on the matplotlib side choose not to embed such fonts. So mathtex  
works in terms of .ttf fonts, but at the matplotlib end of things it  
can opt not to embed them.

This way we retain support for the feature with no additional demands  
on mathtex.

Regards, Freddie.

Hi all,

I've been playing with pyglet and matplotlib integration using the Agg
backend as suggested some time ago on this list. The idea is to let
matplotlib do all the pretty stuff and let pyglet do the rendering of
images (currently, only imshow has been proxied).

Image rendering is done through GL texture using shaders for both
nearest/bilinear and bicubic filters and color LUT. Currently, this
allows to use matplotlib colormap with under/over colors but no bad
color yet.

Sources: http://www.loria.fr/~rougier/tmp/glumpy.tgz
Screenshot: http://www.loria.fr/~rougier/tmp/glumpy-matplotlib.png

Just run 'demo-matplotlib.py' and 'demo-matplotib-2.py' (implementation
of the dynamic_image.py animation demo).



Nicolas

On Wed, Jul 22, 2009 at 1:21 PM, Jouni K. Seppänen<jk...@ik...> wrote:
> Freddie Witherden <fr...@wi...> writes:
>
>> The question is how important are these as a feature? While I can add
>> support for them into mathtex I am unsure exactly how useful they are.

If experience is any guide, you won't hear from the people who depend
on it until you remove support (plaintive pleas to the mailing list
notwithstanding).  The old timers love their small PS files, and we
support this because many people have asked for it.  I hesitate to
remove support lacking compelling justification, though I prefer the
embedded solution myself.

JDH