matplotlib-devel Mailing List for matplotlib

Stéfan van der Walt wrote:
> Hi Eric,
> 
> 2009年9月28日 Eric Firing <ef...@ha...>:
>>> When saving plots (using plt.figsave and matplotlib from SVN)
>>> consisting of subplots, the layout is a bit messed up. As an example,
>>> have a look at
>>>
>>> http://mentat.za.net/refer/segmentation.pdf
>> Wow, that's really ugly! I suspect that for anyone to provide any help
>> on this, you will need to supply a minimal script to show what you are
>> doing. I take it you are starting with something that looks reasonable
>> on the screen, but comes out quite different when you save it?
> 
> I narrowed the problem down to this line:
> 
> matplotlib.rc('figure', dpi=300)
> 
> Does it do some magic behind the scenes?
> 
> Attached is the script that produces this:
Stefan,
You forgot the attachment.
dpi is an inherently confusing parameter because it can relate to font 
rendering and to the resolution of an image. So there are different 
kinds of dpi, but the distinction between them is not kept clear in the 
code--at least it wasn't the last time I looked into this, quite a long 
time ago.
Eric
> 
> http://mentat.za.net/refer/badplot.pdf
> 
> I'm running 1.0.svn on OSX Snow Leopard, Python 2.6 and NumPy dev.
> 
> Regards
> Stéfan
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi Eric,
2009年9月28日 Eric Firing <ef...@ha...>:
>> When saving plots (using plt.figsave and matplotlib from SVN)
>> consisting of subplots, the layout is a bit messed up. As an example,
>> have a look at
>>
>> http://mentat.za.net/refer/segmentation.pdf
>
> Wow, that's really ugly! I suspect that for anyone to provide any help
> on this, you will need to supply a minimal script to show what you are
> doing. I take it you are starting with something that looks reasonable
> on the screen, but comes out quite different when you save it?
I narrowed the problem down to this line:
matplotlib.rc('figure', dpi=300)
Does it do some magic behind the scenes?
Attached is the script that produces this:
http://mentat.za.net/refer/badplot.pdf
I'm running 1.0.svn on OSX Snow Leopard, Python 2.6 and NumPy dev.
Regards
Stéfan

On Wed, Oct 28, 2009 at 1:09 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> This is because the distribution includes a setup.cfg file by mistake.
> Deleting setup.cfg should allow the autodetection logic to disable
> building wxagg. This is bug #2871530 on Sourceforge:
>
> https://sourceforge.net/tracker/?func=detail&aid=2871530&group_id=80706&atid=560720
>
> I suggest we release a 0.99.1.2, possibly with just this bug fixed,
> since this problem keeps being reported on the mailing lists.
My OSX build machine died recently so would take some time. Perhaps
we should just upload a 0.99.1.1 tarball only to the sf site? Earlier
I tried deleting 0.99.1 and reuploading, and it apparently worked on
the one mirror I tested, but clearly it did not propagate through.
JDH

Erin Sheldon <eri...@gm...> writes:
> I just downloaded 0.99.1.1 and I'm finding this error:
> wxPython: no
> * wxPython not found
> Traceback (most recent call last):
> File "setup.py", line 146, in <module>
> import wx
> ImportError: No module named wx
This is because the distribution includes a setup.cfg file by mistake.
Deleting setup.cfg should allow the autodetection logic to disable
building wxagg. This is bug #2871530 on Sourceforge:
https://sourceforge.net/tracker/?func=detail&aid=2871530&group_id=80706&atid=560720
I suggest we release a 0.99.1.2, possibly with just this bug fixed,
since this problem keeps being reported on the mailing lists.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi!
ti, 2009年10月27日 kello 15:36 -0400, Jae-Joon Lee kirjoitti:
> Thanks for your suggestion and the patch.
> However, I'm not very inclined to make such a change any time soon,
> since that custom axes class is one of my primary motivation
> (supporting the cuvelinear grid) behind the axes_grid toolkit. And
> other part of axes_grid toolkit depends on this behavior.
> On the other hand, I'm trying to make some reorganization effort of
> the axes_grid toolkit in the future, during which I will try to
> separate out things that depends on the custom axes.
Fair enough.
[clip: toggle_axisline]
Good to know.
Of course, I did not read the fine manual first, which probably explains
why I had trouble :). User error, sorry for the noise.
> I'm thinking about issuing a warning (about the different behavior
> from the original matplotlib) whenever axes_grid is imported
> (optinally turned off using rcparams). This may help others not to
> waste their time when something does not work.
Perhaps it would be enough to explain in the AxisGrid docstring that the
default class is a customized one, and that there are implications.
Everyone hopefully reads that (at least I did).
Thanks,
Pauli

