matplotlib-devel Mailing List for matplotlib (Page 7)

On Sep 2, 2010, at 14:14, Benjamin Root <ben...@ou...> wrote:
> There was a bug report recently (not to the mailing list) where the reporter noted that if an Axes3D was created using the fig.add_subplot(111, projection='3d') or fig.gca(projection='3d'), then you can not clear the figure using fig.clf(). Doing so causes an exception to be thrown.
> 
> Tracing down the problem revealed that the Axes3D object was added twice to the figure's self.axes, but exists only once in self._axstack. So, when looping through self.axes, a delete is attempted on an axes that no longer exists in the stack.
> 
> I traced down the cause for why the axes is added twice. Because of how Axes3D used to be attached to a figure (and is still valid), the __init__() function for Axes3D calls figure.add_axes(self) on its own. This initialization is done after the check in add_subplot to see if the axes exists already in the figure. So, add_subplot then adds the axes without knowing that it already happened.
> 
> I think there are multiple issues here. Primarially, there is the issue that Axes3D is attaching itself to a figure. However, in the interest of backwards-compatibility, we can't just fix this outright. There is also the issue that there are multiple places in the Figure class that are adding axes to the figure object. Ideally, shouldn't we have a single function that performs proper checks and adds an axes? Then that function should be used in the other class functions to perform this action. In my opinion, there is too much duplicated code here.
I agree the duplicated code should be eliminated. Depending on how complex it would be to clean that up and not break existing code, could we in the short term make use of sets to eliminate duplicates?
Ryan

There was a bug report recently (not to the mailing list) where the reporter
noted that if an Axes3D was created using the fig.add_subplot(111,
projection='3d') or fig.gca(projection='3d'), then you can not clear the
figure using fig.clf(). Doing so causes an exception to be thrown.
Tracing down the problem revealed that the Axes3D object was added twice to
the figure's self.axes, but exists only once in self._axstack. So, when
looping through self.axes, a delete is attempted on an axes that no longer
exists in the stack.
I traced down the cause for why the axes is added twice. Because of how
Axes3D used to be attached to a figure (and is still valid), the __init__()
function for Axes3D calls figure.add_axes(self) on its own. This
initialization is done after the check in add_subplot to see if the axes
exists already in the figure. So, add_subplot then adds the axes without
knowing that it already happened.
I think there are multiple issues here. Primarially, there is the issue
that Axes3D is attaching itself to a figure. However, in the interest of
backwards-compatibility, we can't just fix this outright. There is also the
issue that there are multiple places in the Figure class that are adding
axes to the figure object. Ideally, shouldn't we have a single function
that performs proper checks and adds an axes? Then that function should be
used in the other class functions to perform this action. In my opinion,
there is too much duplicated code here.
Thoughts, concerns, ideas?
Ben Root

