matplotlib

In article 
<CANNq6Fksj9QgnRPE8jFp_3hnpkQ9647EFUPasUgLB3CgrCik0w@...>,
 Benjamin Root <ben.root@...> wrote:

> Ok, there has been a lot of useful discussion (for both MacOSX and Windows),
> but in the end, I want to know this: Is it possible for matplotlib to
> provide a single, recommended, fully-supported-by-us method for installing
> our package (possibly for each platform?).  Could it be pip? Or some other
> option?

I think we'll always need to be able to install from source and also 
offer a binary on MacOS X.

* Build from source.

If your version of MacOS X is recent enough then building from source 
could easily be made to work (with a few minor changes to setupext.py). 
Most other projects have managed this. I may be able to find some time 
to work on this.

On the good side it would work with nearly any python build and it means 
any user can install matplotlib in the obvious fashion. For these 
reasons I think this is very much worth doing. However, it has some 
disadvantages:
- It requires that users install XCode
- I don't think the resulting build will work with older versions of 
MacOS X, because Apple's libraries aren't backward compatible. This 
means the user will run into unexpected difficulty if they build and 
distribute a bundled application. This is a serious problem and means 
that users must have a binary installer option:

* Binary installer (.mpkg or egg)

This is how things are done now. The binary installer can include 
statically linked backward compatible libraries and thus be compatible 
with many versions of MacOS X. Thus users can safely include matplotlib 
in bundled applications.

There are many choices, including Apple's build-in python, python.org, 
Enthought, ActiveState, MacPorts... Most projects, including matplotlib, 
provide binary installers for python.org python because Apple's python 
is useless for distributed apps and is hard to upgrade, and most other 
projects provide their own installers for matplotlib.


So I would hate to see matplotlib give up on binary installers, but we 
could and should improve our ability to build matplotlib from source on 
MacOS X.


Another issue is how to distribute the binary installers. I like .mpkg 
installers because they are pretty good about installing with compatible 
versions of Python. We've tried binary eggs in the past and they were 
not good about finding the right version of Python. That may have 
improved.

-- Russell

That is the same example as before.  Did I just put it in the wrong location
(i.e., messed up with symbolic links?)  Anyway, the offset_demo.py has been
committed directly to master earlier today.

Another possibility is that you have to do a "python make.py clean" first to
clear out any pickled info that might prevent detection of new scripts.

Ben

On Mon, Aug 29, 2011 at 1:29 PM, Eric Firing <efiring@...> wrote:

> doc/mpl_examples/mplot3d/**offset_demo.py
>
> Ben,
>
> Building the docs is choking on the absence of the above file.
>
> Eric
>

On 08/29/2011 08:36 AM, Benjamin Root wrote:
> That is the same example as before.  Did I just put it in the wrong
> location (i.e., messed up with symbolic links?)  Anyway, the
> offset_demo.py has been committed directly to master earlier today.

Ben,

Sorry, my mistake.  I pulled from master but forgot to update my local 
doc branch accordingly.

Eric

>
> Another possibility is that you have to do a "python make.py clean"
> first to clear out any pickled info that might prevent detection of new
> scripts.
>
> Ben
>
> On Mon, Aug 29, 2011 at 1:29 PM, Eric Firing <efiring@...
> <mailto:efiring@...>> wrote:
>
>     doc/mpl_examples/mplot3d/__offset_demo.py
>
>     Ben,
>
>     Building the docs is choking on the absence of the above file.
>
>     Eric
>
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 08/25/2011 04:09 AM, Benjamin Root wrote:
> I am currently in the process of a paper submission, and the page charge
> estimation took us for a bit of a surprise.  Luckily, most of my plots
> don't need color, and I would like to regenerate them in b&w mode.
>
> Is there some default line style cycle (I.e., ['-', '.', '--', '.-'])
> that can be set analogous to the color cycle used by default?

Something like this came up a while ago as a feature request--same sort 
of motivation, I think--but it was never implemented.

You could make a little function that would operate on line objects, 
changing colors from the color cycle to black while using those colors 
to specify line styles.

Eric

>
> Thanks,
> Ben Root

Just brain-storming here... What about two rcparams: cycle.color = true and
cycle.style = false?

This way, cycling for both colors and line styles could be turned on and off
accordingly.  Then, a b&w mode could utilize this. as well as possibly
substitute default values.

Ben Root

On Thursday, August 25, 2011, Eric Firing <efiring@...> wrote:
> On 08/25/2011 04:09 AM, Benjamin Root wrote:
>> I am currently in the process of a paper submission, and the page charge
>> estimation took us for a bit of a surprise.  Luckily, most of my plots
>> don't need color, and I would like to regenerate them in b&w mode.
>>
>> Is there some default line style cycle (I.e., ['-', '.', '--', '.-'])
>> that can be set analogous to the color cycle used by default?
>
> Something like this came up a while ago as a feature request--same sort
> of motivation, I think--but it was never implemented.
>
> You could make a little function that would operate on line objects,
> changing colors from the color cycle to black while using those colors
> to specify line styles.
>
> Eric
>
>>
>> Thanks,
>> Ben Root
>
>
------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Friday, August 26, 2011, Benjamin Root <ben.root@...> wrote:
> Just brain-storming here... What about two rcparams: cycle.color = true
and cycle.style = false?
>
> This way, cycling for both colors and line styles could be turned on and
off accordingly.  Then, a b&w mode could utilize this. as well as possibly
substitute default values.
>
> Ben Root

Taking it a step further, a cycle for markers would be nice, too.

Ben Root

On 08/24/2011 11:07 AM, Grahame Bowland wrote:
> Hi everyone
>
> I've found a few problems in the current matplotlib-py3 branch in the
> _macosx.c code. I've put the fixes in a fork here:
>    https://github.com/grahame/matplotlib-py3
> I saw a pull request for a similar patch with a lot of comments that
> seems to be stuck, so I thought I'd ask here what to do. It'd be great
> to get the master branch working on Mac.

I was worried about accepting the changes without a Mac to test them on, 
and hoping that Michiel de Hoon (the Mac backend author) would have some 
comments.  Maybe we can convince one of the other developers on this 
list who has a Mac to have a look.

> Another thing - I think I've found a str/bytes bug which I can't
> figure it out. I've attached the code, if I run it on my machine I get
> this output:
>
> Traceback (most recent call last):
>    File "crash.py", line 24, in<module>
>      fig.canvas.print_figure(open('test.png', 'wb'), bbox_inches='tight')
>    File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/backend_bases.py",
> line 1951, in print_figure
>      bbox_inches = self.figure.get_tightbbox(renderer)
>    File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
> line 1292, in get_tightbbox
>      for ax in self.axes:
>    File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
> line 290, in _get_axes
>      return self._axstack.as_list()
>    File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
> line 59, in as_list
>      ia_list = [a for k, a in self._elements]
>    File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
> line 59, in<listcomp>
>      ia_list = [a for k, a in self._elements]
> TypeError: string argument expected, got 'bytes'
>
> It's definitely something to do with the bbox_inches='tight' argument,
> if I take that out everything works. Using the debugger I can't see
> anything in any stack frame that explains the traceback - really odd!
>

Can you file an issue for this in the matplotlib-py3 github project?  
I'm busy getting the matplotlib 1.1.x release finished up at the moment, 
and don't have a working environment for Python 3 right now.  I'd hate 
for this bug to fall through the cracks.

Cheers,
Mike

On 08/24/2011 01:41 PM, Michael Droettboom wrote:
> On 08/24/2011 11:07 AM, Grahame Bowland wrote:
>
>> Another thing - I think I've found a str/bytes bug which I can't
>> figure it out. I've attached the code, if I run it on my machine I get
>> this output:
>>
>> Traceback (most recent call last):
>>     File "crash.py", line 24, in<module>
>>       fig.canvas.print_figure(open('test.png', 'wb'), bbox_inches='tight')
>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/backend_bases.py",
>> line 1951, in print_figure
>>       bbox_inches = self.figure.get_tightbbox(renderer)
>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
>> line 1292, in get_tightbbox
>>       for ax in self.axes:
>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
>> line 290, in _get_axes
>>       return self._axstack.as_list()
>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
>> line 59, in as_list
>>       ia_list = [a for k, a in self._elements]
>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
>> line 59, in<listcomp>
>>       ia_list = [a for k, a in self._elements]
>> TypeError: string argument expected, got 'bytes'
>>
>> It's definitely something to do with the bbox_inches='tight' argument,
>> if I take that out everything works. Using the debugger I can't see
>> anything in any stack frame that explains the traceback - really odd!
>>
> Can you file an issue for this in the matplotlib-py3 github project?
> I'm busy getting the matplotlib 1.1.x release finished up at the moment,
> and don't have a working environment for Python 3 right now.  I'd hate
> for this bug to fall through the cracks.
>
Indeed a confusing bug -- errors were not being returned correctly from 
the PNG extension.

Can you confirm that

https://github.com/matplotlib/matplotlib-py3/commit/927acf856bb321e22938846bb39f8b32d90172d4

resolves the issue?

Mike

On 26 August 2011 01:38, Michael Droettboom <mdroe@...> wrote:
> On 08/24/2011 01:41 PM, Michael Droettboom wrote:
>> On 08/24/2011 11:07 AM, Grahame Bowland wrote:
>>
>>> Another thing - I think I've found a str/bytes bug which I can't
>>> figure it out. I've attached the code, if I run it on my machine I get
>>> this output:
>>>
>>> Traceback (most recent call last):
>>>     File "crash.py", line 24, in<module>
>>>       fig.canvas.print_figure(open('test.png', 'wb'), bbox_inches='tight')
>>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/backend_bases.py",
>>> line 1951, in print_figure
>>>       bbox_inches = self.figure.get_tightbbox(renderer)
>>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
>>> line 1292, in get_tightbbox
>>>       for ax in self.axes:
>>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
>>> line 290, in _get_axes
>>>       return self._axstack.as_list()
>>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
>>> line 59, in as_list
>>>       ia_list = [a for k, a in self._elements]
>>>     File "/opt/shrubbery/lib/python3.2/site-packages/matplotlib/figure.py",
>>> line 59, in<listcomp>
>>>       ia_list = [a for k, a in self._elements]
>>> TypeError: string argument expected, got 'bytes'
>>>
>>> It's definitely something to do with the bbox_inches='tight' argument,
>>> if I take that out everything works. Using the debugger I can't see
>>> anything in any stack frame that explains the traceback - really odd!
>>>
>> Can you file an issue for this in the matplotlib-py3 github project?
>> I'm busy getting the matplotlib 1.1.x release finished up at the moment,
>> and don't have a working environment for Python 3 right now.  I'd hate
>> for this bug to fall through the cracks.
>>
> Indeed a confusing bug -- errors were not being returned correctly from
> the PNG extension.
>
> Can you confirm that
>
> https://github.com/matplotlib/matplotlib-py3/commit/927acf856bb321e22938846bb39f8b32d90172d4
>
> resolves the issue?

Hi Mike

Thanks very much, that solves the problem.

Cheers
Grahame

On 08/26/2011 06:23 AM, Michiel de Hoon wrote:
> Dear all,
>
> I am currently modifying the MacOSX backend to make its interactive/non-interactive behavior consistent with the other backends in matplotlib.
> When I was testing the backend, I found a new bug that seems to be related to a recent change in backend_bases.py:
>
> https://github.com/matplotlib/matplotlib/commit/4c078ddf68cc0ecc1a5f36009a3e3a8b4921b037#lib/matplotlib/backend_bases.py
>
> After this commit, GraphicsContextBase.set_alpha has no effect if alpha==None; previously it would set alpha to 1.0.
>
> The bug appears here in Text.draw in text.py:
>
>          gc = renderer.new_gc()
>          gc.set_foreground(self.get_color())
>          gc.set_alpha(self.get_alpha())
>
> In this code, self is a Text object, which derives from the Artist class, which initializes its _alpha member to None. So self.get_alpha() returns None, and gc.set_alpha has no effect. The alpha value used then depends on whatever was present in the gc before the call to new_gc, which is backend-dependent; the MacOSX and cairo backends end up with an incorrect alpha value.
>
> I guess the easiest solution is to initialize _alpha in the Artist class to 1.0 instead of to None.

No, I think this will foul up all sorts of thing.  I will take a look at 
this today or tomorrow at the latest.

Eric

>
> Thanks,
> --Michiel
>

On 08/26/2011 06:23 AM, Michiel de Hoon wrote:
> Dear all,
>
> I am currently modifying the MacOSX backend to make its interactive/non-interactive behavior consistent with the other backends in matplotlib.
> When I was testing the backend, I found a new bug that seems to be related to a recent change in backend_bases.py:

Michiel,

Thank you for doing this work on the MacOSX backend; sorry to have 
introduced a bug that you stumbled over.

>
> https://github.com/matplotlib/matplotlib/commit/4c078ddf68cc0ecc1a5f36009a3e3a8b4921b037#lib/matplotlib/backend_bases.py
>
> After this commit, GraphicsContextBase.set_alpha has no effect if alpha==None; previously it would set alpha to 1.0.
>
> The bug appears here in Text.draw in text.py:
>
>          gc = renderer.new_gc()
>          gc.set_foreground(self.get_color())
>          gc.set_alpha(self.get_alpha())
>
> In this code, self is a Text object, which derives from the Artist class, which initializes its _alpha member to None. So self.get_alpha() returns None, and gc.set_alpha has no effect. The alpha value used then depends on whatever was present in the gc before the call to new_gc, which is backend-dependent; the MacOSX and cairo backends end up with an incorrect alpha value.
>
> I guess the easiest solution is to initialize _alpha in the Artist class to 1.0 instead of to None.

See https://github.com/matplotlib/matplotlib/pull/437

The problem was occurring because the macosx and cairo backends were 
recycling their graphics context objects instead of making new 
instances, so they were not getting initialized.  I made a local fix by 
initializing the _alpha attributes; it may be that other initialization 
is actually needed as well, and that the GraphicsContextBase.__init__ 
method should be called, but I have not looked into that.  The small fix 
solves the immediate problem.

In addition, I realized that a small change in GraphicsContextBase was 
needed to properly support backends that have their own set_alpha and 
set_foreground methods in their gc class.

Eric

>
> Thanks,
> --Michiel

Thanks! That solves the problem for me.
Once these changes have made it into trunk, I can commit my changes to the MacOSX backend.

Thanks,
--Michiel

--- On Fri, 8/26/11, Eric Firing <efiring@...> wrote:

> From: Eric Firing <efiring@...>
> Subject: Re: [matplotlib-devel] graphics context: use alpha value from foreground color if present
> To: matplotlib-devel@...
> Date: Friday, August 26, 2011, 10:20 PM
> On 08/26/2011 06:23 AM, Michiel de
> Hoon wrote:
> > Dear all,
> >
> > I am currently modifying the MacOSX backend to make
> its interactive/non-interactive behavior consistent with the
> other backends in matplotlib.
> > When I was testing the backend, I found a new bug that
> seems to be related to a recent change in backend_bases.py:
> 
> Michiel,
> 
> Thank you for doing this work on the MacOSX backend; sorry
> to have 
> introduced a bug that you stumbled over.
> 
> >
> > https://github.com/matplotlib/matplotlib/commit/4c078ddf68cc0ecc1a5f36009a3e3a8b4921b037#lib/matplotlib/backend_bases.py
> >
> > After this commit, GraphicsContextBase.set_alpha has
> no effect if alpha==None; previously it would set alpha to
> 1.0.
> >
> > The bug appears here in Text.draw in text.py:
> >
> >          gc =
> renderer.new_gc()
> >         
> gc.set_foreground(self.get_color())
> >         
> gc.set_alpha(self.get_alpha())
> >
> > In this code, self is a Text object, which derives
> from the Artist class, which initializes its _alpha member
> to None. So self.get_alpha() returns None, and gc.set_alpha
> has no effect. The alpha value used then depends on whatever
> was present in the gc before the call to new_gc, which is
> backend-dependent; the MacOSX and cairo backends end up with
> an incorrect alpha value.
> >
> > I guess the easiest solution is to initialize _alpha
> in the Artist class to 1.0 instead of to None.
> 
> See https://github.com/matplotlib/matplotlib/pull/437
> 
> The problem was occurring because the macosx and cairo
> backends were 
> recycling their graphics context objects instead of making
> new 
> instances, so they were not getting initialized.  I
> made a local fix by 
> initializing the _alpha attributes; it may be that other
> initialization 
> is actually needed as well, and that the
> GraphicsContextBase.__init__ 
> method should be called, but I have not looked into
> that.  The small fix 
> solves the immediate problem.
> 
> In addition, I realized that a small change in
> GraphicsContextBase was 
> needed to properly support backends that have their own
> set_alpha and 
> set_foreground methods in their gc class.
> 
> Eric
> 
> >
> > Thanks,
> > --Michiel
> 
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified
> management 
> Up to 160% more powerful than alternatives and 25% more
> efficient. 
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 08/26/2011 08:21 PM, Michiel de Hoon wrote:
> Thanks! That solves the problem for me.
> Once these changes have made it into trunk, I can commit my changes to the MacOSX backend.

Done--I hit the merge button.

Eric

>
> Thanks,
> --Michiel
>
> --- On Fri, 8/26/11, Eric Firing<efiring@...>  wrote:
>
>> From: Eric Firing<efiring@...>
>> Subject: Re: [matplotlib-devel] graphics context: use alpha value from foreground color if present
>> To: matplotlib-devel@...
>> Date: Friday, August 26, 2011, 10:20 PM
>> On 08/26/2011 06:23 AM, Michiel de
>> Hoon wrote:
>>> Dear all,
>>>
>>> I am currently modifying the MacOSX backend to make
>> its interactive/non-interactive behavior consistent with the
>> other backends in matplotlib.
>>> When I was testing the backend, I found a new bug that
>> seems to be related to a recent change in backend_bases.py:
>>
>> Michiel,
>>
>> Thank you for doing this work on the MacOSX backend; sorry
>> to have
>> introduced a bug that you stumbled over.
>>
>>>
>>> https://github.com/matplotlib/matplotlib/commit/4c078ddf68cc0ecc1a5f36009a3e3a8b4921b037#lib/matplotlib/backend_bases.py
>>>
>>> After this commit, GraphicsContextBase.set_alpha has
>> no effect if alpha==None; previously it would set alpha to
>> 1.0.
>>>
>>> The bug appears here in Text.draw in text.py:
>>>
>>>            gc =
>> renderer.new_gc()
>>>
>> gc.set_foreground(self.get_color())
>>>
>> gc.set_alpha(self.get_alpha())
>>>
>>> In this code, self is a Text object, which derives
>> from the Artist class, which initializes its _alpha member
>> to None. So self.get_alpha() returns None, and gc.set_alpha
>> has no effect. The alpha value used then depends on whatever
>> was present in the gc before the call to new_gc, which is
>> backend-dependent; the MacOSX and cairo backends end up with
>> an incorrect alpha value.
>>>
>>> I guess the easiest solution is to initialize _alpha
>> in the Artist class to 1.0 instead of to None.
>>
>> See https://github.com/matplotlib/matplotlib/pull/437
>>
>> The problem was occurring because the macosx and cairo
>> backends were
>> recycling their graphics context objects instead of making
>> new
>> instances, so they were not getting initialized.  I
>> made a local fix by
>> initializing the _alpha attributes; it may be that other
>> initialization
>> is actually needed as well, and that the
>> GraphicsContextBase.__init__
>> method should be called, but I have not looked into
>> that.  The small fix
>> solves the immediate problem.
>>
>> In addition, I realized that a small change in
>> GraphicsContextBase was
>> needed to properly support backends that have their own
>> set_alpha and
>> set_foreground methods in their gc class.
>>
>> Eric
>>
>>>
>>> Thanks,
>>> --Michiel
>>
>> ------------------------------------------------------------------------------
>> EMC VNX: the world's simplest storage, starting under $10K
>> The only unified storage solution that offers unified
>> management
>> Up to 160% more powerful than alternatives and 25% more
>> efficient.
>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel@...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 08/23/2011 10:06 AM, David Huard wrote:
>
> You may want to try moving the "<defs>" containing the clipPath up a
>> level, so it is a peer with the histogram rectangles.
> Yep, that works.
>
>> That's just a stab in
>> the dark.  If that turns out that makes the difference, that should be an
>> easy enough fix within matplotlib.
> That would be great !

I have a fix on this branch here:

https://github.com/mdboom/matplotlib/tree/svg_references

Would you mind testing it?

> I'd be glad to contribute an example for the matplotlib gallery if
> there is an interest. I think the SVG+JS combo has a lot of potential,
> and matplotlib makes it easy.

That would make a great addition.  One small comment: I would put the 
"onclick" handler on the legend handles as well as the legend text.  I 
tried to click the legend handles (with nothing happening) until I 
realized the "hotspot" was only on the text.

For a long time, I have considered having a framework where arbitrary 
XML attributes can be assigned to artists and written out directly by 
the SVG writer to avoid the two-pass approach you're using here.  (There 
is already support for assigning hyperlinks to SVG documents, but that 
could be made more general).  But that will require some careful design 
consideration etc. to get it done.  In the meantime, it's useful having 
an example that shows how to do this using ElementTree to modify the SVG 
after matplotlib outputs it.

Cheers,
Mike

On Tue, Aug 23, 2011 at 11:29 AM, Michael Droettboom <mdroe@...> wrote:
> On 08/23/2011 10:06 AM, David Huard wrote:
>>
>> You may want to try moving the "<defs>" containing the clipPath up a
>>> level, so it is a peer with the histogram rectangles.
>> Yep, that works.
>>
>>> That's just a stab in
>>> the dark.  If that turns out that makes the difference, that should be an
>>> easy enough fix within matplotlib.
>> That would be great !
>
> I have a fix on this branch here:
>
> https://github.com/mdboom/matplotlib/tree/svg_references
>
> Would you mind testing it?

Works like a charm !

>
>> I'd be glad to contribute an example for the matplotlib gallery if
>> there is an interest. I think the SVG+JS combo has a lot of potential,
>> and matplotlib makes it easy.
>
> That would make a great addition.  One small comment: I would put the
> "onclick" handler on the legend handles as well as the legend text.  I
> tried to click the legend handles (with nothing happening) until I
> realized the "hotspot" was only on the text.

Right, done.

>
> For a long time, I have considered having a framework where arbitrary
> XML attributes can be assigned to artists and written out directly by
> the SVG writer to avoid the two-pass approach you're using here.  (There
> is already support for assigning hyperlinks to SVG documents, but that
> could be made more general).

I thought about this too. There is already a set_gid method, so I
guess generalizing this to any (attribute, value) pair should not be
too hard. On the other hand, what would also help is more hierarchy
within the svg tree. At the moment, a group is created for figure,
axes, axis, legend and collections (from a quick overview, maybe there
are others.) However, since histogram returns flat patches instead of
a collection of patches, we need to loop through all bar patches to
set their properties. If histogram returned one patchcollection per
variable, we could address this group directly instead of the
individual elements.

> But that will require some careful design
> consideration etc. to get it done.  In the meantime, it's useful having
> an example that shows how to do this using ElementTree to modify the SVG
> after matplotlib outputs it.

Good, I'll work on this then.

Thanks,

David


>
> Cheers,
> Mike
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Mike,

I forked your branch and created this one which includes the revised
histogram example.

https://github.com/huard/matplotlib/tree/interactive_svg

Cheers

David

On Tue, Aug 23, 2011 at 1:37 PM, David Huard <david.huard@...> wrote:
> On Tue, Aug 23, 2011 at 11:29 AM, Michael Droettboom <mdroe@...> wrote:
>> On 08/23/2011 10:06 AM, David Huard wrote:
>>>
>>> You may want to try moving the "<defs>" containing the clipPath up a
>>>> level, so it is a peer with the histogram rectangles.
>>> Yep, that works.
>>>
>>>> That's just a stab in
>>>> the dark.  If that turns out that makes the difference, that should be an
>>>> easy enough fix within matplotlib.
>>> That would be great !
>>
>> I have a fix on this branch here:
>>
>> https://github.com/mdboom/matplotlib/tree/svg_references
>>
>> Would you mind testing it?
>
> Works like a charm !
>
>>
>>> I'd be glad to contribute an example for the matplotlib gallery if
>>> there is an interest. I think the SVG+JS combo has a lot of potential,
>>> and matplotlib makes it easy.
>>
>> That would make a great addition.  One small comment: I would put the
>> "onclick" handler on the legend handles as well as the legend text.  I
>> tried to click the legend handles (with nothing happening) until I
>> realized the "hotspot" was only on the text.
>
> Right, done.
>
>>
>> For a long time, I have considered having a framework where arbitrary
>> XML attributes can be assigned to artists and written out directly by
>> the SVG writer to avoid the two-pass approach you're using here.  (There
>> is already support for assigning hyperlinks to SVG documents, but that
>> could be made more general).
>
> I thought about this too. There is already a set_gid method, so I
> guess generalizing this to any (attribute, value) pair should not be
> too hard. On the other hand, what would also help is more hierarchy
> within the svg tree. At the moment, a group is created for figure,
> axes, axis, legend and collections (from a quick overview, maybe there
> are others.) However, since histogram returns flat patches instead of
> a collection of patches, we need to loop through all bar patches to
> set their properties. If histogram returned one patchcollection per
> variable, we could address this group directly instead of the
> individual elements.
>
>> But that will require some careful design
>> consideration etc. to get it done.  In the meantime, it's useful having
>> an example that shows how to do this using ElementTree to modify the SVG
>> after matplotlib outputs it.
>
> Good, I'll work on this then.
>
> Thanks,
>
> David
>
>
>>
>> Cheers,
>> Mike
>>
>> ------------------------------------------------------------------------------
>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>> user administration capabilities and model configuration. Take
>> the hassle out of deploying and managing Subversion and the
>> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel@...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>