Thanks for your suggestion and the patch.
However, I'm not very inclined to make such a change any time soon,
since that custom axes class is one of my primary motivation
(supporting the cuvelinear grid) behind the axes_grid toolkit. And
other part of axes_grid toolkit depends on this behavior.
On the other hand, I'm trying to make some reorganization effort of
the axes_grid toolkit in the future, during which I will try to
separate out things that depends on the custom axes.
FYI, note that you can turn off the customized behavior by
 ax.toggle_axisline(False)
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#axisline
This should bring back the original behavior of the matplotlib axes
(if it does not, it should be considered a bug). Of course this will
disable some of the functionality of the axes_grid.
I'm thinking about issuing a warning (about the different behavior
from the original matplotlib) whenever axes_grid is imported
(optinally turned off using rcparams). This may help others not to
wast their time when something does not work.
Regards,
-JJ
On Tue, Oct 27, 2009 at 1:53 PM, Pauli Virtanen <pa...@ik...> wrote:
> Hi,
>
> mpl_toolkit.axes_grid.AxesGrid uses a custom axes type as the default
> type of axes it creates. I think it might be more user-friendly to use
> matplotlib.axes.Axes as the default -- the functionality in basic use
> seems to be the same.
>
> The custom axes handle drawing ticks quite differently from matplotlib's
> usual Axes. I just spent an hour wondering why
>
>    grid[0].xaxis.get_major_ticks()[-1].label.set_horizontalalignment("right")
>
> had no effect -- the answer is that LocatableAxis draws ticks using a
> custom tick artist, and that the correct axis object is in
> grid[0].axes["bottom"]. And in fact, it cannot adjust the align of
> individual tick labels.
>
> The AxesGrid is really useful, so I'd suggest the following change:
>
> --- lib/mpl_toolkits/axes_grid/axes_grid.py.orig    2009年10月27日 19:51:43.000000000 +0200
> +++ lib/mpl_toolkits/axes_grid/axes_grid.py   2009年10月27日 19:52:13.000000000 +0200
> @@ -210,10 +210,10 @@
>
>
>     if axes_class is None:
> -      axes_class = LocatableAxes
> +      axes_class = maxes.Axes
>       axes_class_args = {}
>     else:
> -      if isinstance(axes_class, maxes.Axes):
> +      if issubclass(axes_class, maxes.Axes):
>         axes_class_args = {}
>       else:
>         axes_class, axes_class_args = axes_class
>
> --
> Pauli Virtanen
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,
mpl_toolkit.axes_grid.AxesGrid uses a custom axes type as the default 
type of axes it creates. I think it might be more user-friendly to use 
matplotlib.axes.Axes as the default -- the functionality in basic use 
seems to be the same.
The custom axes handle drawing ticks quite differently from matplotlib's 
usual Axes. I just spent an hour wondering why
	grid[0].xaxis.get_major_ticks()[-1].label.set_horizontalalignment("right")