On Wed, Sep 1, 2010 at 11:29 AM, Stan West <sta...@nr...> wrote:
> *From:* ben...@gm... [mailto:ben...@gm...] *On Behalf Of
> *Benjamin Root
> *Sent:* Tuesday, August 31, 2010 23:20
>
> I can confirm that evince also has a problem with the second image, but not
> the first or the third images. This is using the latest matplotlib from
> svn.
>
> Thank you for the confirmation, Ben.
>
> Here's what I've found so far. I examined the Liberation sources (the SFD
> files) in FontForge and as text, and I gather that some of them use a
> non-standard encoding. Liberation Sans, for example, does not define a space
> glyph with the name "space"; instead it defines a glyph for the non-breaking
> space at code point U+00A0 with the name "uni00A0" and gives U+0020 (the
> plain space) as an alternate encoding. (In the file
> LiberationSans-Regular.sfd, these definitions start at line 2929.) However,
> matplotlib assumes that the font uses Postscript's StandardEncoding. I
> suppose that when Postscript processes "(some text) show", it looks for the
> space glyph under the standard name "space" but finds nothing. Here is an
> excerpt of matplotlib/ttconv/pprdrv_tt.cpp from SVN starting at line 415:
>
> /*-------------------------------------------------------------
> ** Define the encoding array for this font.
> ** Since we don't really want to deal with converting all of
>
> ** the possible font encodings in the wild to a standard PS
> ** one, we just explicitly create one for each font.
> -------------------------------------------------------------*/
> void ttfont_encoding(TTStreamWriter& stream, struct TTFONT *font, std::vector<int>& glyph_ids, font_type_enum target_type)
>
> {
> stream.putline("/Encoding StandardEncoding def");
>
> // if (target_type == PS_TYPE_3) {
> // stream.printf("/Encoding [ ");
>
> // for (std::vector<int>::const_iterator i = glyph_ids.begin();
> // i != glyph_ids.end(); ++i) {
> // const char* name = ttfont_CharStrings_getname(font, *i);
>
> // stream.printf("/%s ", name);
> // }
>
> // stream.printf("] def\n");
> // } else {
> // stream.putline("/Encoding StandardEncoding def");
>
> // }
> } /* end of ttfont_encoding() */
>
> I saw in the SVN logs that the commented code for non-standard encodings
> had a brief life of about a month earlier this year before being declared
> more trouble than it was worth.
>
> Getting back to the fonts, I found that not all of the Liberation fonts use
> this non-standard encoding. The Liberation Sans Narrow fonts in the current
> release define "space" at U+0020 with U+00A0 as an alternate encoding, and
> they work fine in matplotlib EPS files. I also checked a few of the fonts in
> one older release, 1.0<https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-1.0.tar.gz>,
> and they also work correctly.
>
> One work-around I found is to use Unicode strings for text containing
> spaces, which in the EPS file causes spaces to be looked up under the glyph
> name "uni00A0". If embedding Type 3 fonts, another work-around (which I
> only spot-checked) is to effectively standardize the encoding by editing the
> EPS file, changing "/uni00A0" to "/space" in the font definition and in
> glyphshow operations that call for "/uni00A0".
>
>
Stan,
Thanks for the insightful analysis. Could you file a bug report with some
of this information (at the very least, reference your message on the
mailing list)?
Ben Root

On 08/27/2010 09:39 AM, Thomas Robitaille wrote:
> Hi,
>
> It seems that the match_original=True option in PatchCollection does not preserve line style. Is this deliberate? If not, here is a patch for collections.py:
>
Thanks. I think your patch is fixing a genuine bug, so I applied it to 
the maintenance branch and the trunk, in 8675 and 8676.
Eric
> Index: collections.py
> ===================================================================
> --- collections.py	(revision 8664)
> +++ collections.py	(working copy)
> @@ -1041,6 +1041,7 @@
> facecolors = [determine_facecolor(p) for p in patches]
> edgecolors = [p.get_edgecolor() for p in patches]
> linewidths = [p.get_linewidth() for p in patches]
> + linestyles = [p.get_linestyle() for p in patches]
> antialiaseds = [p.get_antialiased() for p in patches]
>
> Collection.__init__(
> @@ -1048,7 +1049,7 @@
> edgecolors=edgecolors,
> facecolors=facecolors,
> linewidths=linewidths,
> - linestyles='solid',
> + linestyles=linestyles,
> antialiaseds = antialiaseds)
> else:
> Collection.__init__(self, **kwargs)
>
> Cheers,
>
> Tom
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Tue, Aug 31, 2010 at 7:02 AM, Michiel de Hoon <mjl...@ya...> wrote:
>> 1. Our networking event loop that is based on zeromq/pyzmq
>> 2. A single GUI event loop from wx, qt4, etc.
>>
>> We do this by triggering an iteration of our networking
>> event loop on a periodic GUI timer.
>
> So right now you're in a loop in which you let qt4 (or wx) watch the file descriptors qt4 needs, then zeromq the file descriptors that zeromq needs, and so on?
ZMQ sockets are not really sockets in that they do not have a file
descriptor interface. That is something that is being worked on in
the zeromq development, but it is not there yet. Also, I don't think
the API will be fully compatible, so I am not sure how it will play
with what Qt is expecting.
> Just use the qt4 event loop to watch both the file descriptors zeromq wants to watch, in addition to whatever events qt4 needs. Qt4 already has the API that allows you to do this (QSocketNotifier et al.). I am not familiar with zeromq, but if there is a way to determine which file descriptors it wants to watch then you're almost done. If not, you could discuss this with the zeromq developers. Then you won't need to poll, you'll get better response times, and the code will be scalable too.
>
> Best,
> --Michiel.
>
>
>
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

