Re: [matplotlib-devel] transform_angles
Hi, On Wed, 2008-11-05 at 11:58 -0500, Michael Droettboom wrote: > What is the argument against? It seems like this would be > straightforward (at least from the outside). But I'm probably > missing > something. More work for diminishing interest Perhaps I am incorrect, but I think this object is only used for legends and axes labels, which probably wouldn't use this feature. If I remember correctly, there was also the problem that the dash had its own rotation angle, which would require a whole other set of corresponding variables and methods to select the coordinate system for the dash I think I saw this and just decided to raise not implemented warnings on attempts to set non-screen coordinate system rotations. Is there a strong desire for adding this feature to text with dash? Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - 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
Re: [matplotlib-devel] transform_angles
Hi, On Wed, 2008-11-05 at 13:28 -0500, Stan West wrote: > 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? > This is an interesting suggestion, but seems like it is (a) a bit out of my league and (b) like it would bring up other issues, such as which coordinate system to use for interpreting the location given to the text function for the text object. The standard way this problem has been dealt with is to create an invisible axes that covers your entire plot and add a text object to that axes. Can this method do the trick for you? Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - 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
Re: [matplotlib-devel] transform_angles
David Kaplan wrote: > Hi, > > On Wed, 2008-11-05 at 11:58 -0500, Michael Droettboom wrote: > >> What is the argument against? It seems like this would be >> straightforward (at least from the outside). But I'm probably >> missing >> something. >> > > More work for diminishing interest Perhaps I am incorrect, but I > think this object is only used for legends and axes labels, which > probably wouldn't use this feature. > > If I remember correctly, there was also the problem that the dash had > its own rotation angle, which would require a whole other set of > corresponding variables and methods to select the coordinate system for > the dash > > I think I saw this and just decided to raise not implemented warnings on > attempts to set non-screen coordinate system rotations. > > Is there a strong desire for adding this feature to text with dash? > Thanks. I see the complications now. I agree -- let's not worry about TextWithDash for now, except for possibly warning or throwing when trying to use this new feature with a TextWithDash. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - 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
Re: [matplotlib-devel] SVG clickable images
Thanks Michael,
I've attached a new diff file which I believe also has all the
necessary changes to the collections and images. I've also attached
two simple scripts which test the collections and image functionality.
I've had to make some modification to extension code in this patch
which is definitely not my area of expertise so it would be worth
someone more experienced casting an eye over this.
I've tested this on Linux and successfully run the backend_driver.py
file (or at least, it failed with the same errors as before I applied
the patch!).
Any other comments welcome
Thanks
On Wed, Nov 5, 2008 at 2:31 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> This looks great to me. I can confirm that this works on Linux as well.
>
> I think from here it's just a matter of applying the same pattern of changes
> to collections and images. Once that's done, I'm happy to apply the patch.
> And if you plan to make a lot of changes in the future, it generally pretty
> easy to get commit access. Just ask.
>
> Mike
>
> Andrew Stock wrote:
>>
>> Hi,
>>
>> I've attached a diff file which implements the basic functionality. It
>> currently doesn't handle collections or draw_image, but I wanted to
>> get something simple working first, before expanding the scope. A
>> simple test program is as follows:
>>
>> from pylab import *
>>
>> f = figure()
>> a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')
>>
>> a.set_url('http://www.google.com')
>>
>> f.canvas.print_figure(r'c:\test.svg')
>>
>> I'd be interested in comments / feedback on the attached before I
>> start to branch out into more significant changes!
>>
>> Thanks
>>
>> Andrew
>>
>> On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <[EMAIL PROTECTED]>
>> wrote:
>>
>>>
>>> I realised in my earlier message, I didn't really address your initial
>>> request for feedback on your approach.
>>>
>>> I think the goal here should be to make the url support as pervasive as
>>> possible wrt both plot types and backends.
>>>
>>> Many of the high-level plotting functions (such as bar()) take a standard
>>> set of "Artist" keywords. In the docs, you'll often see a table like the
>>> one at the bottom for bar():
>>>
>>>
>>> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.bar
>>>
>>> This support all happens automatically simply by adding a setter and
>>> getter
>>> to the "Artist" class. So, in Artist, simply add set_url/get_url methods
>>> and a private attribute to store the url. You shouldn't have to touch
>>> any
>>> of the high-level plotting functions to have this supported everywhere
>>> where
>>> it makes sense.
>>>
>>> Then, to use the url value, you'll want to store it in a GraphicsContext
>>> object to pass to the backend. So you'll want to add an attribute and
>>> getter/setter in GraphicsContextBase as well.
>>>
>>> All of the places where the front-end creates a gc and passes it to the
>>> backend will need to be updated (such as Artist.draw, Text.draw, perhaps
>>> others, do a grep for the public methods in RendererBase). Where it sets
>>> things like facecolor on the GraphicsContext, it should also set a url.
>>>
>>> Then, in backends where appropriate you would use the url value if
>>> present.
>>> You could start with SVG, and maybe someone can come along and add PDF
>>> support later.
>>>
>>> An additional complication for completeness is handling Collections.
>>> Collections store a list of graphics context information (facecolor,
>>> edgecolor etc.) rather than a single one. Therefore, you'll want to add
>>> set_urls/get_urls to Collection as well, and then deal with passing those
>>> values to the backend. Collections don't use a GraphicsContext class, so
>>> you'll need to add a new arg to draw_path_collection in all backends.
>>> (Refactoring this so we pass an object to the backends rather than a
>>> long
>>> list of arguments would be welcome to avoid needing to update multiple
>>> backends for these sorts of new features in the future). You will also
>>> need
>>> to update RendererBase._iter_collection to support iterating over URLs in
>>> the same way as everything else there.
>>>
>>> draw_image also doesn't use a gc, so you'll need to add an argument
>>> there.
>>>
>>> Hope that gives you a road map... Please let me know if I can help
>>> further.
>>>
>>> Mike
>>>
>>> Andrew Stock wrote:
>>>
Hi,
I have a requirement to make clickable bar charts using the SVG output
(rather than html maps).
An initial look has suggested that the following changes would be
required:
backend_bases.py: Add a url property to GraphicsContextBase
(defaulting to None, so it's all backwards compatible)
axes.py: Add a url option to the bar function and pass this on to the
constructor of the Rectangle object
patches.py: Pass the url option in the constructor for the Patch
object to the GraphicsContextBase object created in the draw function
backen