had no effect -- the answer is that LocatableAxis draws ticks using a 
custom tick artist, and that the correct axis object is in
grid[0].axes["bottom"]. And in fact, it cannot adjust the align of
individual tick labels.
The AxesGrid is really useful, so I'd suggest the following change:
--- lib/mpl_toolkits/axes_grid/axes_grid.py.orig	2009年10月27日 19:51:43.000000000 +0200
+++ lib/mpl_toolkits/axes_grid/axes_grid.py	2009年10月27日 19:52:13.000000000 +0200
@@ -210,10 +210,10 @@
 
 
 if axes_class is None:
- axes_class = LocatableAxes
+ axes_class = maxes.Axes
 axes_class_args = {}
 else:
- if isinstance(axes_class, maxes.Axes):
+ if issubclass(axes_class, maxes.Axes):
 axes_class_args = {}
 else:
 axes_class, axes_class_args = axes_class
-- 
Pauli Virtanen

From: Craig Lang [mailto:cr...@gr...] 
Sent: Monday, October 26, 2009 13:04
Greetings,
I am using matplotlib to generate an SVG plot containing a mixture of
Annotations and Circles. I noticed that the annotation text does not appear at
exactly the correct location when outputting to SVG. The difference is minor,
but definitely present.
The following will reproduce the problem in the form of two files, an svg and
a png:
[...]
Further investigation reveals that this problem occurs with ps and pdf output
as well. It seems that all backend_*.py files in
/usr/share/pyshared/matplotlib/backends suffer from this problem. I have poked
around in a few files but can't see any obvious fixes. 
Has anyone encountered this problem before and found a decent workaround? 
Thanks,
Craig
(I'm cc'ing the development list.)
I believe I have some understanding of what's happening. The backends you
mentioned use routines in ft2font.cpp to align text. The algorithms for
aligning text use information returned by the function compute_string_bbox,
which bases the bounding box on the extent of the painted regions of the
glyphs. The width and height of that box are computed by get_width_height
(also in ft2font.cpp) and returned to the renderer, which hands them off to
the _get_layout method of each text object. That method leaves the anchor
point (near the lower-left corner of the text) undisturbed for left-aligned
text, but for centered or right-aligned text shifts it left by half or all,
respectively, of the bounding box width. The resulting coordinate is returned
to the text object's draw method, which eventually calls the renderer.
The difference arises in how the renderers for the different backends treat
the anchor coordinate. The bitmap Agg backend uses draw_glyphs_to_bitmap in
ft2font.cpp, and I think that that function aligns the leftmost ink of the
bitmapped text to the anchor point. Because the anchor point was adjusted, if
at all, by the width of the inked area, it's the inked area of the text that
is left-, center-, or right-aligned. In contrast, the SVG, PS, and PDF
backends make text objects at that anchor coordinate in their output. (I'm
glossing over more complex cases like that of text converted to paths).
However, the inked area of the first character may be to the right (as with
your H) or to the left (as often with lowercase j) of the anchor point. (See,
for example, http://www.tortall.net/mu/wiki/CairoTutorial#understanding-text.)
If the text is to be center- or right-aligned, the anchor point has been
adjusted only for the width of the inked area, so any offset of the ink
relative to the initial anchor is simply translated to the other alignments.
Thus, your H was too far to the right.
I showed some different manifestations of this behavior in a tracker I filed
last year, at http://sourceforge.net/tracker/?func=detail
<http://sourceforge.net/tracker/?func=detail&atid=560721&aid=1978234&group_id=
80706> &atid=560721&aid=1978234&group_id=80706. The digits and decimal points
of the y-axis tick labels are out of alignment, the x-axis tick labels have
different baselines, and the numbers in the middle are not aligned in columns
(although in PDF and SVG saves of the figure, the left-aligned numbers do lie
in columns).
I'd like to see matplotlib have at least the option of aligning using the
advance widths of the characters in the horizontal direction and the font-wide
ascent and descent (rather than the ascent and descent of the particular
glyphs in each text object) in the vertical direction. Is it important to have
the option of aligning to the glyph ink, too (and to do it consistently across
backends)? As time permits, I'm willing to contribute coding effort.
Craig, I don't know of a work-around at the moment, but I'll write again if I
think of one.

> Have you tried:
> ax1.scatter(sanjose_y,sanjose_x,color=(0.9,0.9,0.0),label='SanJose',alpha=0.1)
Yes, the above worked, thank you
--
Andrew 'Boo' Davie

Eero Nevalainen <eer...@in...> writes:
> I'm plotting GPS scatter and I have a problem with the plotting library
> https://sourceforge.net/tracker/?func=detail&aid=2886541&group_id=80706&atid=560720
> Doing a scatterplot with for example scatter(x,y, s=1, c='r') makes black
> dots instead of red ones. 
It's because of the black edgecolor. Try
scatter(x,y,s=1,c='r',edgecolor='None')
to disable drawing the edges.
> Do you devs have an IRC channel? I'd like to talk interactively.
Not that I know of.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
I'm plotting GPS scatter and I have a problem with the plotting library
https://sourceforge.net/tracker/?func=detail&aid=2886541&group_id=80706&atid=560720
I'm comparing different GPS'es and need the colors to separate them. You
can check the current output in
http://users.tkk.fi/~ejnevala/scatterplot.png
Do you devs have an IRC channel? I'd like to talk interactively.
I pledge to donate 5 bucks to matplotlib just for triaging the bug.
-- 
Eero Nevalainen
System Architect
Indagon Ltd.

tcb wrote:
> Hi Mike,
>
> I'm not sure about the textpath functionality. Most of the 'easy'
> marker types have been specified already (triangles, squares etc). Are
> the latex symbols defined somewhere that you could easily extract a
> path description of them, and then pass that to the textpath code you
> have? This would be perfect, since you could then apply the properties
> changes already there (like color, size, linewidth etc), and you
> wouldnt necessarily need latex to render the markers.
>
> Even if you could manage to make a path description for (all) the
> markers, they might not exactly correspond to the latex symbols which
> would be one of the main aims- for eg. using text.usetex with the pdf
> backend you could match the fonts in your graph to your latex document
> and it would all look very nice ;)
>
> I agree that the best approach would be to make a new marker style
> '$...$' and pass the string inside to whatever renders the math text.
>
> I hadn't consider making a patch myself- but perhaps I'll take a look
> and see if something can be done (any pointers on the use of the math
> text code would be appreciated...)- either way I will file an
> enhancement request to keep track of it.
> 
The functionality in textpath.py is able to turn any text (including 
math with the internal render and externally-rendered LaTeX) into a path 
on-the-fly. It should exactly match the rest of the text, as long as 
the usetex option is passed along correctly. Look at 
textpath.text_to_path.get_text_path:
 convert text *s* to path (a tuple of vertices and codes for 
matplotlib.math.Path).
 *prop*
 font property
 *s*
 text to be converted
 
 *usetex*
 If True, use matplotlib usetex mode.
 *ismath*
 If True, use mathtext parser. Effective only if usetex == False.
