matplotlib-devel Mailing List for matplotlib

On Fri, Aug 31, 2007 at 03:32:09PM -0400, Michael Droettboom wrote:
> And placing bitmaps in menu items reportedly doesn't work at all on 
> wxCocoa. -- so maybe it's best to stay away from that altogether.
The wxPython demo.py for menus has a smiley face bit map that displays
just fine. Let me know if you want a screen shot.
	- Paul

On Fri, Aug 31, 2007 at 03:28:49PM -0400, Michael Droettboom wrote:
> There is now preliminary support for getting a mathtext bitmap to 
> transfer to a GUI widget in SVN, along with a toy wxPython example in 
> examples/mathtext_wx.py. I've only tested this on 
> Linux/wxGTK2/wxPython-2.8. I'd appreciate help with testing (and 
> screenshots) on any other platforms you may care about.
That's wonderful! I'm attaching a screen shot for wx 2.8 on OS/X.
The rendering is kind of ugly, but I haven't looked into it.
	- Paul

I should also mention my mathtext_wx.py example reveals a [possible] bug 
in wxPython-2.8 and/or the underlying Gtk. When you put a bitmap on a 
menu item, the *height* of the menu item is determined by the *width* of 
the bitmap.
And placing bitmaps in menu items reportedly doesn't work at all on 
wxCocoa. -- so maybe it's best to stay away from that altogether.
Cheers,
Mike
Michael Droettboom wrote:
> There is now preliminary support for getting a mathtext bitmap to 
> transfer to a GUI widget in SVN, along with a toy wxPython example in 
> examples/mathtext_wx.py. I've only tested this on 
> Linux/wxGTK2/wxPython-2.8. I'd appreciate help with testing (and 
> screenshots) on any other platforms you may care about.
> 
> Gtk+ and Qt should also be theoretically possible. Tk will be more 
> difficult, because a) it doesn't support an alpha channel (which would 
> mainly be a quality problem), and b) you have to use the _tkagg C++ 
> bridge to get the image data into a widget.
> 
> Be aware that the API for this may change due to my planned 
> mathtext/backend communication refactoring. If you do plan on relying 
> on this functionality, I recommend wrapping it in a function (like 
> mathtext_to_wxbitmap in the example) so any future changes will be 
> localized.
> 
> Cheers,
> Mike
> 
> Michael Droettboom wrote:
>> Cool idea. I don't know if anyone has tried this. I assume you'd 
>> want to get something that you could pass to wx.ImageFromBuffer() (and 
>> the equivalent in Gtk). It would just be a matter of or'ing together 
>> all of the greyscale ft2font buffers (which aren't currently exposed 
>> to Python) and converting them to an RGB buffer and Alpha buffer. Not 
>> that difficult, but it would require some additional C routines in 
>> ft2font.cpp.
>>
>> (And long term, as cool as matplotlib is, it would be nice to refactor 
>> this out as a separate library for apps that don't do any plotting...)
>>
>> Cheers,
>> Mike
>>
>> Paul Kienzle wrote:
>>> Hi,
>>>
>>> It would be great to be able to display math markup in other parts of my
>>> application, such as labels, tables, lists and menus. Has anyone ever
>>> tried doing this for wx or gtk?
>>>
>>> Thanks in advance,
>>>
>>> - Paul
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems? Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 

There is now preliminary support for getting a mathtext bitmap to 
transfer to a GUI widget in SVN, along with a toy wxPython example in 
examples/mathtext_wx.py. I've only tested this on 
Linux/wxGTK2/wxPython-2.8. I'd appreciate help with testing (and 
screenshots) on any other platforms you may care about.
Gtk+ and Qt should also be theoretically possible. Tk will be more 
difficult, because a) it doesn't support an alpha channel (which would 
mainly be a quality problem), and b) you have to use the _tkagg C++ 
bridge to get the image data into a widget.
Be aware that the API for this may change due to my planned 
mathtext/backend communication refactoring. If you do plan on relying 
on this functionality, I recommend wrapping it in a function (like 
mathtext_to_wxbitmap in the example) so any future changes will be 
localized.
Cheers,
Mike
Michael Droettboom wrote:
> Cool idea. I don't know if anyone has tried this. I assume you'd want 
> to get something that you could pass to wx.ImageFromBuffer() (and the 
> equivalent in Gtk). It would just be a matter of or'ing together all of 
> the greyscale ft2font buffers (which aren't currently exposed to Python) 
> and converting them to an RGB buffer and Alpha buffer. Not that 
> difficult, but it would require some additional C routines in ft2font.cpp.
> 
> (And long term, as cool as matplotlib is, it would be nice to refactor 
> this out as a separate library for apps that don't do any plotting...)
> 
> Cheers,
> Mike
> 
> Paul Kienzle wrote:
>> Hi,
>>
>> It would be great to be able to display math markup in other parts of my
>> application, such as labels, tables, lists and menus. Has anyone ever
>> tried doing this for wx or gtk?
>>
>> Thanks in advance,
>>
>> 	- Paul
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

It would probably be considerable work to ply mathtext out of matplotlib, particularly if you consider bringing along the Ps/Pdf/Svg/Cairo backends. Just bringing the raster backend (which is really in ft2font.cpp) would be considerably less work.
But I was mainly just sharing a "wouldn't it be cool if...". Separating mathtext would be a project unto itself.
Cheers,
Mike

Hello,
it seems that there are two minor bugs in matplotlib concerning the 
logspace function.
1) line 93 of mlab.py:
def logspace(xmin,xmax,N):
 return exp(linspace(log(xmin), log(xmax),Nh))
- should be N or Nh in the both lines;
2) pylab does not import logspace at all:
line 293 of pylab.py:
from matplotlib.mlab import linspace, ...
- should be
from matplotlib.mlab import linspace, logspace, ...
I have just found matplotlib, and it seems to me that it is very good 
and promising product, albeit not yet as polished as octave/gnuplot 
pair. The mathtext feature which eliminates all hassles with psfrag is 
especially useful.
Best wishes,
Farid.

