Re: [matplotlib-devel] Arc requires explicitly setting fill=False?
Yes -- that is correct. Arc's are unfillable by design -- such a thing might be possible, but it would require some extra work to the code to generate rectilinear lines around the edges of the clipped area. I think this fix is correct -- the purpose is to warn the user trying to fill an Arc that filling is not possible. Cheers, Mike Eric Firing wrote: > John Hunter wrote: > >> On Sun, May 24, 2009 at 7:20 PM, Eric Firing wrote: >> >>> Tony S Yu wrote: >>> Currently, Arc in matplotlib.patches requires that it be called with kwarg ``fill=False``. Was this behavior intentional? The code suggests that a default value was left out of the kwarg lookup. I've attached a simple patch to fix this (it still fails when fill set to True). >>> Thanks. I committed a slightly different fix. I think this handles all >>> possibilities. >>> >>> >> Michael can weigh in on this when he has a chance, but my recollection >> is that Arc was added to satisfy a JPL reported bug when one zooms >> into a small region of an ellipse -- in that case our 4 spline >> approximation code was inadequate, and in a heroic burst Michael >> provided an 8 spline interpolation limited to the viewport. Ie, >> instead of getting 4 splines for the entire ellipse, with his Arc >> class you get 8 for the segment in the viewport. As part of this, he >> decided it was mostly impossible to fully support filling, or at least >> too difficult, so he may have intentionally raised this error. So we >> should be careful here, because it may be that simple arcs, those >> where everything is in the viewport, work ok with filling, but things >> break down when his zoom optimizations are triggered. >> > > John, > > Yes, Arc is a very special-purpose class, and not really a patch at all. > Actually, according to the docstrings, the Ellipse is calculated with > 8 splines, and Arc is calculated with 8 splines for the viewable portion > alone. > > The change I made merely made it so that Arc works with no fill kwarg at > all, or with fill=False, and as before, it raises an error if > fill==True. I suspect this is the behavior Mike intended--I doubt he > meant to *require* a kwarg that can take only one value without raising > an error--but certainly he can correct me if I am mistaken. > > Eric > > >> JDH >> > > > -- > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > 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 -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] transform question
Hi MPL transform gurus (aka Mike), I'm trying to close on this "dropped spine" thing, and I have a question I think you could save me some time on. I need to get a transform that will be combined with the normal xaxis transform to shift the spine and associated ticks and tick labels by some amount. For my first incarnation, I used something like mtransforms.ScaledTranslation(offset_x,offset_y,self.figure.dpi_scale_trans) This is fine when I new the offset in points directly. However, now I'd like to support offsetting the spine to the center of the Axes. So, for this case, I'd like to calculate the offset transform required to take axes coordinate 0 and translate it to 0.5. Thus, I think I need something like mtransforms.ScaledTranslation(0.5, 0, self.axes.transAxes) Unfortunately, that's clearly not working. So, is there a quick fix for this? Note that, as I've implemented things, the easiest path is that the new transform is a translation combined with the existing xaxis transform (using "get_xaxis_transform() + my_new_transform"). Other methods may be possible, but I think they'll be a lot more work. Thanks, Andrew -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] transform question
This is off the top of my head. I haven't really been following this thread and I wasn't able to determine which was the most current patch to apply. It looks like you don't actually want to apply the axes transform twice (which get_xaxis_transform() + mtransforms.ScaledTranslation(0.5, 0, self.axes.transAxes) would do). What seems to work for me is to transform the input coordinates *before* applying the existing axis transform: mtransforms.Affine2D().translate(0.0, 0.5) + self.get_xaxis_transform() I would suggest that you could keep two kinds of spine transforms (those relative to the axes and those given in points) separate. Build the whole pipeline all the time and then just allow the user to tweak either or both, and thus have something like: transform_by_axes_units + self.get_xaxis_transform() + transform_by_points Using them in combination may be rare, but isn't completely nonsensical. Hope that helps, Mike Andrew Straw wrote: > Hi MPL transform gurus (aka Mike), > > I'm trying to close on this "dropped spine" thing, and I have a question > I think you could save me some time on. > > I need to get a transform that will be combined with the normal xaxis > transform to shift the spine and associated ticks and tick labels by > some amount. For my first incarnation, I used something like > > mtransforms.ScaledTranslation(offset_x,offset_y,self.figure.dpi_scale_trans) > > This is fine when I new the offset in points directly. However, now I'd > like to support offsetting the spine to the center of the Axes. So, for > this case, I'd like to calculate the offset transform required to take > axes coordinate 0 and translate it to 0.5. Thus, I think I need > something like > > mtransforms.ScaledTranslation(0.5, 0, self.axes.transAxes) > > Unfortunately, that's clearly not working. So, is there a quick fix for > this? > > Note that, as I've implemented things, the easiest path is that the new > transform is a translation combined with the existing xaxis transform > (using "get_xaxis_transform() + my_new_transform"). Other methods may be > possible, but I think they'll be a lot more work. > > Thanks, > Andrew > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