There's an example of its usage at the bottom of the same file.
It would be great if you wanted to look into this further. Let me know 
if I can provide any more pointers.
Mike
> thanks,
>
> tcb
>
>
>
> On Mon, Oct 26, 2009 at 1:03 PM, Michael Droettboom <md...@st...> wrote:
> 
>> That's a very interesting idea. I actually think that with the recent
>> textpath functionality that Jae-Joon added, we may be able to tie text and
>> markers together without too much pain. Then it can advantage of all the
>> performance optimizations in draw_markers. Each of the marker styles now
>> contains a function that draws a path for the marker and then passes that to
>> draw_marker. We could add one that draws an arbitrary text path, and then
>> passes that along. I propose that Line.set_marker supports a new marker
>> style "$...$" which would render whatever "..." is as math text.
>>
>> Were you offering to try to produce a patch yourself? Either way, it would
>> be great to file an enhancement request in the tracker so this idea doesn't
>> get lost. It's a good one.
>>
>> Mike
>>
>> tcb wrote:
>> 
>>> Hi,
>>>
>>> Is there some way to add support for latex symbols as markers?
>>>
>>> I think it would be an extension of the current methods for plotting
>>> markers- since I dont think all the color, edge, line style etc
>>> properties would be relevant (or even possible). However, it would
>>> allow arbitrary symbols (at least whatever latex can do) to be used,
>>> which would be really useful.
>>>
>>> The current marker set is fine for most simple plots- but when there
>>> are a few different symbols it quickly becomes tricky to find a set
>>> which can easily be distinguished from each other. The other problem
>>> is that when preparing a graph for publication, it is occasionally
>>> necessary to be able to refer to or quote the symbols in the caption
>>> or the main text- and latex symbols in the graphs would make this look
>>> a bit better.
>>>
>>> I've had a quick look at how the marker symbols are implemented, and
>>> it is my impression that it would be reasonably hard to implement a
>>> new symbol of choice. On the other hand, since I am already using
>>> latex to produce all the text in the graph, it seems it should be
>>> fairly straightforward (with some careful attention to the
>>> positioning...) to use the same text-drawing code which is used for
>>> the legend, axes labels etc, to put the markers on the plot.
>>>
>>> Is there any interest in this?
>>>
>>> thanks,
>>>
>>> tcb
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> 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
>>
>>
>> 
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> 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 Mike,
I'm not sure about the textpath functionality. Most of the 'easy'
marker types have been specified already (triangles, squares etc). Are
the latex symbols defined somewhere that you could easily extract a
path description of them, and then pass that to the textpath code you
have? This would be perfect, since you could then apply the properties
changes already there (like color, size, linewidth etc), and you
wouldnt necessarily need latex to render the markers.
Even if you could manage to make a path description for (all) the
markers, they might not exactly correspond to the latex symbols which
would be one of the main aims- for eg. using text.usetex with the pdf
backend you could match the fonts in your graph to your latex document
and it would all look very nice ;)
I agree that the best approach would be to make a new marker style
'$...$' and pass the string inside to whatever renders the math text.
I hadn't consider making a patch myself- but perhaps I'll take a look
and see if something can be done (any pointers on the use of the math
text code would be appreciated...)- either way I will file an
enhancement request to keep track of it.
thanks,
tcb
On Mon, Oct 26, 2009 at 1:03 PM, Michael Droettboom <md...@st...> wrote:
> That's a very interesting idea. I actually think that with the recent
> textpath functionality that Jae-Joon added, we may be able to tie text and
> markers together without too much pain. Then it can advantage of all the
> performance optimizations in draw_markers. Each of the marker styles now
> contains a function that draws a path for the marker and then passes that to
> draw_marker. We could add one that draws an arbitrary text path, and then
> passes that along. I propose that Line.set_marker supports a new marker
> style "$...$" which would render whatever "..." is as math text.
>
> Were you offering to try to produce a patch yourself? Either way, it would
> be great to file an enhancement request in the tracker so this idea doesn't
> get lost. It's a good one.
>
> Mike
>
> tcb wrote:
>>
>> Hi,
>>
>> Is there some way to add support for latex symbols as markers?
>>
>> I think it would be an extension of the current methods for plotting
>> markers- since I dont think all the color, edge, line style etc
>> properties would be relevant (or even possible). However, it would
>> allow arbitrary symbols (at least whatever latex can do) to be used,
>> which would be really useful.
>>
>> The current marker set is fine for most simple plots- but when there
>> are a few different symbols it quickly becomes tricky to find a set
>> which can easily be distinguished from each other. The other problem
>> is that when preparing a graph for publication, it is occasionally
>> necessary to be able to refer to or quote the symbols in the caption
>> or the main text- and latex symbols in the graphs would make this look
>> a bit better.
>>
>> I've had a quick look at how the marker symbols are implemented, and
>> it is my impression that it would be reasonably hard to implement a
>> new symbol of choice. On the other hand, since I am already using
>> latex to produce all the text in the graph, it seems it should be
>> fairly straightforward (with some careful attention to the
>> positioning...) to use the same text-drawing code which is used for
>> the legend, axes labels etc, to put the markers on the plot.
>>
>> Is there any interest in this?
>>
>> thanks,
>>
>> tcb
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> 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
>
>

