matplotlib-devel Mailing List for matplotlib

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.