On Thu, Aug 30, 2007 at 01:56:36PM -0500, John Hunter wrote:
> On 8/30/07, Michael Droettboom <md...@st...> wrote:
> 
> > (And long term, as cool as matplotlib is, it would be nice to refactor
> > this out as a separate library for apps that don't do any plotting...)
> 
> I agree, the mathtext stuff is becoming really good, and will be
> really good when we have a good set of fonts to work with. I can see
> it being useful in lots of contexts, and more users in other contexts
> will make it more useful for us down the road.
The challenge is to separate the backends from matplotlib.
If mathtext takes over all of the font handling then matplotlib won't need
to include freetype. If matplotlib handles bitmap rotation, then mathtext
won't need to include agg. Then mathtext need only take the format string
and return a bounding box, a bitmap, or the PDF/PS/SVG instructions
necessary to render the text.
I don't know if PDF/PS/SVG can rotate the coordinate system prior to
rendering. If not, then rotation will need to be moved into mathtext
as well.
	- Paul

Paul Kienzle wrote:
> It would be great to be able to display math markup in other parts of my
> application, such as labels, tables, lists and menus. Has anyone ever
> tried doing this for wx or gtk?
It's worth a post to the wxPython-users list -- it gets talked about now 
and again.
It shouldn't be too hard to use the ustex stuff from MPL -- doesn't that 
use TeX, etc to make a png or something? If so, it could be stuck on a 
wx.widget easily.
Michael Droettboom wrote:
> (And long term, as cool as matplotlib is, it would be nice to refactor 
> this out as a separate library for apps that don't do any plotting...)
Yes, that would be great -- a kind of mini-TeX that's embeddable. 
Another plus to that is you'd expand the user base, and with that 
hopefully the developer base, so it could get fuller featured faster.
How tied in with MPL is the code? Could it just be it's own module?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Paul Kienzle wrote:
> On Thu, Aug 30, 2007 at 02:19:47PM -0400, Michael Droettboom wrote:
>> Paul Kienzle wrote:
>>> Hi all,
>>> Before I look to deeply into this myself, is there anyone working on it 
>>> already? Is there anything I need to look out for when implementing it?
>> I've made a few excursions down that road --
>>
>> For bitmap font rendering, the entire math expression is first laid out 
>> in a greyscale bitmap buffer, which is cached and then transferred to 
>> the main plot bitmap. It was already that way when I got here, and I 
>> assume that's an important optimization (so the text doesn't have to be 
>> re-laid-out when the plot is zoomed/panned). I say "perhaps" because I 
>> have no data to back it up, and don't know if that came out of profiling 
>> or not.
>>
>> There are a few key low level pieces that are missing for rotation:
>>
>> - FT2Font.draw_glyph_to_bitmap does not support rotation. This would 
>> have to be added, or there may be a way to use 
>> set_text/draw_glyphs_to_bitmap which does support rotation. However, 
>> that would make rendering the entire expression to a single buffer much 
>> more difficult.
> 
> Adding rotation to draw_glyph_to_bitmap looks like the easier option...
 >
>> - The horizontal lines are all drawn as filled rectangles aligned to the 
>> pixel grid, directly into the font buffers. That will probably have to 
>> be pushed upward into the Agg layer to get good line drawing at 
>> arbitrary angles -- but that also makes caching the bitmap a little more 
>> difficult. So maybe it makes sense to implement our own Breshenham's 
>> algorithm in ft2font.cpp.
> 
> ...but if we need to go into agg anyway, why not use Agg's font handling
> capabilities directly?
Perhaps historical reasons. I wonder if they're still relevant.
>> All this will be affected by John's proposed refactoring of the 
>> backends, of course, which has kind of kept me off of it in a "wait and 
>> see" kind of mode. Right now, each backend has a custom interface to 
>> communicate with mathtext -- whereas mathtext should simply be calling 
>> the same low-level methods on all backends to get its job done. That, 
>> of course, would make this buffer optimization harder (or at least it 
>> would have to be thought about differently).
> 
> I haven't followed the refactoring proposal close enough to know if it
> makes more sense to implement mathtext via freetype in agg or to use
> freetype directly like you are currently doing. Once that decision is
> clear, we can certainly prototype the handling of rotated text in the Agg
> backend.
> 
> Presumably this will have to be repeated for Cairo.
Cairo already works, as of a few weeks ago, it no longer uses bitmaps 
for mathtext rendering. (I should have been more clear earlier -- my 
brain has it filed in with the vector backends, though obviously it has 
a resterizer.)
>> Let me know if you decide to implement this and let me know if you have 
>> any questions about the code. Otherwise I'm happy to add it to my queue.
> 
> I can get by for now with limited text rotation, at least until the
> backend refactoring has settled.
That may be a while (re: John's latest message). In the meantime, I'm 
going to explore, as he suggested, how bad doing a raster rotation would 
look, as that's the easiest path forward.
Cheers,
Mike

On Thu, Aug 30, 2007 at 02:19:47PM -0400, Michael Droettboom wrote:
> Paul Kienzle wrote:
> > Hi all,
> > 
> > I replaced one of the text_rotation examples with r'$\rm{mathtext_{225}}$'
> > to see if rotation is supported for mathtext. It is not in the current
> > trunk downloaded today.
> 
> It's only not supported in the bitmap (Agg and Gdk) backends. It works 
> fine in the vector backends.
Okay. wxAgg works with 90ドル^\circ$ rotations as well. This will work for
me short term (though 45ドル^\circ$ is better).
> > Before I look to deeply into this myself, is there anyone working on it 
> > already? Is there anything I need to look out for when implementing it?
> 
> I've made a few excursions down that road --
> 
> For bitmap font rendering, the entire math expression is first laid out 
> in a greyscale bitmap buffer, which is cached and then transferred to 
> the main plot bitmap. It was already that way when I got here, and I 
> assume that's an important optimization (so the text doesn't have to be 
> re-laid-out when the plot is zoomed/panned). I say "perhaps" because I 
> have no data to back it up, and don't know if that came out of profiling 
> or not.
> 
> There are a few key low level pieces that are missing for rotation:
> 
> - FT2Font.draw_glyph_to_bitmap does not support rotation. This would 
> have to be added, or there may be a way to use 
> set_text/draw_glyphs_to_bitmap which does support rotation. However, 
> that would make rendering the entire expression to a single buffer much 
> more difficult.
Adding rotation to draw_glyph_to_bitmap looks like the easier option...
> 
> - The horizontal lines are all drawn as filled rectangles aligned to the 
> pixel grid, directly into the font buffers. That will probably have to 
> be pushed upward into the Agg layer to get good line drawing at 
> arbitrary angles -- but that also makes caching the bitmap a little more 
> difficult. So maybe it makes sense to implement our own Breshenham's 
> algorithm in ft2font.cpp.
...but if we need to go into agg anyway, why not use Agg's font handling
capabilities directly?
> 
> All this will be affected by John's proposed refactoring of the 
> backends, of course, which has kind of kept me off of it in a "wait and 
> see" kind of mode. Right now, each backend has a custom interface to 
> communicate with mathtext -- whereas mathtext should simply be calling 
> the same low-level methods on all backends to get its job done. That, 
> of course, would make this buffer optimization harder (or at least it 
> would have to be thought about differently).
I haven't followed the refactoring proposal close enough to know if it
makes more sense to implement mathtext via freetype in agg or to use
freetype directly like you are currently doing. Once that decision is
clear, we can certainly prototype the handling of rotated text in the Agg
backend.
Presumably this will have to be repeated for Cairo.
> 
> Let me know if you decide to implement this and let me know if you have 
> any questions about the code. Otherwise I'm happy to add it to my queue.
I can get by for now with limited text rotation, at least until the
backend refactoring has settled.
 - Paul

I just committed code to allow vertical alignment of text by the 
baseline (rather than the bottom of all the descenders).
I think it should be useful, however, it behaves rather strangely with 
rotation, and I thought I'd solicit some feedback from the list.
The "problem" (if it is one) is that halignment and valignment don't 
rotate along with the text (and there's lots of good reasons why it 
doesn't.) However, when you rotate text by 90 degrees, does that mean 
you would want the baseline to be horizontally aligned to the baseline? 
 Does this suggest that baseline alignment is not really a property of 
valignment? But then what do you do with non-rectilinear rotations?
Does this even matter? Is it good enough to just ignore the rotation 
problems?
Cheers,
Mike

John Hunter wrote:
> On 8/30/07, Michael Droettboom <md...@st...> wrote:
> 
>> - FT2Font.draw_glyph_to_bitmap does not support rotation. This would
>> have to be added, or there may be a way to use
>> set_text/draw_glyphs_to_bitmap which does support rotation. However,
>> that would make rendering the entire expression to a single buffer much
>> more difficult.
> 
> I was envisioning simply rotating the entire text expression by
> rotating the ft2font pixel buffer. Agg could do this and still
> preserve subpixel effects, but we would need to expose a little code
> (presumably in the agg SWIG module). 
I was concerned about loss of quality doing the rotation in raster 
space, particularly due to all of the trouble to get the hinting just 
right. (Though I'm not sure how much hinting to a grid matters when the 
glyphs aren't actually parallel with the grid anymore.)
I suppose it's worth some experimentation, though, as that is definitely 
the path of least resistance.
> One couldn't rotate individual
> glyphs in a larger expression this way, but by far the most common
> use case is to rotate the entire expression so this limitation doesn't
> concern me much.
Agreed. My usual response is: TeX doesn't support it, so why should we? ;)
Cheers,
Mike

On 8/30/07, Michael Droettboom <md...@st...> wrote:
> (And long term, as cool as matplotlib is, it would be nice to refactor
> this out as a separate library for apps that don't do any plotting...)
I agree, the mathtext stuff is becoming really good, and will be
really good when we have a good set of fonts to work with. I can see
it being useful in lots of contexts, and more users in other contexts
will make it more useful for us down the road.
JDH

On 8/30/07, Michael Droettboom <md...@st...> wrote:
> - FT2Font.draw_glyph_to_bitmap does not support rotation. This would
> have to be added, or there may be a way to use
> set_text/draw_glyphs_to_bitmap which does support rotation. However,
> that would make rendering the entire expression to a single buffer much
> more difficult.
I was envisioning simply rotating the entire text expression by
rotating the ft2font pixel buffer. Agg could do this and still
preserve subpixel effects, but we would need to expose a little code
(presumably in the agg SWIG module). One couldn't rotate individual
glyphs in a larger expression this way, but by far the most common
use case is to rotate the entire expression so this limitation doesn't
concern me much.
> All this will be affected by John's proposed refactoring of the
> backends, of course, which has kind of kept me off of it in a "wait and
> see" kind of mode. Right now, each backend has a custom interface to
The rest of my life has intervened a bit here and I hope to return to
the refactoring soon, but I don't think it should hold you up.
Despite my initial revolutionary fervor, I have tempered a bit, and
favor a more integrationist approach than espoused in some of my
original emails on mpl1. So if you have an approach that will improve
the backend mathtext handling, by all means go for it and we will
incorporate this into further revisions.
JDH

Cool idea. I don't know if anyone has tried this. I assume you'd want 
to get something that you could pass to wx.ImageFromBuffer() (and the 
equivalent in Gtk). It would just be a matter of or'ing together all of 
the greyscale ft2font buffers (which aren't currently exposed to Python) 
and converting them to an RGB buffer and Alpha buffer. Not that 
difficult, but it would require some additional C routines in ft2font.cpp.
(And long term, as cool as matplotlib is, it would be nice to refactor 
this out as a separate library for apps that don't do any plotting...)
Cheers,
Mike
Paul Kienzle wrote:
> Hi,
> 
> It would be great to be able to display math markup in other parts of my
> application, such as labels, tables, lists and menus. Has anyone ever
> tried doing this for wx or gtk?
> 
> Thanks in advance,
> 
> 	- Paul
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Paul Kienzle wrote:
> Hi all,
> 
> I replaced one of the text_rotation examples with r'$\rm{mathtext_{225}}$'
> to see if rotation is supported for mathtext. It is not in the current
> trunk downloaded today.
It's only not supported in the bitmap (Agg and Gdk) backends. It works 
fine in the vector backends.
> Before I look to deeply into this myself, is there anyone working on it 
> already? Is there anything I need to look out for when implementing it?
I've made a few excursions down that road --
For bitmap font rendering, the entire math expression is first laid out 
in a greyscale bitmap buffer, which is cached and then transferred to 
the main plot bitmap. It was already that way when I got here, and I 
assume that's an important optimization (so the text doesn't have to be 
re-laid-out when the plot is zoomed/panned). I say "perhaps" because I 
have no data to back it up, and don't know if that came out of profiling 
or not.
There are a few key low level pieces that are missing for rotation:
- FT2Font.draw_glyph_to_bitmap does not support rotation. This would 
have to be added, or there may be a way to use 
set_text/draw_glyphs_to_bitmap which does support rotation. However, 
that would make rendering the entire expression to a single buffer much 
more difficult.
- The horizontal lines are all drawn as filled rectangles aligned to the 
pixel grid, directly into the font buffers. That will probably have to 
be pushed upward into the Agg layer to get good line drawing at 
arbitrary angles -- but that also makes caching the bitmap a little more 
difficult. So maybe it makes sense to implement our own Breshenham's 
algorithm in ft2font.cpp.
All this will be affected by John's proposed refactoring of the 
backends, of course, which has kind of kept me off of it in a "wait and 
see" kind of mode. Right now, each backend has a custom interface to 
communicate with mathtext -- whereas mathtext should simply be calling 
the same low-level methods on all backends to get its job done. That, 
of course, would make this buffer optimization harder (or at least it 
would have to be thought about differently).
Let me know if you decide to implement this and let me know if you have 
any questions about the code. Otherwise I'm happy to add it to my queue.
Cheers,
Mike

Hi,
It would be great to be able to display math markup in other parts of my
application, such as labels, tables, lists and menus. Has anyone ever
tried doing this for wx or gtk?
Thanks in advance,
	- Paul

Hi all,
I replaced one of the text_rotation examples with r'$\rm{mathtext_{225}}$'
to see if rotation is supported for mathtext. It is not in the current
trunk downloaded today.
Before I look to deeply into this myself, is there anyone working on it 
already? Is there anything I need to look out for when implementing it?
Thanks in advance...
	- Paul

On Aug 29, 2007, at 5:12 PM, Hardeep Nahal wrote:
>
> Yes, I think my libpng library was corrupt, but when I tried
> reinstalling, it still wouldn't work.
It's not corrupt, it's just not the correct kind of library. There 
are two types: static libraries (.a), which get compiled into a 
program, and shared libraries (.so), which are stored outside of the 
program. Trying to compile a shared library that uses a static 
library is always a bit dodgy and sometimes fails completely. If you 
really need to use your own copy of libpng you should re-run the 
configure script with the "--enable-shared" option and then 
recompile. Since you're using Debian I'd advise you to just use the 
libraries it provides whenever possible. That ought to make your 
life easier.
> It appears the matplotlib and numpy packages that come with Debian are
> incompatible.
I have been unable to reproduce the problem you were having with the 
Debian matplotlib and numpy packages. I'd appreciate more details 
about the packages you had installed, if you don't mind breaking your 
system again briefly. Could you please reinstall them, verify that 
the problem still occurs, and then email me the output of the 
following four commands? If you don't have time to work on this 
right now don't worry about it.
Here are the commands which will provide me with the information I 
require:
	$ cat /etc/debian_version
	$ dpkg -s python
	$ dpkg -s python-numpy
	$ dpkg -s python-numarray
Thanks,
Ken

Yes, I think my libpng library was corrupt, but when I tried 
reinstalling, it still wouldn't work. So I deleted it, as Ken 
suggested, and it worked. I think it wasn't finding the default 
libpng, and was going straight to the corrupted version. I spent the 
whole day trying to figure this out! ;P , so thank you very much Ken 
and Jouni for your suggestions.
It appears the matplotlib and numpy packages that come with Debian are 
incompatible. But I installed matplotlib 0.90.1 and numpy 1.0.3-2 on 
my own, and after fixing that libpng error, they appear to be 
compatible.
Hardeep
Quoting Ken McIvor <mc...@ii...>:
> On Aug 29, 2007, at 1:59 PM, Hardeep Nahal wrote:
>>
>> build/temp.linux-x86_64-2.3/src/_na_backend_agg.o -L/usr/local/lib
>> -L/usr/lib -L/usr/lib64 -L/usr/local/lib -L/usr/lib -L/usr/lib64 -lpng
>> -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o
>> build/lib.linux-x86_64-2.3/matplotlib/backends/_na_backend_agg.so
>> /usr/bin/ld: /usr/local/lib/libpng.a(png.o): relocation R_X86_64_32
>> against `a local symbol' can not be used when making a shared object;
>> recompile with -fPIC
>> /usr/local/lib/libpng.a: could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>> error: command 'c++' failed with exit status 1
>
> You need to either recompile libpng so it builds a shared library or
> delete `/usr/local/lib/libpng.a' so gcc picks up the default version
> provided by Debian.
>
>> I think this Debian distribution of matplotlib (which is older than
>> the current release) is incompatible with the current version of
>> numpy/Numeric that I have installed, but I'm not sure. I would rather
>> have the latest matplotlib vesrion installed (version 0.90.1), but I
>> can't seem to get it to even build properly.
>
> Did you install your own copy of numpy or are you using the one that
> comes with Debian? If you're using the one that comes with Debian,
> I'll try to reproduce the problem and file a bug report.
>
> Ken

On Aug 29, 2007, at 1:59 PM, Hardeep Nahal wrote:
>
> build/temp.linux-x86_64-2.3/src/_na_backend_agg.o -L/usr/local/lib
> -L/usr/lib -L/usr/lib64 -L/usr/local/lib -L/usr/lib -L/usr/lib64 -lpng
> -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o
> build/lib.linux-x86_64-2.3/matplotlib/backends/_na_backend_agg.so
> /usr/bin/ld: /usr/local/lib/libpng.a(png.o): relocation R_X86_64_32
> against `a local symbol' can not be used when making a shared object;
> recompile with -fPIC
> /usr/local/lib/libpng.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> error: command 'c++' failed with exit status 1
You need to either recompile libpng so it builds a shared library or 
delete `/usr/local/lib/libpng.a' so gcc picks up the default version 
provided by Debian.
> I think this Debian distribution of matplotlib (which is older than
> the current release) is incompatible with the current version of
> numpy/Numeric that I have installed, but I'm not sure. I would rather
> have the latest matplotlib vesrion installed (version 0.90.1), but I
> can't seem to get it to even build properly.
Did you install your own copy of numpy or are you using the one that 
comes with Debian? If you're using the one that comes with Debian, 
I'll try to reproduce the problem and file a bug report.
Ken

On 8/21/07, Michael Droettboom <md...@st...> wrote:
> Darren Dale wrote:
> >> I'm concerned about consistency and/or redundancy between this and the
> >> new markup kwarg. I don't know whether or not "usetex" being
> >> "all-or-nothing" is desirable. But we could meet in the middle by doing
> >> one of the following:
> >>
> >> a) only send text to LaTeX for rendering when text.usetex=True and
> >> markup="tex". (Which makes usetex=True behave a little more like
> >> usetex=False).
> >
> > This seems like a bad idea. If I want to use tex as my text layout engine, now
> > I have two settings to keep track of. We'll get lots of posts asking why
> > latex is not being used when usetex is True.
>
> I agree with this point. My counter-worry is that people may be
> surprised when their dollar signs behave differently when usetex is on
> or off. Maybe people don't change that setting all that often in
> practice, though... We could (and I'm not necessarily advocate this),
> pre-process the string sent to LaTeX when usetex is True and markup ==
> 'plain', so that the dollar signs are escaped (and will appear as dollar
> signs in the output).
>
> >> b) add another value to markup, to render text with LaTeX. (If we
> >> do, I would suggest changing the kwarg to "text_renderer" and having the
> >> values be "normal", "mathtext" and "latex" or something)
> >
> > This seems reasonable. Although, if we make it so latex can be used to layout
> > some text but not others, I worry that we will get no end of posts
> > complaining about how the latex fonts dont match the mathtext or normal
> > fonts.
>
> Agreed.
>
> >> c) make markup="tex" be all-or-nothing as well (that is, keep the
> >> rcParam, but drop the kwarg.) With this flag, you're basically saying
> >> "I know how to deal with $'s".
> >>
> >> b) is probably the most flexible (maybe too flexible, as I can't see why
> >> one would want to use all three types of rendering in the same plot).
> >> a) and b) would break backward compatibility with 0.90.1, while c) would
> >> not.
> >>
> >> Any thoughts?
> >
> > I think b) fits best. Maybe backward compatibility can be maintained. usetex
> > would be deprecated, and would set the text_renderer rcParam to latex when
> > True.
>
> That seems like a good approach, if we go with option b).
>
> > Or does 0.90.1 already have the markup kwarg?
>
> The markup kwarg is only a couple weeks old.
>
> > Again, there must be a
> > way. The new validation mechanism in rcParams (not traits, the stuff I did
> > right before traits) could probably provide a route for transition without
> > actually breaking anything.
>
> Good point.
>
> > I am pretty busy this week at work, and will be
> > on vacation for 11 days starting August 24, just letting you know.
>
> Thanks. I don't think there's a huge rush to decide this (the
> implementation should be straightforward no matter what we decide). But
> it would make sense to sort this out before the next release.
Sorry to jump in late on this discussion again -- I was just trying to
use the new mathtext and ran into this use case
ax.plot(something, label=r'$\alpha=1'$)
ax.legend()
Paul mentioned earlier in his objection to the markup kwarg that
legend would be a problem, and there will probably be other cases too.
 I suggested once before that we adopt something like the following