On Mon, Oct 26, 2009 at 2:35 AM, <Boo...@cs...> wrote:
> Also (a different problem), I get an error message (when adding a legend, that no labels were defined). This is also changed behaviour since the upgrade. Seems like scatter has changed... but why?
This is a known bug.
http://www.nabble.com/No-legend-using-scatter-function-td24816047.html#a24816047
This is fixed in the svn, and I guess 0.99.1.1 shipped with this fixed.
If you don't want to upgrade, use the workaround in the above post.
Regards,
-JJ

Have you tried:
ax1.scatter(sanjose_y,sanjose_x,color=(0.9,0.9,0.0),label='SanJose',alpha=0.1)
That's what the scatter_demo2.py example does, and it appears to be working.
In general, alpha support is a bit inconsistent, and is the source of a 
number of these kinds of bugs -- where RGBA values are supported in some 
places but not in others. It's on the TODO list to fix, but it's rather 
pervasive so hasn't been tackled yet.
Mike
Boo...@cs... wrote:
> Reporting this as a matplotlib bug because that's where I see the error.
>
> I have some code which was running fine, drawing a scatter plot with transparent/alpha for the colour, like this...
>
> ax1.scatter(sanjose_y,sanjose_x,color=(0.9,0.9,0.0,0.1),label='SanJose')
>
> This used to draw a very faint transparent series of points which (where there were a lot of points) built up a fairly solid colour. Now, after an upgrade to Ubuntu 9.10 I see only solid colour, no transparency/alpha at all. Also (a different problem), I get an error message (when adding a legend, that no labels were defined). This is also changed behaviour since the upgrade. Seems like scatter has changed... but why?
>
> I tried downloading matplotlib source code and compiling -- and despite a few glitches (like, it was by default Mac compilation) -- I think I got that going OK. Still, I see exactly the same behaviour. Scatter is behaving differently, and I really need that alpha/transparency!!!
>
> Neither of these problems were evident on Ubuntu 9.04, and I was using the inbuilt matplotlib for that.
>
> Please excuse if this report is in the wrong place -- my first attempt to report a bug in this package.
>
> Cheers
> A
>
> --
> Andrew 'Boo' Davie
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> 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