On 09/01/2010 07:57 AM, Thomas Robitaille wrote:
>>>> I have submitted a ticket: https://sourceforge.net/tracker/?group_id=80706&atid=560720
>>>
>>> The obvious fix would be to change from patch.fill to
>>> patch.get_fill(). However, I'm curious how this code got broken.
>>
>> I broke it here: http://currents.soest.hawaii.edu/hgstage/hgwebdir.cgi/mpl_hg/diff/799df584a8df/matplotlib/lib/matplotlib/patches.py
>>
>> The safest way to fix it--that is, preserving the old behavior of patch.fill--would be to make it a property. I can do that later today or tomorrow, or you can go ahead with it. It would be something of an inconsistency, in that for partly historical reasons mpl is based on an endless procession of getters and setters, but I don't think it would do any harm, and it does preserve the earlier API. At the same time, it would be OK to use get_fill in the PatchCollection--it will work, and it is more consistent with typical mpl usage. So, I think the best fix is to make both changes, with a comment in patches.py as to why fill is a property.
>
> I was wondering whether it would be possible at least for now to implement the get_fill() fix in PatchCollection? One of the packages I develop (http://aplpy.sourceforge.net/) depends on match_original, and recent svn versions of matplotlib are unusable because of this.
>
I broke it, so I fixed it: maintenance branch 8673, trunk 8674.
Sorry for the delay.
Eric

On Wed, Sep 1, 2010 at 12:57 PM, Thomas Robitaille
<tho...@gm...> wrote:
>>>> I have submitted a ticket: https://sourceforge.net/tracker/?group_id=80706&atid=560720
>>>
>>> The obvious fix would be to change from patch.fill to
>>> patch.get_fill(). However, I'm curious how this code got broken.
>>
>> I broke it here: http://currents.soest.hawaii.edu/hgstage/hgwebdir.cgi/mpl_hg/diff/799df584a8df/matplotlib/lib/matplotlib/patches.py
>>
>> The safest way to fix it--that is, preserving the old behavior of patch.fill--would be to make it a property. I can do that later today or tomorrow, or you can go ahead with it. It would be something of an inconsistency, in that for partly historical reasons mpl is based on an endless procession of getters and setters, but I don't think it would do any harm, and it does preserve the earlier API. At the same time, it would be OK to use get_fill in the PatchCollection--it will work, and it is more consistent with typical mpl usage. So, I think the best fix is to make both changes, with a comment in patches.py as to why fill is a property.
>
> I was wondering whether it would be possible at least for now to implement the get_fill() fix in PatchCollection? One of the packages I develop (http://aplpy.sourceforge.net/) depends on match_original, and recent svn versions of matplotlib are unusable because of this.
It's in my queue to get it done, but probably not until tomorrow.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

>>> I have submitted a ticket: https://sourceforge.net/tracker/?group_id=80706&atid=560720
>> 
>> The obvious fix would be to change from patch.fill to
>> patch.get_fill(). However, I'm curious how this code got broken.
> 
> I broke it here: http://currents.soest.hawaii.edu/hgstage/hgwebdir.cgi/mpl_hg/diff/799df584a8df/matplotlib/lib/matplotlib/patches.py
> 
> The safest way to fix it--that is, preserving the old behavior of patch.fill--would be to make it a property. I can do that later today or tomorrow, or you can go ahead with it. It would be something of an inconsistency, in that for partly historical reasons mpl is based on an endless procession of getters and setters, but I don't think it would do any harm, and it does preserve the earlier API. At the same time, it would be OK to use get_fill in the PatchCollection--it will work, and it is more consistent with typical mpl usage. So, I think the best fix is to make both changes, with a comment in patches.py as to why fill is a property.
I was wondering whether it would be possible at least for now to implement the get_fill() fix in PatchCollection? One of the packages I develop (http://aplpy.sourceforge.net/) depends on match_original, and recent svn versions of matplotlib are unusable because of this.
Thanks!
Tom
> 
> Eric
> 
>> 
>> Eric, any ideas? SVN claims that the last change to that line was done
>> by you (based on a bug *I* reported)? It apparently worked then:
>> 
>> http://sourceforge.net/mailarchive/message.php?msg_name=487A5AE3.5070500%40gmail.com
>> 
>> Ryan
>> 
> 

From: ben...@gm... [mailto:ben...@gm...] On Behalf Of Benjamin
Root
Sent: Tuesday, August 31, 2010 23:20
 
I can confirm that evince also has a problem with the second image, but not
the first or the third images. This is using the latest matplotlib from svn.
Thank you for the confirmation, Ben.
Here's what I've found so far. I examined the Liberation sources (the SFD
files) in FontForge and as text, and I gather that some of them use a
non-standard encoding. Liberation Sans, for example, does not define a space
glyph with the name "space"; instead it defines a glyph for the non-breaking
space at code point U+00A0 with the name "uni00A0" and gives U+0020 (the plain
space) as an alternate encoding. (In the file LiberationSans-Regular.sfd,
these definitions start at line 2929.) However, matplotlib assumes that the
font uses Postscript's StandardEncoding. I suppose that when Postscript
processes "(some text) show", it looks for the space glyph under the standard
name "space" but finds nothing. Here is an excerpt of
matplotlib/ttconv/pprdrv_tt.cpp from SVN starting at line 415:
/*-------------------------------------------------------------
** Define the encoding array for this font.
** Since we don't really want to deal with converting all of
** the possible font encodings in the wild to a standard PS
** one, we just explicitly create one for each font.
-------------------------------------------------------------*/
void ttfont_encoding(TTStreamWriter& stream, struct TTFONT *font,
std::vector<int>& glyph_ids, font_type_enum target_type)
 {
 stream.putline("/Encoding StandardEncoding def");
 // if (target_type == PS_TYPE_3) {
 // stream.printf("/Encoding [ ");
 // for (std::vector<int>::const_iterator i = glyph_ids.begin();
 // i != glyph_ids.end(); ++i) {
 // const char* name = ttfont_CharStrings_getname(font, *i);
 // stream.printf("/%s ", name);
 // }
 // stream.printf("] def\n");
 // } else {
 // stream.putline("/Encoding StandardEncoding def");
 // }
 } /* end of ttfont_encoding() */
I saw in the SVN logs that the commented code for non-standard encodings had a
brief life of about a month earlier this year before being declared more
trouble than it was worth.
Getting back to the fonts, I found that not all of the Liberation fonts use
this non-standard encoding. The Liberation Sans Narrow fonts in the current
release define "space" at U+0020 with U+00A0 as an alternate encoding, and
they work fine in matplotlib EPS files. I also checked a few of the fonts in
one older release, 1.0
<https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-1.0.t
ar.gz> , and they also work correctly.
One work-around I found is to use Unicode strings for text containing spaces,
which in the EPS file causes spaces to be looked up under the glyph name
"uni00A0". If embedding Type 3 fonts, another work-around (which I only
spot-checked) is to effectively standardize the encoding by editing the EPS
file, changing "/uni00A0" to "/space" in the font definition and in glyphshow
operations that call for "/uni00A0".

On Wed, Sep 1, 2010 at 9:33 AM, Benjamin Root <ben...@ou...> wrote:
> matplotlib version 1.0 now has a few different tools that could help you.
> There is GridSpec,
>
> http://matplotlib.sourceforge.net/api/gridspec_api.html#
>
http://matplotlib.sourceforge.net/users/gridspec.html
> There is also AxesGrid1:
>
> http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/index.html#toolkit-axesgrid-index
>
axesgrid1 can do things that gridspec cannot (e.g., fixed size axes
such as 5x5 inch) , but I would recommend it for an experienced user.
Regards,
-JJ
> Maybe one of these could be what you are looking for?

On Mon, Aug 30, 2010 at 10:48 AM, Stan West <sta...@nr...> wrote:
> Greetings. The attached script saves three EPS files (also attached) of a
> figure containing a text object using the Liberation Sans font. In the three
> EPS files, the text object contains no spaces, a normal space, and a
> non-breaking space, respectively. Ghostscript handles the first and third
> files but not the second, for which it gives the message "Error: /undefined
> in --get--" at the Postscript "show" instruction for the text. I noticed
> that the second file embeds a character for the non-breaking space "uni00A0"
> but not the normal space, so I suppose that's why the error is occurring. I
> tried a few other fonts and did not see any problems. I have matplotlib v.
> 1.0.0, Python 2.6.5, and Liberation fonts 1.06.0.20100721. Would someone
> kindly look into whether this might be a bug with matplotlib or the
> Liberation fonts? Many thanks!
>
>
I can confirm that evince also has a problem with the second image, but not
the first or the third images. This is using the latest matplotlib from
svn.
The error from evince is very non-descriptive:
undefined -21
** (evince:3597): WARNING **: Error rendering thumbnail
undefined -21
Ben Root

Hello,
I have been working on a couple of interesting concoctions for matplotlib.
The first is a wrapper class called "ThinWrap" that, essentially, provides a
way to create objects that are linked to a given object. These objects can
then be subclassed for some very interesting behaviors. Which leads me to
my ReMap class.
The ReMap class is designed to be a wrapper around a Colormap object, and
the __call__ function is overloaded so that some other defined function can
modify the rgba values that comes from a call to the original colormap
object. All of this is done without modifying the original colormap. In
addition, a ReMap object can wrap another ReMap object, allowing for
stacking. As an example, I have created a ToGrayscale() ReMap class.
For your reviewing pleasure, there are two patch files. The first,
thinwrap.patch, adds the ThinWrap class to cbook.py. The second,
remap.patch, creates a new file "remap.py" that holds the ReMap class and
the ToGrayscale class. In addition, in order for things to work, a few
changes had to be made to other code:
cm.py: get_cmap() could finish the function without returning anything. I
modified it to remove the "isinstance" check that would cause
non-Colormap/non-string objects to fall into a black hole. We are gonna
have to follow duck-typing here...
colors.py: The Colormap class needs to be a new-style class for ReMap to
work properly
contour.py: Commented out code that did a isinstance() check on the cmap
that would cause ReMaps on contours to fail.
I have also included an example script to demonstrate how this wrapper class
works and the ToGrayscale() class works.
Let me know what you think!
Ben Root

On Tue, Aug 31, 2010 at 2:38 AM, imsc <raj...@gm...> wrote:
>
> Is there any development in this project. I was searching for the ways to
> change the subplot sizes, but could not find any easy or nicer way.
>
>
> --
> View this message in context:
> http://old.nabble.com/Custom-sized-and-spanning-subplots-tp20485188p29580203.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
>
>
matplotlib version 1.0 now has a few different tools that could help you.
There is GridSpec,
http://matplotlib.sourceforge.net/api/gridspec_api.html#
There is also AxesGrid1:
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/index.html#toolkit-axesgrid-index
Maybe one of these could be what you are looking for?
Ben Root