matplotlib-devel Mailing List for matplotlib

On Thu, Sep 2, 2010 at 3:51 PM, Ryan May <rm...@gm...> wrote:
> 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
I am not exactly sure how possible that would be. I am not exactly sure I
understand the rationale behind the current implementation. There is a
dictionary self._seen that stores key/axes pairs, a self.axes list storing
the axes, and a self._axstack Stack (from cbook, I believe) that also
contains the axes.
I think I understand the purpose for each container by itself, but not for
having all three together at the same time. At the very least, maybe we can
eliminate the list container? I think the difficulty there would be with
clearing the stack properly.
Ben Root

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