rule:
 if a string has one dollar sign, treat it as plain text. If it has
more that one unquoted dollar sign, treat it as TeX, and use mathtext
or usetex depending on rc.
I know Eric objected that this kind of complexity can make things
unpleasant and lead to some difficult to debug oddities, but I think
this is a case where convenience trumps complexity. I would like the
rescind my earlier vote (now that I am trying to actually use this
stuff for real work) and support mathtext w/o kwark markup.
To support the use case above with svn, will I need to get the text
instances back from the legend and set the markup property on them?
JDH

Hardeep Nahal <na...@cs...> writes:
> /usr/bin/ld: /usr/local/lib/libpng.a(png.o): relocation R_X86_64_32
> against `a local symbol' can not be used when making a shared object;
> recompile with -fPIC
That sounds like your libpng library is broken. Since it is in
/usr/local/lib, it is probably not provided by Debian but installed by
yourself. Doesn't Debian provide libpng?
> ImportError: cannot import name Int8
>
> I think this Debian distribution of matplotlib (which is older than 
> the current release) is incompatible with the current version of 
> numpy/Numeric that I have installed, but I'm not sure. 
Yes. I think there was a period when you had to match versions of numpy
and matplotlib quite closely. Modern numpy does not have Int8, so you
cannot use that version of matplotlib with that version of numpy.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
I have been having problems trying to install matplotlib properly on 
our server. Our environment is Debian 4.1.1-21, Python2.4 , and I have 
installed all the required modules (numpy, Numeric etc). I originally 
tried installing matplotlib from source, but the build was 
unsuccessful. I was getting this error when I tried building 
matplotlib-0.90.1:
python setup.py build
building for GTK requires pygtk; you must be able to "import gtk" in 
your build/install environment
TKAgg requires TkInter
running build
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc ->
build/lib.linux-x86_64-2.3/matplotlib/mpl-data
running build_ext
building 'matplotlib.backends._na_backend_agg' extension
c++ -pthread -shared
build/temp.linux-x86_64-2.3/agg23/src/agg_trans_affine.o
build/temp.linux-x86_64-2.3/agg23/src/agg_path_storage.o
build/temp.linux-x86_64-2.3/agg23/src/agg_bezier_arc.o
build/temp.linux-x86_64-2.3/agg23/src/agg_curves.o
build/temp.linux-x86_64-2.3/agg23/src/agg_vcgen_dash.o
build/temp.linux-x86_64-2.3/agg23/src/agg_vcgen_stroke.o
build/temp.linux-x86_64-2.3/agg23/src/agg_rasterizer_scanline_aa.o
build/temp.linux-x86_64-2.3/agg23/src/agg_image_filters.o
build/temp.linux-x86_64-2.3/src/_image.o
build/temp.linux-x86_64-2.3/src/ft2font.o
build/temp.linux-x86_64-2.3/src/mplutils.o
build/temp.linux-x86_64-2.3/CXX/IndirectPythonInterface.o
build/temp.linux-x86_64-2.3/CXX/cxx_extensions.o
build/temp.linux-x86_64-2.3/CXX/cxxsupport.o
build/temp.linux-x86_64-2.3/CXX/cxxextensions.o
build/temp.linux-x86_64-2.3/src/_na_backend_agg.o -L/usr/local/lib
-L/usr/lib -L/usr/lib64 -L/usr/local/lib -L/usr/lib -L/usr/lib64 -lpng
-lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o
build/lib.linux-x86_64-2.3/matplotlib/backends/_na_backend_agg.so
/usr/bin/ld: /usr/local/lib/libpng.a(png.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
/usr/local/lib/libpng.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'c++' failed with exit status 1
So I tried installing matplotlib from distribution (ie. using apt-get 
install python-matplotlib), thinking it may work instead of me trying 
to manually install it. The distribution installs matplotlib-0.87.7, 
which is older than the current version available by source. And it 
seemed to compile fine without any errors. However, when I try to 
import pylab using python command line, I get this error:
import matplotlib
import pylab
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "matplotlib/pylab.py", line 197, in ?
 import cm
 File "matplotlib/cm.py", line 5, in ?
 import colors
 File "matplotlib/colors.py", line 33, in ?
 from numerix import array, arange, take, put, Float, Int, where, \
 File "matplotlib/numerix/__init__.py", line 75, in ?
 from _sp_imports import nx, infinity, rand, randn, isnan, all, any
 File "matplotlib/numerix/_sp_imports.py", line 9, in ?
 from numpy import Int8, UInt8, \
ImportError: cannot import name Int8
I think this Debian distribution of matplotlib (which is older than 
the current release) is incompatible with the current version of 
numpy/Numeric that I have installed, but I'm not sure. I would rather 
have the latest matplotlib vesrion installed (version 0.90.1), but I 
can't seem to get it to even build properly.
I'm stumped and I'm hoping someone has an idea why I might be getting 
this error, and how I can get around it. Please let me know if you 
need more information if it helps understand the problem better. 
Thanks in advance,
best,
Hardeep

Perhaps the difference is below the noise floor? I was focusing only on 
startup time by running lsprofcalltree over a script containing only 
"import pylab". In that context, dedent was the largest contributor to 
startup time (other than stuff in the stdlib and numpy) before this 
change. But I would imagine that that over the total time of 
backend_driver.py and actually doing stuff like, say, *plotting* is 
fairly insignificant.
Cheers,
Mike
Eric Firing wrote:
> Mike,
> 
> After a quick test, I am puzzled: running "backend_driver.py Template"
> takes 0.49 minutes on my machine before and after this change, so the 
> dedenting time must have been less than I thought.
> 
> Eric
> 
> md...@us... wrote:
>> Revision: 3744
>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=3744&view=rev
>> Author: mdboom
>> Date: 2007年08月28日 12:17:21 -0700 (2007年8月28日)
>>
>> Log Message:
>> -----------
>> Use regular expressions to do dedenting. This is ~15X faster than the
>> old implementation. dedent accounted for around 30% of the time spent
>> in "import pylab", so was probably worthy of optimization, even if this
>> regex approach is less clear. The results are identical to the old
>> implementation, with the exception of a single docstring (in
>> backend_bases.py) that needed to be fixed.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel