> From: Michael Droettboom [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 05, 2008 11:59 > > David Kaplan wrote: > > Hi, > > > > Actually your question is a good one. One of the reasons I never > > finished adding an option to text objects to rotate with respect to the > > plot (is this the correct terminology?), not the screen, is that I > > wasn't sure of the best way to implement this without making it > > hopelessly confusing for the user. > > > > One way is to add a boolean that tells the text object whether or not > > the angle is with respect to screen coordinates. In this case, > > text_obj.get_rotation() would return the angle in whichever coordinate > > system is the active one based on the boolean, unless an option to > > get_rotation is specified that would force the angle to the screen > > coordinate system (this option would then be used by show methods to > > assure they get the correct angle for plotting on the screen). > > Similarly, set_rotation would set the angle in the active system. The > > disadvantage of this approach is that it can be pretty confusing - > > unless you consult the boolean, you don't know what your angle is > > measured relative to. > > > > Another approach would be to add a ._rotationPlot variable, as well > > as .get_rotationPlot and .set_rotationPlot text-object methods. In this > > case, using set_rotation would set the "active" angle to be the screen > > angle, while using set_rotationPlot would set the "active" angle to be > > the plot angle. The non-active angle would be set to None and show > > calls would test for whether or not ._rotation is none, in which case > > the screen angle would be calculated from the transform. In this case, > > get_rotation and get_rotationPlot would return angles in the respective > > system, regardless of which one is "active". > > > > What structure would people prefer? > > > I think the latter choice presents less confusion, particularly after > hearing your arguments. It should probably be rotation_plot, just to be > consistent with other getters/setters. There should probably also be a > check and warning for setting rotation_plot for figure text, where it > doesn't make sense, and fall back to the identity transform.
Beyond the two options of the screen coordinates and the data coordinates as the references, I believe it would be useful to allow other coordinate systems. If I wanted to diagonally watermark an entire figure with, say, "DRAFT" or "PRELIMINARY," it would be convenient to specify a rotation of +/- 45 degrees relative to the normalized (0-1) figure coordinates. The watermark would lie along the diagonal regardless of the aspect ratio. Likewise, to watermark only a subplot, one might use the normalized axes coordinates. It seems especially convenient if users could accomplish that by passing to the text object one of the predefined transforms -- like ax.transData, fig.transFigure, or ax.transAxes -- to specify the coordinate system for the rotation. Would it be possible to specify the reference system and rotation angle in a composite transform using transform machinery such as rotate_deg or rotate_deg_around? > > Another reason I never finished this is that I got confused by some of > > the code - there was talk of unitful and unitless rotations and > > coordinates. > Hopefully someone else has some guidance on unit-related issues. I > still don't have my head around that stuff. > > Also, I wasn't sure what to do with objects that inherit > > the text object class - namely, text with a dash. It didn't seem it was > > worth adding this non-screen rotation functionality to these objects. > > > What is the argument against? It seems like this would be > straightforward (at least from the outside). But I'm probably missing > something. > > If anyone can point me in the right direction on these points, I will > > try to finish a patch for this functionality. > > > Thanks. > > Mike > > Cheers, > > David > > > > On Wed, 2008-11-05 at 10:28 -0500, Michael Droettboom wrote: > > > >> Darn clogged e-mail queue! ;) > >> > >> I see you've already addressed my question... > >> > >> Cheers, > >> Mike > >> > >> David Kaplan wrote: > >> > >>> Hi, > >>> > >>> I just wanted to send a note saying that I committed an additional > >>> method to the Transforms class that transforms angles. The basic idea > >>> is to transform an angle at a point to a new angle at the corresponding > >>> point in the transformed coordinate system. The included method is > >>> generic and should work well for almost any transform provided that the > >>> spatial scale isn't too small or too large. Much faster algorithms that > >>> would work regardless of spatial scale can be found for particular > >>> transforms, particularly affine transforms, but I haven't added these > >>> yet. > >>> > >>> I also added an example script that shows how to use this method to plot > >>> text rotated so that it aligns with a line in a figure > >>> ( text_rotation_relative_to_line.py ). > >>> > >>> I initially intended to use this method to give text objects the option > >>> to be rotated with respect to the plot coordinate system (as opposed to > >>> the screen coordinate system), but I haven't gotten around to finishing > >>> this yet. > >>> > >>> Cheers, > >>> David > >>> > >>> > >>> > >>> > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA Stan ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