That's a very interesting idea. I actually think that with the recent 
textpath functionality that Jae-Joon added, we may be able to tie text 
and markers together without too much pain. Then it can advantage of 
all the performance optimizations in draw_markers. Each of the marker 
styles now contains a function that draws a path for the marker and then 
passes that to draw_marker. We could add one that draws an arbitrary 
text path, and then passes that along. I propose that Line.set_marker 
supports a new marker style "$...$" which would render whatever "..." is 
as math text.
Were you offering to try to produce a patch yourself? Either way, it 
would be great to file an enhancement request in the tracker so this 
idea doesn't get lost. It's a good one.
Mike
tcb wrote:
> Hi,
>
> Is there some way to add support for latex symbols as markers?
>
> I think it would be an extension of the current methods for plotting
> markers- since I dont think all the color, edge, line style etc
> properties would be relevant (or even possible). However, it would
> allow arbitrary symbols (at least whatever latex can do) to be used,
> which would be really useful.
>
> The current marker set is fine for most simple plots- but when there
> are a few different symbols it quickly becomes tricky to find a set
> which can easily be distinguished from each other. The other problem
> is that when preparing a graph for publication, it is occasionally
> necessary to be able to refer to or quote the symbols in the caption
> or the main text- and latex symbols in the graphs would make this look
> a bit better.
>
> I've had a quick look at how the marker symbols are implemented, and
> it is my impression that it would be reasonably hard to implement a
> new symbol of choice. On the other hand, since I am already using
> latex to produce all the text in the graph, it seems it should be
> fairly straightforward (with some careful attention to the
> positioning...) to use the same text-drawing code which is used for
> the legend, axes labels etc, to put the markers on the plot.
>
> Is there any interest in this?
>
> thanks,
>
> tcb
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> 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

Reporting this as a matplotlib bug because that's where I see the error.
I have some code which was running fine, drawing a scatter plot with transparent/alpha for the colour, like this...
ax1.scatter(sanjose_y,sanjose_x,color=(0.9,0.9,0.0,0.1),label='SanJose')
This used to draw a very faint transparent series of points which (where there were a lot of points) built up a fairly solid colour. Now, after an upgrade to Ubuntu 9.10 I see only solid colour, no transparency/alpha at all. Also (a different problem), I get an error message (when adding a legend, that no labels were defined). This is also changed behaviour since the upgrade. Seems like scatter has changed... but why?
I tried downloading matplotlib source code and compiling -- and despite a few glitches (like, it was by default Mac compilation) -- I think I got that going OK. Still, I see exactly the same behaviour. Scatter is behaving differently, and I really need that alpha/transparency!!!
Neither of these problems were evident on Ubuntu 9.04, and I was using the inbuilt matplotlib for that.
Please excuse if this report is in the wrong place -- my first attempt to report a bug in this package.
Cheers
A
--
Andrew 'Boo' Davie

Hi,
Is there some way to add support for latex symbols as markers?
I think it would be an extension of the current methods for plotting
markers- since I dont think all the color, edge, line style etc
properties would be relevant (or even possible). However, it would
allow arbitrary symbols (at least whatever latex can do) to be used,
which would be really useful.
The current marker set is fine for most simple plots- but when there
are a few different symbols it quickly becomes tricky to find a set
which can easily be distinguished from each other. The other problem
is that when preparing a graph for publication, it is occasionally
necessary to be able to refer to or quote the symbols in the caption
or the main text- and latex symbols in the graphs would make this look
a bit better.
I've had a quick look at how the marker symbols are implemented, and
it is my impression that it would be reasonably hard to implement a
new symbol of choice. On the other hand, since I am already using
latex to produce all the text in the graph, it seems it should be
fairly straightforward (with some careful attention to the
positioning...) to use the same text-drawing code which is used for
the legend, axes labels etc, to put the markers on the plot.
Is there any interest in this?
thanks,
tcb

James Evans wrote:
> All,
> 
> 
> 
> I have a question regarding the default alpha value for an Artist. Why 
> is it 1.0 instead of None? The color conversion code takes into account 
> if alpha is None and having it default to something other than None 
> makes it impossible for any Patch to have a fill_color specified as an 
> RGBA value (and possibly other Artist sub-classes). Should this be 
> something else, or should the Patch.set_facecolor method pre-process the 
> incoming color value and set any specified alpha as appropriate (I hope 
> not since this would cause the color value to be processed several times)?
> 
James,
This is just an aspect of the general mess that is alpha-handling in 
mpl. Sometime, maybe a year ago, I thought it would be easy to fix at 
least some of the problems by changing the default Artist alpha to None. 
 It turned out to be not that simple, I ran out of time and patience, 
and dropped it. Perhaps some other changes in the interim have made it 
so that changing the Artist initial value now would be simpler, but I 
suspect it will still have to be done as part of a deeper overhaul, if 
not the full overhaul that would be most desirable.
Eric
> 
> 
> Thanks,
> 
> --James Evans
> 

Eric Bruning wrote:
> I'm seeing problems with reversed colormaps (attached code and image).
> The problem seems to be with colormaps that are specified functionally
> or that don't have equal numbers of red, green, and blue entries. For
> instance, 'flag', 'rainbow', and 'gist_earth'.
> 
> Furthermore, 'gist_rainbow_r' and 'terrain_r' don't plot at all with
> the attached code.
> 
> I presume this is a regression from earlier behavior, since quite a
> few colormaps are affected. svn shows some cleanup to the colormap
> code this summer. Can someone with more familiarity with that code
> point to the problem?
Fixed in svn 7902.
Eric
> 
> Thanks,
> Eric
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Eric Bruning wrote:
> I'm seeing problems with reversed colormaps (attached code and image).
> The problem seems to be with colormaps that are specified functionally
> or that don't have equal numbers of red, green, and blue entries. For
> instance, 'flag', 'rainbow', and 'gist_earth'.
> 
> Furthermore, 'gist_rainbow_r' and 'terrain_r' don't plot at all with
> the attached code.
> 
> I presume this is a regression from earlier behavior, since quite a
> few colormaps are affected. svn shows some cleanup to the colormap
> code this summer. Can someone with more familiarity with that code
> point to the problem?
I'll take care of it. Thanks for the bug report.
Eric
> 
> Thanks,
> Eric

All,
 
I have a question regarding the default alpha value for an Artist. Why is it 1.0 instead of None? The color conversion code takes
into account if alpha is None and having it default to something other than None makes it impossible for any Patch to have a
fill_color specified as an RGBA value (and possibly other Artist sub-classes). Should this be something else, or should the
Patch.set_facecolor method pre-process the incoming color value and set any specified alpha as appropriate (I hope not since this
would cause the color value to be processed several times)?
 
Thanks,
--James Evans

I'm seeing problems with reversed colormaps (attached code and image).
The problem seems to be with colormaps that are specified functionally
or that don't have equal numbers of red, green, and blue entries. For
instance, 'flag', 'rainbow', and 'gist_earth'.
Furthermore, 'gist_rainbow_r' and 'terrain_r' don't plot at all with
the attached code.
I presume this is a regression from earlier behavior, since quite a
few colormaps are affected. svn shows some cleanup to the colormap
code this summer. Can someone with more familiarity with that code
point to the problem?
Thanks,
Eric

I don't have a patch. I just wrote a key handler that runs the snippet
I gave when "q" is pressed. I hope there's a better way to do it anyway :)
Georg
Jae-Joon Lee schrieb:
> Can you post your patch so that others can review?
> 
> Regards,
> 
> -JJ
> 
> 
> On Wed, Oct 21, 2009 at 3:23 AM, Georg Brandl <g.b...@gm...> wrote:
>> Hi,
>>
>> one thing I missed when I switched from Gnuplot to matplotlib was that I
>> can't press "q" to close a window but have to use the window manager; in
>> one environment I work in that means I have to use the mouse to close a
>> window.
>>
>> I made a custom key handler that does the following:
>>
>> try:
>> event.canvas.manager.destroy()
>> except AttributeError:
>> pass
-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

Can you post your patch so that others can review?
Regards,
-JJ
On Wed, Oct 21, 2009 at 3:23 AM, Georg Brandl <g.b...@gm...> wrote:
> Hi,
>
> one thing I missed when I switched from Gnuplot to matplotlib was that I
> can't press "q" to close a window but have to use the window manager; in
> one environment I work in that means I have to use the mouse to close a
> window.
>
> I made a custom key handler that does the following:
>
>    try:
>      event.canvas.manager.destroy()
>    except AttributeError:
>      pass
>
> which seems to work, at least with GtkAgg (I didn't venture to find out
> why the AttributeError is raised, it works in spite of that).
>
> Would it make sense to have that shortcut by default (and working for all
> windowing backends)?
>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>