From tcaswell at gmail.com  Sat Apr  1 16:00:49 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sat, 01 Apr 2017 20:00:49 +0000
Subject: [Matplotlib-users] bug for savefig to eps in the latest version
 of matplotlib
In-Reply-To: <0eff43bc-e1dc-2f9f-770c-8db8e6e0e0ae@gmail.com>
References: <cc105e66-f458-b198-e017-429a7320caf4@gmail.com>
 <07401b7b-992b-d339-0959-6e0662e5fdc8@gmail.com>
 <CANNq6FmAPokaSufbC5+cQVZKKwBTwetrgjxQkO_xCgXaLGcsWg@mail.gmail.com>
 <0eff43bc-e1dc-2f9f-770c-8db8e6e0e0ae@gmail.com>
Message-ID: <CAA48SF_HDv8oGA58iW3cS83kzwpNSnXo=w2L4KtiVcCpeTV6uw@mail.gmail.com>

The black is probably from a 0 alpha ending up in the output (which eps
does not support).  I wonder where you think the bug is Ben, my guess is in
the image resampling code.

Tom

On Thu, Mar 30, 2017 at 10:01 AM Xu, Bin <xubinrun at gmail.com> wrote:

> Dear Ben Root,
>
> Thanks for your suggestions. Here, I used "plt.style.use('classic')", but
> the created eps figure was still  similar to previous one or even larger...
> Incidentally, the matplotlibrc I used is the default matplotlibc in my
> version 2.0.0.
> Bin
>
>
> On 03/30/2017 09:43 PM, Benjamin Root wrote:
>
> as a test, can you activate the "classic" mode? I have a suspicion what
> this bug is. Just add "import matplotlib; matplotlib.use('classic')" before
> any plotting calls.
>
> Ben Root
>
>
> On Wed, Mar 29, 2017 at 11:16 PM, Xu, Bin <xubinrun at gmail.com> wrote:
>
> Dear all,
>
> I recently update my matplotlib to the latest version, and found
> pyplot.savefig to eps file didn't work well like previous version.
> Test script:
> ==================================
> #!/usr/bin/python -tt
> from matplotlib.colors import LogNorm
> import matplotlib.pyplot as plt
> import numpy as np
>
> # normal distribution center at x=0 and y=5
> x = np.random.randn(100000)
> y = np.random.randn(100000) + 5
>
> plt.hist2d(x, y, bins=40, norm=LogNorm())
> plt.colorbar()
> #plt.show()
> plt.savefig('test.eps')
> #plt.savefig('test.png')
> ==================================
> The result of plt.show() is just like the result of test.png, while
> test.eps has a weired large file size (more than 20 MB in other case). In
> the meantime, the facecolor for 'NaN' value in test.eps is black, different
> from test.png and previous version. I consider it is a bug here.
> How to reach the desired style (regular size, and white color for 'NaN'
> value in image)?  Thanks a lot.
> --
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Xu,Bin
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-users
>
>
>
> --
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Xu,Bin
>
> School of Materials Science and Engineering,
> Shanghai Jiao Tong University,
> 800 Dongchuan Road, Minhang,
> Shanghai 200240, China
>
> Email: xubinrun at gmail.com, xubin_materials at sjtu.edu.cn
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170401/5936eca8/attachment.html>

From tcaswell at gmail.com  Sat Apr  1 16:06:00 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sat, 01 Apr 2017 20:06:00 +0000
Subject: [Matplotlib-users] How is GUI startup implemented?
In-Reply-To: <697F21A6-D789-4A12-B1FD-1151A5B417F4@me.com>
References: <697F21A6-D789-4A12-B1FD-1151A5B417F4@me.com>
Message-ID: <CAA48SF_j_Z3CCaa5R=82tf7WcxN0AmrqEtfqr_Hm3nKLY=4uFw@mail.gmail.com>

It depends on which backend you are using.  Have a look at `pylab_setup` in
backends/__init__.py which will point you back to the underlying
backend-specific functions.

Tom

On Mon, Mar 27, 2017 at 10:27 AM Jean CRUYPENYNCK <filaton at me.com> wrote:

Hi all!

I?m currently writing some Python/C++ library using *Boost.Python* on
macOS. When I import it, I get the ?famous rocket icon? bouncing in the
macOS Dock and I can?t understand why. I know that this icon appears on
macOS when Python detects that a program will interact with the GUI.
It?s something that happens with *matplotlib* as well, when running *from
matplotlib import pyplot* with the default backend.
I?m wondering how this behavior is implemented, *i.e. **where in the source
code does matplotlib call the GUI process when I execute the from
matplotlib import pyplot statement?* I believe that could help me solving
my problem with* Boost.Python*.

Thank you in advance for your answer,
Jean.
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users at python.org
https://mail.python.org/mailman/listinfo/matplotlib-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170401/a4b76ae9/attachment.html>

From tcaswell at gmail.com  Sat Apr  1 16:30:30 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sat, 01 Apr 2017 20:30:30 +0000
Subject: [Matplotlib-users] Arbitrary artist data on SVG elements
In-Reply-To: <CAFZWoGYKqD1_XpmCjbrjF+KdJwDsA0k_KQ2gRzEryETybavT4g@mail.gmail.com>
References: <CAFZWoGYKqD1_XpmCjbrjF+KdJwDsA0k_KQ2gRzEryETybavT4g@mail.gmail.com>
Message-ID: <CAA48SF-NEFrH8GzsY5_n6pzmS6f4AFMXOa0snMn9RbRc37-Tog@mail.gmail.com>

Joshua,

That is an interesting use case!

I am hesitant to add this attribute to Artist because it is very specific
to the SVG backend (none of the other backends would make use of this as
far as I know). On the other hand, a generic way to use gid to add extra
information in the SVG backend could be interesting.  I am pretty sure
there are examples of optianal backend-specific kwargs going into
`savefig`, what would the API for that look like?

Tom

On Wed, Mar 22, 2017 at 4:42 PM Joshua Klein <mobiusklein at gmail.com> wrote:

> Hello,
>
> I often embed figures as SVG graphics in web pages. As part of this
> process, I usually do the following
>
>    1.
>
>    Set gids on artists and link that gid to a set of data describing that
>    part of a graphic in an external dictionary. This includes things like
>    setting the element?s class, extra contextual information, information that
>    would be good to show in a tooltip, ids of related elements, and so forth.
>    2.
>
>    Serialize the figure into a file-like object, use an element tree
>    implementation?s XMLID to get an element id map and Element objects
>    3.
>
>    Iterate over my data dictionary from (1) and set keys in the mapped
>    Element?s attrib dictionary, using the id map from (2)
>    4.
>
>    Use the element tree implementation?s tostring function to serialize
>    the updated Element objects back into a string and then send the string out
>    as a response to a web request.
>    5.
>
>    After receiving the SVG string from the server on the client, add the
>    SVG to the page?s DOM and then hang event handlers on it (or pre-specify
>    delegated handlers) that use the added attributes to configure interactive
>    behavior.
>
> I looked at the Artist type and saw no good place to store ?arbitrary
> data?. Before I start working on this I wanted to know if anyone else had a
> better solution. I would also like to know if the devs would be opposed to
> a PR that adds an extra dictionary/attribute to every Artist instance
> created.
>
> Another alternative solution would be to find a way to push my dictionary
> mapping gids to extra attributes into the SVGRenderer and have it pass
> them as **extras to XMLWriter.element when it processes individual
> artists.
>
> Here?s a generic example of what I do currently:
>
> def plot_with_extras_for_svg(*data, **kwargs):
>     # Do the plotting, generating the id-linked data in `id_mapper`
>     ax, id_mapper = plot_my_data(*data, **kwargs)
>     xlim = ax.get_xlim()
>     ylim = ax.get_ylim()
>
>     # compute the total space used in both dimensions when dealing with
>     # negative axis bounds
>     x_size = sum(map(abs, xlim))
>     y_size = sum(map(abs, ylim))
>
>     # Map the used axis space to the drawable region dimensions
>     aspect_ratio = x_size / y_size
>     canvas_x = 8.
>     canvas_y = canvas_x / aspect_ratio
>
>     # Configure the artist to draw within the new drawable region bounds
>     fig = ax.get_figure()
>     fig.tight_layout(pad=0.2)
>     fig.patch.set_visible(False)
>     fig.set_figwidth(canvas_x)
>     fig.set_figheight(canvas_y)
>
>     ax.patch.set_visible(False)
>
>     # Perform the first serialization
>     buff = StringIO()
>     fig.savefig(buff, format='svg')
>
>     # Parse XML buffer from `buff` and configure tag attributes
>     root, ids = ET.XMLID(buff.getvalue())
>     root.attrib['class'] = 'plot-class-svg'
>     for id, attributes in id_mapper.items():
>         element = ids[id]
>         element.attrib.update({("data-" + k): str(v)
>                                for k, v in attributes.items()})
>         element.attrib['class'] = id.rsplit('-')[0]
>
>     # More drawable space shenanigans
>     min_x, min_y, max_x, max_y = map(int, root.attrib["viewBox"].split(" "))
>     min_x += 100
>     max_x += 200
>     view_box = ' '.join(map(str, (min_x, min_y, max_x, max_y)))
>     root.attrib["viewBox"] = view_box
>     width = float(root.attrib["width"][:-2]) * 1.75
>     root.attrib["width"] = "100%"
>
>     height = width / (aspect_ratio)
>
>     root.attrib["height"] = "%dpt" % (height * 1.2)
>     root.attrib["preserveAspectRatio"] = "xMinYMin meet"
>
>     # Second serialization
>     svg = ET.tostring(root)
>     plt.close(fig)
>
>     return svg
>
> Thank you
> ?
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170401/2d693775/attachment-0001.html>

From mobiusklein at gmail.com  Sat Apr  1 20:57:19 2017
From: mobiusklein at gmail.com (Joshua Klein)
Date: Sat, 1 Apr 2017 20:57:19 -0400
Subject: [Matplotlib-users] Arbitrary artist data on SVG elements
In-Reply-To: <CAA48SF-NEFrH8GzsY5_n6pzmS6f4AFMXOa0snMn9RbRc37-Tog@mail.gmail.com>
References: <CAFZWoGYKqD1_XpmCjbrjF+KdJwDsA0k_KQ2gRzEryETybavT4g@mail.gmail.com>
 <CAA48SF-NEFrH8GzsY5_n6pzmS6f4AFMXOa0snMn9RbRc37-Tog@mail.gmail.com>
Message-ID: <CAFZWoGYd_vTKWkXdGF+4O=7y_a+sJ+UyxR1bjtYUBrQUQ0cLTQ@mail.gmail.com>

Hello,

I couldn?t find an example in the gallery, but just reading Figure.savefig,
and FigureCanvasBase.print_figure it was pretty clear how extra arguments
would flow to the backend, and that appropriately prefixed keyword
arguments would insulate the the high level API.

Since the preferred approach would be to just migrate this logic into the
SVG backend, it would also be a good opportunity to expose some of the
other parts of the SVG canvas that are otherwise left constant or
effectively constant by association e.g. height vs. viewBox dimensions,
setting other attributes on the <svg> element, and the inclusion of some
extra external components like including <defs> sections as described in
svg_filter_line <http://matplotlib.org/examples/misc/svg_filter_line.html>.

Proposed implementation would be:

   1. Add keyword arguments svg_gid_data and svg_attribs to
   FigureCanvasSVG._print_svg to be passed to RendererSVG, which will be
   expected to be Mapping-like objects.
   2. Add svg_gid_data and svg_attribs arguments to RendererSVG.__init__
   and attributes by the same name.
   3. When RendererSVG begins writing the <svg> tag, use the default values
   as written, and those key-value pairs of self.svg_attribs except for
   "defs" and "extra_content" keys.
   4. After completing the opening <svg> tag, if a "extra_content" key is
   in self.svg_attribs, this content will be written verbatim into the
   output stream, where malformed XML will produce invalid markup.
   5. If "defs" is in self.svg_attribs, the value will be written into the
   stream verbatim, (or map a dict of dicts to XML? Seems too much work for
   something I don?t know enough about).
   6. When RendererSVG begins rendering an artist, it will check if the
   artist has an assigned gid by calling Artist.get_gid, and if a gid is
   set, check self.svg_gid_data for additional data to include when opening
   the artist?s appropriate tag. No translation will be done so attribute
   names will be used as-is. This could be used to set on<event> handlers
   and set the class attribute, as well as adding data-<name> attributes
   for adding semantic data to the graphical elements.

I can also fix an omission in FigureCanvasSVG.print_svgz failing to
propagate **kwargs to _print_svg.

Thank you,
Joshua Klein
?

On Sat, Apr 1, 2017 at 4:30 PM, Thomas Caswell <tcaswell at gmail.com> wrote:

> Joshua,
>
> That is an interesting use case!
>
> I am hesitant to add this attribute to Artist because it is very specific
> to the SVG backend (none of the other backends would make use of this as
> far as I know). On the other hand, a generic way to use gid to add extra
> information in the SVG backend could be interesting.  I am pretty sure
> there are examples of optianal backend-specific kwargs going into
> `savefig`, what would the API for that look like?
>
> Tom
>
> On Wed, Mar 22, 2017 at 4:42 PM Joshua Klein <mobiusklein at gmail.com>
> wrote:
>
>> Hello,
>>
>> I often embed figures as SVG graphics in web pages. As part of this
>> process, I usually do the following
>>
>>    1.
>>
>>    Set gids on artists and link that gid to a set of data describing
>>    that part of a graphic in an external dictionary. This includes things like
>>    setting the element?s class, extra contextual information, information that
>>    would be good to show in a tooltip, ids of related elements, and so forth.
>>    2.
>>
>>    Serialize the figure into a file-like object, use an element tree
>>    implementation?s XMLID to get an element id map and Element objects
>>    3.
>>
>>    Iterate over my data dictionary from (1) and set keys in the mapped
>>    Element?s attrib dictionary, using the id map from (2)
>>    4.
>>
>>    Use the element tree implementation?s tostring function to serialize
>>    the updated Element objects back into a string and then send the string out
>>    as a response to a web request.
>>    5.
>>
>>    After receiving the SVG string from the server on the client, add the
>>    SVG to the page?s DOM and then hang event handlers on it (or pre-specify
>>    delegated handlers) that use the added attributes to configure interactive
>>    behavior.
>>
>> I looked at the Artist type and saw no good place to store ?arbitrary
>> data?. Before I start working on this I wanted to know if anyone else had a
>> better solution. I would also like to know if the devs would be opposed to
>> a PR that adds an extra dictionary/attribute to every Artist instance
>> created.
>>
>> Another alternative solution would be to find a way to push my dictionary
>> mapping gids to extra attributes into the SVGRenderer and have it pass
>> them as **extras to XMLWriter.element when it processes individual
>> artists.
>>
>> Here?s a generic example of what I do currently:
>>
>> def plot_with_extras_for_svg(*data, **kwargs):
>>     # Do the plotting, generating the id-linked data in `id_mapper`
>>     ax, id_mapper = plot_my_data(*data, **kwargs)
>>     xlim = ax.get_xlim()
>>     ylim = ax.get_ylim()
>>
>>     # compute the total space used in both dimensions when dealing with
>>     # negative axis bounds
>>     x_size = sum(map(abs, xlim))
>>     y_size = sum(map(abs, ylim))
>>
>>     # Map the used axis space to the drawable region dimensions
>>     aspect_ratio = x_size / y_size
>>     canvas_x = 8.
>>     canvas_y = canvas_x / aspect_ratio
>>
>>     # Configure the artist to draw within the new drawable region bounds
>>     fig = ax.get_figure()
>>     fig.tight_layout(pad=0.2)
>>     fig.patch.set_visible(False)
>>     fig.set_figwidth(canvas_x)
>>     fig.set_figheight(canvas_y)
>>
>>     ax.patch.set_visible(False)
>>
>>     # Perform the first serialization
>>     buff = StringIO()
>>     fig.savefig(buff, format='svg')
>>
>>     # Parse XML buffer from `buff` and configure tag attributes
>>     root, ids = ET.XMLID(buff.getvalue())
>>     root.attrib['class'] = 'plot-class-svg'
>>     for id, attributes in id_mapper.items():
>>         element = ids[id]
>>         element.attrib.update({("data-" + k): str(v)
>>                                for k, v in attributes.items()})
>>         element.attrib['class'] = id.rsplit('-')[0]
>>
>>     # More drawable space shenanigans
>>     min_x, min_y, max_x, max_y = map(int, root.attrib["viewBox"].split(" "))
>>     min_x += 100
>>     max_x += 200
>>     view_box = ' '.join(map(str, (min_x, min_y, max_x, max_y)))
>>     root.attrib["viewBox"] = view_box
>>     width = float(root.attrib["width"][:-2]) * 1.75
>>     root.attrib["width"] = "100%"
>>
>>     height = width / (aspect_ratio)
>>
>>     root.attrib["height"] = "%dpt" % (height * 1.2)
>>     root.attrib["preserveAspectRatio"] = "xMinYMin meet"
>>
>>     # Second serialization
>>     svg = ET.tostring(root)
>>     plt.close(fig)
>>
>>     return svg
>>
>> Thank you
>> ?
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170401/7bf53e49/attachment-0001.html>

From tcaswell at gmail.com  Sat Apr  1 22:02:34 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sun, 02 Apr 2017 02:02:34 +0000
Subject: [Matplotlib-users] Arbitrary artist data on SVG elements
In-Reply-To: <CAFZWoGYd_vTKWkXdGF+4O=7y_a+sJ+UyxR1bjtYUBrQUQ0cLTQ@mail.gmail.com>
References: <CAFZWoGYKqD1_XpmCjbrjF+KdJwDsA0k_KQ2gRzEryETybavT4g@mail.gmail.com>
 <CAA48SF-NEFrH8GzsY5_n6pzmS6f4AFMXOa0snMn9RbRc37-Tog@mail.gmail.com>
 <CAFZWoGYd_vTKWkXdGF+4O=7y_a+sJ+UyxR1bjtYUBrQUQ0cLTQ@mail.gmail.com>
Message-ID: <CAA48SF8VEyoOQUyuTQr0oPGzcsctpKQjgoRq4MVWPDcxGWCHUQ@mail.gmail.com>

That seems reasonable (but I don't know the svg backend super well).

One concern in the special keys in `svg_attribs`,  would reserving the keys
'defs' and 'extra_content' get in the way of users?  It may be better to do
this as 4 parameters.

For 5 if you are not sure maybe just skip it for now?

For 4 is it possible/reasonable to validate the xml before we write it?

On Sat, Apr 1, 2017 at 8:57 PM Joshua Klein <mobiusklein at gmail.com> wrote:

> Hello,
>
> I couldn?t find an example in the gallery, but just reading Figure.savefig,
> and FigureCanvasBase.print_figure it was pretty clear how extra arguments
> would flow to the backend, and that appropriately prefixed keyword
> arguments would insulate the the high level API.
>
> Since the preferred approach would be to just migrate this logic into the
> SVG backend, it would also be a good opportunity to expose some of the
> other parts of the SVG canvas that are otherwise left constant or
> effectively constant by association e.g. height vs. viewBox dimensions,
> setting other attributes on the <svg> element, and the inclusion of some
> extra external components like including <defs> sections as described in
> svg_filter_line <http://matplotlib.org/examples/misc/svg_filter_line.html>
> .
>
> Proposed implementation would be:
>
>    1. Add keyword arguments svg_gid_data and svg_attribs to
>    FigureCanvasSVG._print_svg to be passed to RendererSVG, which will be
>    expected to be Mapping-like objects.
>    2. Add svg_gid_data and svg_attribs arguments to RendererSVG.__init__
>    and attributes by the same name.
>    3. When RendererSVG begins writing the <svg> tag, use the default
>    values as written, and those key-value pairs of self.svg_attribs
>    except for "defs" and "extra_content" keys.
>    4. After completing the opening <svg> tag, if a "extra_content" key is
>    in self.svg_attribs, this content will be written verbatim into the
>    output stream, where malformed XML will produce invalid markup.
>    5. If "defs" is in self.svg_attribs, the value will be written into
>    the stream verbatim, (or map a dict of dicts to XML? Seems too much work
>    for something I don?t know enough about).
>    6. When RendererSVG begins rendering an artist, it will check if the
>    artist has an assigned gid by calling Artist.get_gid, and if a gid is
>    set, check self.svg_gid_data for additional data to include when
>    opening the artist?s appropriate tag. No translation will be done so
>    attribute names will be used as-is. This could be used to set on<event>
>    handlers and set the class attribute, as well as adding data-<name>
>    attributes for adding semantic data to the graphical elements.
>
> I can also fix an omission in FigureCanvasSVG.print_svgz failing to
> propagate **kwargs to _print_svg.
>
> Thank you,
> Joshua Klein
> ?
>
> On Sat, Apr 1, 2017 at 4:30 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
>
> Joshua,
>
> That is an interesting use case!
>
> I am hesitant to add this attribute to Artist because it is very specific
> to the SVG backend (none of the other backends would make use of this as
> far as I know). On the other hand, a generic way to use gid to add extra
> information in the SVG backend could be interesting.  I am pretty sure
> there are examples of optianal backend-specific kwargs going into
> `savefig`, what would the API for that look like?
>
> Tom
>
> On Wed, Mar 22, 2017 at 4:42 PM Joshua Klein <mobiusklein at gmail.com>
> wrote:
>
> Hello,
>
> I often embed figures as SVG graphics in web pages. As part of this
> process, I usually do the following
>
>    1.
>
>    Set gids on artists and link that gid to a set of data describing that
>    part of a graphic in an external dictionary. This includes things like
>    setting the element?s class, extra contextual information, information that
>    would be good to show in a tooltip, ids of related elements, and so forth.
>    2.
>
>    Serialize the figure into a file-like object, use an element tree
>    implementation?s XMLID to get an element id map and Element objects
>    3.
>
>    Iterate over my data dictionary from (1) and set keys in the mapped
>    Element?s attrib dictionary, using the id map from (2)
>    4.
>
>    Use the element tree implementation?s tostring function to serialize
>    the updated Element objects back into a string and then send the string out
>    as a response to a web request.
>    5.
>
>    After receiving the SVG string from the server on the client, add the
>    SVG to the page?s DOM and then hang event handlers on it (or pre-specify
>    delegated handlers) that use the added attributes to configure interactive
>    behavior.
>
> I looked at the Artist type and saw no good place to store ?arbitrary
> data?. Before I start working on this I wanted to know if anyone else had a
> better solution. I would also like to know if the devs would be opposed to
> a PR that adds an extra dictionary/attribute to every Artist instance
> created.
>
> Another alternative solution would be to find a way to push my dictionary
> mapping gids to extra attributes into the SVGRenderer and have it pass
> them as **extras to XMLWriter.element when it processes individual
> artists.
>
> Here?s a generic example of what I do currently:
>
> def plot_with_extras_for_svg(*data, **kwargs):
>     # Do the plotting, generating the id-linked data in `id_mapper`
>     ax, id_mapper = plot_my_data(*data, **kwargs)
>     xlim = ax.get_xlim()
>     ylim = ax.get_ylim()
>
>     # compute the total space used in both dimensions when dealing with
>     # negative axis bounds
>     x_size = sum(map(abs, xlim))
>     y_size = sum(map(abs, ylim))
>
>     # Map the used axis space to the drawable region dimensions
>     aspect_ratio = x_size / y_size
>     canvas_x = 8.
>     canvas_y = canvas_x / aspect_ratio
>
>     # Configure the artist to draw within the new drawable region bounds
>     fig = ax.get_figure()
>     fig.tight_layout(pad=0.2)
>     fig.patch.set_visible(False)
>     fig.set_figwidth(canvas_x)
>     fig.set_figheight(canvas_y)
>
>     ax.patch.set_visible(False)
>
>     # Perform the first serialization
>     buff = StringIO()
>     fig.savefig(buff, format='svg')
>
>     # Parse XML buffer from `buff` and configure tag attributes
>     root, ids = ET.XMLID(buff.getvalue())
>     root.attrib['class'] = 'plot-class-svg'
>     for id, attributes in id_mapper.items():
>         element = ids[id]
>         element.attrib.update({("data-" + k): str(v)
>                                for k, v in attributes.items()})
>         element.attrib['class'] = id.rsplit('-')[0]
>
>     # More drawable space shenanigans
>     min_x, min_y, max_x, max_y = map(int, root.attrib["viewBox"].split(" "))
>     min_x += 100
>     max_x += 200
>     view_box = ' '.join(map(str, (min_x, min_y, max_x, max_y)))
>     root.attrib["viewBox"] = view_box
>     width = float(root.attrib["width"][:-2]) * 1.75
>     root.attrib["width"] = "100%"
>
>     height = width / (aspect_ratio)
>
>     root.attrib["height"] = "%dpt" % (height * 1.2)
>     root.attrib["preserveAspectRatio"] = "xMinYMin meet"
>
>     # Second serialization
>     svg = ET.tostring(root)
>     plt.close(fig)
>
>     return svg
>
> Thank you
> ?
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170402/4da4bc7b/attachment-0001.html>

From mobiusklein at gmail.com  Sat Apr  1 22:39:46 2017
From: mobiusklein at gmail.com (Joshua Klein)
Date: Sat, 1 Apr 2017 22:39:46 -0400
Subject: [Matplotlib-users] Arbitrary artist data on SVG elements
In-Reply-To: <CAA48SF8VEyoOQUyuTQr0oPGzcsctpKQjgoRq4MVWPDcxGWCHUQ@mail.gmail.com>
References: <CAFZWoGYKqD1_XpmCjbrjF+KdJwDsA0k_KQ2gRzEryETybavT4g@mail.gmail.com>
 <CAA48SF-NEFrH8GzsY5_n6pzmS6f4AFMXOa0snMn9RbRc37-Tog@mail.gmail.com>
 <CAFZWoGYd_vTKWkXdGF+4O=7y_a+sJ+UyxR1bjtYUBrQUQ0cLTQ@mail.gmail.com>
 <CAA48SF8VEyoOQUyuTQr0oPGzcsctpKQjgoRq4MVWPDcxGWCHUQ@mail.gmail.com>
Message-ID: <CAFZWoGZdOFWdeUkAyJHjLhVXwH=q02ZUxj0hsRyN9=0mquLTgw@mail.gmail.com>

5 could just be folded into 4 just by writing defs as raw XML. As for
validating the extra content XML, it?s possible to validate the markup
syntax, but it?s not easy to validate the SVG semantics of the markup.
Syntactic validation can be carried out just using the standard library?s
xml.etree.ElementTree.fromstring for detection, wrapped in a try-except to
catch the initial error and raise a more informative error.
?

On Sat, Apr 1, 2017 at 10:02 PM, Thomas Caswell <tcaswell at gmail.com> wrote:

> That seems reasonable (but I don't know the svg backend super well).
>
> One concern in the special keys in `svg_attribs`,  would reserving the
> keys 'defs' and 'extra_content' get in the way of users?  It may be better
> to do this as 4 parameters.
>
> For 5 if you are not sure maybe just skip it for now?
>
> For 4 is it possible/reasonable to validate the xml before we write it?
>
> On Sat, Apr 1, 2017 at 8:57 PM Joshua Klein <mobiusklein at gmail.com> wrote:
>
>> Hello,
>>
>> I couldn?t find an example in the gallery, but just reading
>> Figure.savefig, and FigureCanvasBase.print_figure it was pretty clear
>> how extra arguments would flow to the backend, and that appropriately
>> prefixed keyword arguments would insulate the the high level API.
>>
>> Since the preferred approach would be to just migrate this logic into the
>> SVG backend, it would also be a good opportunity to expose some of the
>> other parts of the SVG canvas that are otherwise left constant or
>> effectively constant by association e.g. height vs. viewBox dimensions,
>> setting other attributes on the <svg> element, and the inclusion of some
>> extra external components like including <defs> sections as described in
>> svg_filter_line
>> <http://matplotlib.org/examples/misc/svg_filter_line.html>.
>>
>> Proposed implementation would be:
>>
>>    1. Add keyword arguments svg_gid_data and svg_attribs to
>>    FigureCanvasSVG._print_svg to be passed to RendererSVG, which will be
>>    expected to be Mapping-like objects.
>>    2. Add svg_gid_data and svg_attribs arguments to RendererSVG.__init__
>>    and attributes by the same name.
>>    3. When RendererSVG begins writing the <svg> tag, use the default
>>    values as written, and those key-value pairs of self.svg_attribs
>>    except for "defs" and "extra_content" keys.
>>    4. After completing the opening <svg> tag, if a "extra_content" key
>>    is in self.svg_attribs, this content will be written verbatim into
>>    the output stream, where malformed XML will produce invalid markup.
>>    5. If "defs" is in self.svg_attribs, the value will be written into
>>    the stream verbatim, (or map a dict of dicts to XML? Seems too much work
>>    for something I don?t know enough about).
>>    6. When RendererSVG begins rendering an artist, it will check if the
>>    artist has an assigned gid by calling Artist.get_gid, and if a gid is
>>    set, check self.svg_gid_data for additional data to include when
>>    opening the artist?s appropriate tag. No translation will be done so
>>    attribute names will be used as-is. This could be used to set
>>    on<event> handlers and set the class attribute, as well as adding
>>    data-<name> attributes for adding semantic data to the graphical
>>    elements.
>>
>> I can also fix an omission in FigureCanvasSVG.print_svgz failing to
>> propagate **kwargs to _print_svg.
>>
>> Thank you,
>> Joshua Klein
>> ?
>>
>> On Sat, Apr 1, 2017 at 4:30 PM, Thomas Caswell <tcaswell at gmail.com>
>> wrote:
>>
>> Joshua,
>>
>> That is an interesting use case!
>>
>> I am hesitant to add this attribute to Artist because it is very specific
>> to the SVG backend (none of the other backends would make use of this as
>> far as I know). On the other hand, a generic way to use gid to add extra
>> information in the SVG backend could be interesting.  I am pretty sure
>> there are examples of optianal backend-specific kwargs going into
>> `savefig`, what would the API for that look like?
>>
>> Tom
>>
>> On Wed, Mar 22, 2017 at 4:42 PM Joshua Klein <mobiusklein at gmail.com>
>> wrote:
>>
>> Hello,
>>
>> I often embed figures as SVG graphics in web pages. As part of this
>> process, I usually do the following
>>
>>    1.
>>
>>    Set gids on artists and link that gid to a set of data describing
>>    that part of a graphic in an external dictionary. This includes things like
>>    setting the element?s class, extra contextual information, information that
>>    would be good to show in a tooltip, ids of related elements, and so forth.
>>    2.
>>
>>    Serialize the figure into a file-like object, use an element tree
>>    implementation?s XMLID to get an element id map and Element objects
>>    3.
>>
>>    Iterate over my data dictionary from (1) and set keys in the mapped
>>    Element?s attrib dictionary, using the id map from (2)
>>    4.
>>
>>    Use the element tree implementation?s tostring function to serialize
>>    the updated Element objects back into a string and then send the string out
>>    as a response to a web request.
>>    5.
>>
>>    After receiving the SVG string from the server on the client, add the
>>    SVG to the page?s DOM and then hang event handlers on it (or pre-specify
>>    delegated handlers) that use the added attributes to configure interactive
>>    behavior.
>>
>> I looked at the Artist type and saw no good place to store ?arbitrary
>> data?. Before I start working on this I wanted to know if anyone else had a
>> better solution. I would also like to know if the devs would be opposed to
>> a PR that adds an extra dictionary/attribute to every Artist instance
>> created.
>>
>> Another alternative solution would be to find a way to push my dictionary
>> mapping gids to extra attributes into the SVGRenderer and have it pass
>> them as **extras to XMLWriter.element when it processes individual
>> artists.
>>
>> Here?s a generic example of what I do currently:
>>
>> def plot_with_extras_for_svg(*data, **kwargs):
>>     # Do the plotting, generating the id-linked data in `id_mapper`
>>     ax, id_mapper = plot_my_data(*data, **kwargs)
>>     xlim = ax.get_xlim()
>>     ylim = ax.get_ylim()
>>
>>     # compute the total space used in both dimensions when dealing with
>>     # negative axis bounds
>>     x_size = sum(map(abs, xlim))
>>     y_size = sum(map(abs, ylim))
>>
>>     # Map the used axis space to the drawable region dimensions
>>     aspect_ratio = x_size / y_size
>>     canvas_x = 8.
>>     canvas_y = canvas_x / aspect_ratio
>>
>>     # Configure the artist to draw within the new drawable region bounds
>>     fig = ax.get_figure()
>>     fig.tight_layout(pad=0.2)
>>     fig.patch.set_visible(False)
>>     fig.set_figwidth(canvas_x)
>>     fig.set_figheight(canvas_y)
>>
>>     ax.patch.set_visible(False)
>>
>>     # Perform the first serialization
>>     buff = StringIO()
>>     fig.savefig(buff, format='svg')
>>
>>     # Parse XML buffer from `buff` and configure tag attributes
>>     root, ids = ET.XMLID(buff.getvalue())
>>     root.attrib['class'] = 'plot-class-svg'
>>     for id, attributes in id_mapper.items():
>>         element = ids[id]
>>         element.attrib.update({("data-" + k): str(v)
>>                                for k, v in attributes.items()})
>>         element.attrib['class'] = id.rsplit('-')[0]
>>
>>     # More drawable space shenanigans
>>     min_x, min_y, max_x, max_y = map(int, root.attrib["viewBox"].split(" "))
>>     min_x += 100
>>     max_x += 200
>>     view_box = ' '.join(map(str, (min_x, min_y, max_x, max_y)))
>>     root.attrib["viewBox"] = view_box
>>     width = float(root.attrib["width"][:-2]) * 1.75
>>     root.attrib["width"] = "100%"
>>
>>     height = width / (aspect_ratio)
>>
>>     root.attrib["height"] = "%dpt" % (height * 1.2)
>>     root.attrib["preserveAspectRatio"] = "xMinYMin meet"
>>
>>     # Second serialization
>>     svg = ET.tostring(root)
>>     plt.close(fig)
>>
>>     return svg
>>
>> Thank you
>> ?
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-users
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170401/8c6a01cc/attachment-0001.html>

From ben.v.root at gmail.com  Mon Apr  3 11:00:44 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Mon, 3 Apr 2017 11:00:44 -0400
Subject: [Matplotlib-users] bug for savefig to eps in the latest version
 of matplotlib
In-Reply-To: <CAA48SF_HDv8oGA58iW3cS83kzwpNSnXo=w2L4KtiVcCpeTV6uw@mail.gmail.com>
References: <cc105e66-f458-b198-e017-429a7320caf4@gmail.com>
 <07401b7b-992b-d339-0959-6e0662e5fdc8@gmail.com>
 <CANNq6FmAPokaSufbC5+cQVZKKwBTwetrgjxQkO_xCgXaLGcsWg@mail.gmail.com>
 <0eff43bc-e1dc-2f9f-770c-8db8e6e0e0ae@gmail.com>
 <CAA48SF_HDv8oGA58iW3cS83kzwpNSnXo=w2L4KtiVcCpeTV6uw@mail.gmail.com>
Message-ID: <CANNq6F=v=MOrNexm7O-qdm47hh+W+H7fN+A2S4ZTPfN2bfvnJg@mail.gmail.com>

I was thinking it was possibly a change in background, but that would have
been tied to the style change. Since the bug is in both syles, my original
theory doesn't pan out.

Ben Root

On Sat, Apr 1, 2017 at 4:00 PM, Thomas Caswell <tcaswell at gmail.com> wrote:

> The black is probably from a 0 alpha ending up in the output (which eps
> does not support).  I wonder where you think the bug is Ben, my guess is in
> the image resampling code.
>
> Tom
>
> On Thu, Mar 30, 2017 at 10:01 AM Xu, Bin <xubinrun at gmail.com> wrote:
>
>> Dear Ben Root,
>>
>> Thanks for your suggestions. Here, I used "plt.style.use('classic')", but
>> the created eps figure was still  similar to previous one or even larger...
>> Incidentally, the matplotlibrc I used is the default matplotlibc in my
>> version 2.0.0.
>> Bin
>>
>>
>> On 03/30/2017 09:43 PM, Benjamin Root wrote:
>>
>> as a test, can you activate the "classic" mode? I have a suspicion what
>> this bug is. Just add "import matplotlib; matplotlib.use('classic')" before
>> any plotting calls.
>>
>> Ben Root
>>
>>
>> On Wed, Mar 29, 2017 at 11:16 PM, Xu, Bin <xubinrun at gmail.com> wrote:
>>
>> Dear all,
>>
>> I recently update my matplotlib to the latest version, and found
>> pyplot.savefig to eps file didn't work well like previous version.
>> Test script:
>> ==================================
>> #!/usr/bin/python -tt
>> from matplotlib.colors import LogNorm
>> import matplotlib.pyplot as plt
>> import numpy as np
>>
>> # normal distribution center at x=0 and y=5
>> x = np.random.randn(100000)
>> y = np.random.randn(100000) + 5
>>
>> plt.hist2d(x, y, bins=40, norm=LogNorm())
>> plt.colorbar()
>> #plt.show()
>> plt.savefig('test.eps')
>> #plt.savefig('test.png')
>> ==================================
>> The result of plt.show() is just like the result of test.png, while
>> test.eps has a weired large file size (more than 20 MB in other case). In
>> the meantime, the facecolor for 'NaN' value in test.eps is black, different
>> from test.png and previous version. I consider it is a bug here.
>> How to reach the desired style (regular size, and white color for 'NaN'
>> value in image)?  Thanks a lot.
>> --
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Xu,Bin
>>
>>
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-users
>>
>>
>>
>> --
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Xu,Bin
>>
>> School of Materials Science and Engineering,
>> Shanghai Jiao Tong University,
>> 800 Dongchuan Road, Minhang,
>> Shanghai 200240, China
>>
>> Email: xubinrun at gmail.com, xubin_materials at sjtu.edu.cn
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170403/77c14e25/attachment.html>

From mobiusklein at gmail.com  Mon Apr  3 13:34:14 2017
From: mobiusklein at gmail.com (Joshua Klein)
Date: Mon, 3 Apr 2017 13:34:14 -0400
Subject: [Matplotlib-users] Arbitrary artist data on SVG elements
In-Reply-To: <CAFZWoGZdOFWdeUkAyJHjLhVXwH=q02ZUxj0hsRyN9=0mquLTgw@mail.gmail.com>
References: <CAFZWoGYKqD1_XpmCjbrjF+KdJwDsA0k_KQ2gRzEryETybavT4g@mail.gmail.com>
 <CAA48SF-NEFrH8GzsY5_n6pzmS6f4AFMXOa0snMn9RbRc37-Tog@mail.gmail.com>
 <CAFZWoGYd_vTKWkXdGF+4O=7y_a+sJ+UyxR1bjtYUBrQUQ0cLTQ@mail.gmail.com>
 <CAA48SF8VEyoOQUyuTQr0oPGzcsctpKQjgoRq4MVWPDcxGWCHUQ@mail.gmail.com>
 <CAFZWoGZdOFWdeUkAyJHjLhVXwH=q02ZUxj0hsRyN9=0mquLTgw@mail.gmail.com>
Message-ID: <CAFZWoGaK7eY1x8KHYUfWG0YArU53iUVKuN4OHe_fcuH80T9p3g@mail.gmail.com>

The described functionality has been implemented and unit tests written to
exercise the new code-paths at
https://github.com/mobiusklein/matplotlib/tree/svg-extra-data, and is
passing the unit test suite on both Py2 and Py3. Before submitting a pull
request I want to document what new features are available, but I?m not
sure where is appropriate. The Figure.savefig and pyplot.savefig docstrings
don?t describe any particular keyword argument forwarding for individual
backends, and the only equivalent interface that is backend-specific that I
am aware of is PdfPages, which instantiates a whole new object that takes
over the figure-saving process.

Most of the names in backend_svg are unmentioned in the documentation
anyway since they don?t have docstrings, instead using something that looks
like doxygen comments above classes and functions. Should I migrate these
to use NumPy-style docstrings so that Sphinx can pick them up, and then
describe the additional features in the module-level and print_svg
docstrings?

Thank you,
Joshua Klein
?

On Sat, Apr 1, 2017 at 10:39 PM, Joshua Klein <mobiusklein at gmail.com> wrote:

> 5 could just be folded into 4 just by writing defs as raw XML. As for
> validating the extra content XML, it?s possible to validate the markup
> syntax, but it?s not easy to validate the SVG semantics of the markup.
> Syntactic validation can be carried out just using the standard library?s
> xml.etree.ElementTree.fromstring for detection, wrapped in a try-except
> to catch the initial error and raise a more informative error.
> ?
>
> On Sat, Apr 1, 2017 at 10:02 PM, Thomas Caswell <tcaswell at gmail.com>
> wrote:
>
>> That seems reasonable (but I don't know the svg backend super well).
>>
>> One concern in the special keys in `svg_attribs`,  would reserving the
>> keys 'defs' and 'extra_content' get in the way of users?  It may be better
>> to do this as 4 parameters.
>>
>> For 5 if you are not sure maybe just skip it for now?
>>
>> For 4 is it possible/reasonable to validate the xml before we write it?
>>
>> On Sat, Apr 1, 2017 at 8:57 PM Joshua Klein <mobiusklein at gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> I couldn?t find an example in the gallery, but just reading
>>> Figure.savefig, and FigureCanvasBase.print_figure it was pretty clear
>>> how extra arguments would flow to the backend, and that appropriately
>>> prefixed keyword arguments would insulate the the high level API.
>>>
>>> Since the preferred approach would be to just migrate this logic into
>>> the SVG backend, it would also be a good opportunity to expose some of the
>>> other parts of the SVG canvas that are otherwise left constant or
>>> effectively constant by association e.g. height vs. viewBox dimensions,
>>> setting other attributes on the <svg> element, and the inclusion of
>>> some extra external components like including <defs> sections as
>>> described in svg_filter_line
>>> <http://matplotlib.org/examples/misc/svg_filter_line.html>.
>>>
>>> Proposed implementation would be:
>>>
>>>    1. Add keyword arguments svg_gid_data and svg_attribs to
>>>    FigureCanvasSVG._print_svg to be passed to RendererSVG, which will
>>>    be expected to be Mapping-like objects.
>>>    2. Add svg_gid_data and svg_attribs arguments to RendererSVG.__init__
>>>    and attributes by the same name.
>>>    3. When RendererSVG begins writing the <svg> tag, use the default
>>>    values as written, and those key-value pairs of self.svg_attribs
>>>    except for "defs" and "extra_content" keys.
>>>    4. After completing the opening <svg> tag, if a "extra_content" key
>>>    is in self.svg_attribs, this content will be written verbatim into
>>>    the output stream, where malformed XML will produce invalid markup.
>>>    5. If "defs" is in self.svg_attribs, the value will be written into
>>>    the stream verbatim, (or map a dict of dicts to XML? Seems too much work
>>>    for something I don?t know enough about).
>>>    6. When RendererSVG begins rendering an artist, it will check if the
>>>    artist has an assigned gid by calling Artist.get_gid, and if a gid
>>>    is set, check self.svg_gid_data for additional data to include when
>>>    opening the artist?s appropriate tag. No translation will be done so
>>>    attribute names will be used as-is. This could be used to set
>>>    on<event> handlers and set the class attribute, as well as adding
>>>    data-<name> attributes for adding semantic data to the graphical
>>>    elements.
>>>
>>> I can also fix an omission in FigureCanvasSVG.print_svgz failing to
>>> propagate **kwargs to _print_svg.
>>>
>>> Thank you,
>>> Joshua Klein
>>> ?
>>>
>>> On Sat, Apr 1, 2017 at 4:30 PM, Thomas Caswell <tcaswell at gmail.com>
>>> wrote:
>>>
>>> Joshua,
>>>
>>> That is an interesting use case!
>>>
>>> I am hesitant to add this attribute to Artist because it is very
>>> specific to the SVG backend (none of the other backends would make use of
>>> this as far as I know). On the other hand, a generic way to use gid to add
>>> extra information in the SVG backend could be interesting.  I am pretty
>>> sure there are examples of optianal backend-specific kwargs going into
>>> `savefig`, what would the API for that look like?
>>>
>>> Tom
>>>
>>> On Wed, Mar 22, 2017 at 4:42 PM Joshua Klein <mobiusklein at gmail.com>
>>> wrote:
>>>
>>> Hello,
>>>
>>> I often embed figures as SVG graphics in web pages. As part of this
>>> process, I usually do the following
>>>
>>>    1.
>>>
>>>    Set gids on artists and link that gid to a set of data describing
>>>    that part of a graphic in an external dictionary. This includes things like
>>>    setting the element?s class, extra contextual information, information that
>>>    would be good to show in a tooltip, ids of related elements, and so forth.
>>>    2.
>>>
>>>    Serialize the figure into a file-like object, use an element tree
>>>    implementation?s XMLID to get an element id map and Element objects
>>>    3.
>>>
>>>    Iterate over my data dictionary from (1) and set keys in the mapped
>>>    Element?s attrib dictionary, using the id map from (2)
>>>    4.
>>>
>>>    Use the element tree implementation?s tostring function to serialize
>>>    the updated Element objects back into a string and then send the string out
>>>    as a response to a web request.
>>>    5.
>>>
>>>    After receiving the SVG string from the server on the client, add
>>>    the SVG to the page?s DOM and then hang event handlers on it (or
>>>    pre-specify delegated handlers) that use the added attributes to configure
>>>    interactive behavior.
>>>
>>> I looked at the Artist type and saw no good place to store ?arbitrary
>>> data?. Before I start working on this I wanted to know if anyone else had a
>>> better solution. I would also like to know if the devs would be opposed to
>>> a PR that adds an extra dictionary/attribute to every Artist instance
>>> created.
>>>
>>> Another alternative solution would be to find a way to push my
>>> dictionary mapping gids to extra attributes into the SVGRenderer and
>>> have it pass them as **extras to XMLWriter.element when it processes
>>> individual artists.
>>>
>>> Here?s a generic example of what I do currently:
>>>
>>> def plot_with_extras_for_svg(*data, **kwargs):
>>>     # Do the plotting, generating the id-linked data in `id_mapper`
>>>     ax, id_mapper = plot_my_data(*data, **kwargs)
>>>     xlim = ax.get_xlim()
>>>     ylim = ax.get_ylim()
>>>
>>>     # compute the total space used in both dimensions when dealing with
>>>     # negative axis bounds
>>>     x_size = sum(map(abs, xlim))
>>>     y_size = sum(map(abs, ylim))
>>>
>>>     # Map the used axis space to the drawable region dimensions
>>>     aspect_ratio = x_size / y_size
>>>     canvas_x = 8.
>>>     canvas_y = canvas_x / aspect_ratio
>>>
>>>     # Configure the artist to draw within the new drawable region bounds
>>>     fig = ax.get_figure()
>>>     fig.tight_layout(pad=0.2)
>>>     fig.patch.set_visible(False)
>>>     fig.set_figwidth(canvas_x)
>>>     fig.set_figheight(canvas_y)
>>>
>>>     ax.patch.set_visible(False)
>>>
>>>     # Perform the first serialization
>>>     buff = StringIO()
>>>     fig.savefig(buff, format='svg')
>>>
>>>     # Parse XML buffer from `buff` and configure tag attributes
>>>     root, ids = ET.XMLID(buff.getvalue())
>>>     root.attrib['class'] = 'plot-class-svg'
>>>     for id, attributes in id_mapper.items():
>>>         element = ids[id]
>>>         element.attrib.update({("data-" + k): str(v)
>>>                                for k, v in attributes.items()})
>>>         element.attrib['class'] = id.rsplit('-')[0]
>>>
>>>     # More drawable space shenanigans
>>>     min_x, min_y, max_x, max_y = map(int, root.attrib["viewBox"].split(" "))
>>>     min_x += 100
>>>     max_x += 200
>>>     view_box = ' '.join(map(str, (min_x, min_y, max_x, max_y)))
>>>     root.attrib["viewBox"] = view_box
>>>     width = float(root.attrib["width"][:-2]) * 1.75
>>>     root.attrib["width"] = "100%"
>>>
>>>     height = width / (aspect_ratio)
>>>
>>>     root.attrib["height"] = "%dpt" % (height * 1.2)
>>>     root.attrib["preserveAspectRatio"] = "xMinYMin meet"
>>>
>>>     # Second serialization
>>>     svg = ET.tostring(root)
>>>     plt.close(fig)
>>>
>>>     return svg
>>>
>>> Thank you
>>> ?
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Matplotlib-users at python.org
>>> https://mail.python.org/mailman/listinfo/matplotlib-users
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170403/15ccd151/attachment-0001.html>

From widmer.j at gmail.com  Thu Apr  6 04:21:37 2017
From: widmer.j at gmail.com (lorny)
Date: Thu, 6 Apr 2017 01:21:37 -0700 (MST)
Subject: [Matplotlib-users] Subplots problem: Last tick-formatting not
 working
Message-ID: <1491466897017-47986.post@n5.nabble.com>

Hi, I'm new here and also quite a python/matplotlib-noob (as you will be able
to recognize in my code-example).
I have a problem with *plt.subplots*: When I plot any amount of bars (or
different graphs/diags) in a for-loop through the subplots, and I try to
format the yaxis-ticklabels (using the ticker module), the ticklabels are
adapting all the subplots *except the last subplot yaxis*
Anyone any ideas or hints?
Thanks a lot for any support!
Best regards
Here is the code:
import matplotlib.pyplot as plt
import matplotlib.ticker as ticker
import numpy as np
from sympy import *
from random import randint

init_printing(use_unicode=True)
np.seterr(all='ignore')


def graph(numsubplots):
    fig1, axarr = plt.subplots(numsubplots, ncols=1, num="Subplot Problem",
figsize=(10, 15), dpi=100)
    fontsize = 16

    for i in range(0, len(axarr)):
        ax = axarr[i]
        n = 5
        indx = np.arange(1, n+1)
        width = randint(1, 5)/10
        ax.barh(indx - width/2, [4, 7, 2, 1, 9], width, color='y',
label="Me")
        ax.barh(indx + width/2, [3, 3, 0, 3, 3], width, color='r',
label="The other")
        ax.set_xlabel('Hours', fontsize=fontsize)
        ax.set_ylabel('Day', fontsize=fontsize)
        ticklabelformat(ax, which='y', step=1, formating='day %d')

        ax.set_title('Hours working a day', fontsize=fontsize)
        ax.legend(fontsize=fontsize)
        ax.grid(True)

    for i in fig1.axes:
        plt.setp(i.get_xticklabels(), visible=True, rotation=30)
    plt.yscale('linear')
    plt.tight_layout()
    fig1.subplots_adjust(hspace=0.3)
    plt.show()


def ticklabelformat(axe, which='xy', step=1, formating='%d'):
    majorlocator = ticker.MultipleLocator(step)
    majorformatter = ticker.FormatStrFormatter(formating)
    if which == 'y':
        axe.yaxis.set_major_locator(majorlocator)
        axe.yaxis.set_major_formatter(majorformatter)
    elif which == 'x':
        axe.xaxis.set_major_locator(majorlocator)
        axe.xaxis.set_major_formatter(majorformatter)
    else:
        axe.yaxis.set_major_locator(majorlocator)
        axe.yaxis.set_major_formatter(majorformatter)
        axe.xaxis.set_major_locator(majorlocator)
        axe.xaxis.set_major_formatter(majorformatter)


if __name__ == "__main__":
    graph(3)





--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Subplots-problem-Last-tick-formatting-not-working-tp47986.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170406/0ed819c6/attachment.html>

From Nicolas.Rougier at inria.fr  Thu Apr  6 07:33:23 2017
From: Nicolas.Rougier at inria.fr (Nicolas P. Rougier)
Date: Thu, 6 Apr 2017 13:33:23 +0200
Subject: [Matplotlib-users] Subplots problem: Last tick-formatting not
 working
In-Reply-To: <1491466897017-47986.post@n5.nabble.com>
References: <1491466897017-47986.post@n5.nabble.com>
Message-ID: <EFD2E243-9242-4CFE-A56D-8D11C215F092@inria.fr>


I think it comes from the line plt.yscale('linear') that will act on the last ax (because of plt.).
Instead, you can use ax.set_yscale('linear') *before* calling ticklabelformat().

Nicolas


> On 6 Apr 2017, at 10:21, lorny <widmer.j at gmail.com> wrote:
> 
> Hi, I'm new here and also quite a python/matplotlib-noob (as you will be able to recognize in my code-example).
> I have a problem with plt.subplots: When I plot any amount of bars (or different graphs/diags) in a for-loop through the subplots, and I try to format the yaxis-ticklabels (using the ticker module), the ticklabels are adapting all the subplots except the last subplot yaxis
> Anyone any ideas or hints?
> Thanks a lot for any support!
> Best regards
> 
> Here is the code:
> import matplotlib.pyplot as plt
> import matplotlib.ticker as ticker
> import numpy as np
> from sympy import *
> from random import randint
> 
> init_printing(use_unicode=True)
> np.seterr(all='ignore')
> 
> 
> def graph(numsubplots):
> fig1, axarr = plt.subplots(numsubplots, ncols=1, num="Subplot Problem", figsize=(10, 15), dpi=100)
> fontsize = 16
> 
> for i in range(0, len(axarr)):
> ax = axarr[i]
> n = 5
> indx = np.arange(1, n+1)
> width = randint(1, 5)/10
> ax.barh(indx - width/2, [4, 7, 2, 1, 9], width, color='y', label="Me")
> ax.barh(indx + width/2, [3, 3, 0, 3, 3], width, color='r', label="The other")
> ax.set_xlabel('Hours', fontsize=fontsize)
> ax.set_ylabel('Day', fontsize=fontsize)
> ticklabelformat(ax, which='y', step=1, formating='day %d')
> 
> ax.set_title('Hours working a day', fontsize=fontsize)
> ax.legend(fontsize=fontsize)
> ax.grid(True)
> 
> for i in fig1.axes:
> plt.setp(i.get_xticklabels(), visible=True, rotation=30)
> plt.yscale('linear')
> plt.tight_layout()
> fig1.subplots_adjust(hspace=0.3)
> plt.show()
> 
> 
> def ticklabelformat(axe, which='xy', step=1, formating='%d'):
> majorlocator = ticker.MultipleLocator(step)
> majorformatter = ticker.FormatStrFormatter(formating)
> if which == 'y':
> axe.yaxis.set_major_locator(majorlocator)
> axe.yaxis.set_major_formatter(majorformatter)
> elif which == 'x':
> axe.xaxis.set_major_locator(majorlocator)
> axe.xaxis.set_major_formatter(majorformatter)
> else:
> axe.yaxis.set_major_locator(majorlocator)
> axe.yaxis.set_major_formatter(majorformatter)
> axe.xaxis.set_major_locator(majorlocator)
> axe.xaxis.set_major_formatter(majorformatter)
> 
> 
> if __name__ == "__main__":
> graph(3)
> 
> 
> View this message in context: Subplots problem: Last tick-formatting not working
> Sent from the matplotlib - users mailing list archive at Nabble.com.
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-users


From widmer.j at gmail.com  Thu Apr  6 07:46:06 2017
From: widmer.j at gmail.com (lorny)
Date: Thu, 6 Apr 2017 04:46:06 -0700 (MST)
Subject: [Matplotlib-users] Subplots problem: Last tick-formatting not
 working
In-Reply-To: <EFD2E243-9242-4CFE-A56D-8D11C215F092@inria.fr>
References: <1491466897017-47986.post@n5.nabble.com>
 <EFD2E243-9242-4CFE-A56D-8D11C215F092@inria.fr>
Message-ID: <1491479166857-47988.post@n5.nabble.com>

Wow, thanks a lot, Nicolas!
I was quite blind - just added once the plt.yscale at the end, because it
was sometimes changing automatically on "log"-scale.
Now I did the change and *it worked*

Regards, Jonas



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Subplots-problem-Last-tick-formatting-not-working-tp47986p47988.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

From pierre.haessig at crans.org  Sat Apr  8 03:49:13 2017
From: pierre.haessig at crans.org (Pierre Haessig)
Date: Sat, 8 Apr 2017 09:49:13 +0200
Subject: [Matplotlib-users] width of bar plot when using pandas DatetimeIndex
Message-ID: <c42ed950-0772-b5d6-0da8-5761a01f5b34@crans.org>

Hi,

I wonder if there is a documented behavior when making a barplot with 
datetimes (more precisely pandas DatetimeIndex) as the x values.

I've pasted an example below with matplotlib 2.0 and pandas 0.19.2.

In this experiment, it seems that the width of the bars is interpreted 
as a number of days, so if I want to plot monthly data without blanks, I 
have to put width = 31. So my question is: /is it a reliable behavior 
that the bar width is a number of days when working with a DatetimeIndex? /

Notice that it is not coherent with pandas behavior: when addiding +1 on 
a monthly datetime index it adds on month.

Also, with the default width value (0.8), some of the bars are not 
visible and I don't understand why, but maybe it's a separate issue.

best,

Pierre

The example:

a = pd.date_range('2015', '2016',freq='M')

ts = pd.Series([3.,2]*6, a)

plt.bar(a, ts);

plt.bar(a, ts, width=31);

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170408/7e934731/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eadgedkoimhkmfdf.png
Type: image/png
Size: 4114 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170408/7e934731/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dgomnnplmonlhagf.png
Type: image/png
Size: 4114 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170408/7e934731/attachment-0001.png>

From i at introo.me  Sat Apr  8 12:39:51 2017
From: i at introo.me (Shiyao Ma)
Date: Sun, 9 Apr 2017 00:39:51 +0800
Subject: [Matplotlib-users] Why different figure size for screen/savefig
 even dpi is the same?
Message-ID: <CAJQX3Dx8ZNaDD7xSCr3ux5X3B0BSsgH1+jiuXnnG5Xrg8NLsbA@mail.gmail.com>

Hi,

This, http://imgur.com/a/q9UvR  contains two pictures.

One is drawn by the plt.show(), the other is by plt.savefig and then
opened by the pdf reader.

All the settings are the same, including the dpi.  ( I am using matplotlib2)

Why does the figure size differ ?

The one shown in the pdf reader seems normal, however, the one in the
default plt.show() is a little bit small.

I am on macos with retina, if that makes a difference.


Best.

From lars.bittrich at gmail.com  Wed Apr 12 10:47:45 2017
From: lars.bittrich at gmail.com (Lars Bittrich)
Date: Wed, 12 Apr 2017 16:47:45 +0200
Subject: [Matplotlib-users] Line mode of RectangleSelector broken or no
 longer intuitive
Message-ID: <CAOmr_7NOv3ob8SyTu9q=pW6WAxfsg94rv=ni3tKT5xgmZ-Qncw@mail.gmail.com>

Dear all,

I recently upgraded to matplotlib 2.0 and found a regression with
RectangleSelector with drawtype='line'. A line is no longer draw between
start point and end point, but from lower left to upper right of an
imaginary rectangle. So you can no longer select a downward slope.

This behavior may have been around for some time and most users will just
use RectangleSelector with a rectangle and not a line. There has been a
mail on this list regarding the return values only:

http://matplotlib.1069221.n5.nabble.com/widgets-RectangleSelector-return-values-td47623.html

But also the interactive drawing is affected. I looked into the
corresponding code and found quite a lot of sorting of x and y values
separately. To restore the old behavior one would need many changes to the
worse from my point of view.


Please note, that the docstring for RectangleSelector still advertises the
?line?-mode even if the ?box? mode is default now. This example clearly
illustrates the problem.

However, I suggest and request for people like me, who want so select a
line in a plot to add a LineSelector instead of changing RectangleSelector
to the old behavior and maybe break some code for the ?box?-mode again.
This would be much more intuitive for new users.


I added such a LineSelector and attached a patch for widgets.py based on a
much reduced copy of RectangleSelector. There still is some code duplicated
in the _release method, which could be resolved with a common base class,
but would require more changes. Additionally, there are some changes in the
docstring of RectangleSelector to use the box-mode and change the print
statement to clearly state that start point and end point are no longer
returned. In future one could add a deprecation warning and point users to
LineSelector if the RectangleSelector is used in line-mode.


Best regards,

Lars
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170412/2c0fb814/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: widgets.patch
Type: application/octet-stream
Size: 8015 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170412/2c0fb814/attachment.obj>

From jni.soma at gmail.com  Thu Apr 13 04:34:14 2017
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Thu, 13 Apr 2017 18:34:14 +1000
Subject: [Matplotlib-users] Testing of interactive functions
Message-ID: <6098a775-4f32-4315-9b74-e533268ac0d8@Spark>

Hello,

We just got an exciting PR in scikit-image to do manual image segmentation with matplotlib:
https://github.com/scikit-image/scikit-image/pull/2584

The manual_lasso_segmentation function in particular is astoundingly simple ? a testament to the ease of use of the mpl interactive bindings. Thanks!

Because it relies on interactive clicking and click-and-dragging after a blocking call to plt.show(block=True), though, it?s tricky if not impossible to test. I?m wondering whether mpl has a testing framework for the interactive components?

Juan.

PS: Also, the layout of the undo button is a bit tricky? If you have any tips for that, we are all ears! =)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170413/5a1ae549/attachment.html>

From tcaswell at gmail.com  Thu Apr 13 09:11:46 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Thu, 13 Apr 2017 13:11:46 +0000
Subject: [Matplotlib-users] Testing of interactive functions
In-Reply-To: <6098a775-4f32-4315-9b74-e533268ac0d8@Spark>
References: <6098a775-4f32-4315-9b74-e533268ac0d8@Spark>
Message-ID: <CAA48SF9UyT1H0uGCaPL=GHm8maTHF3tR2BArtUTUBeGoFdZh-Q@mail.gmail.com>

See https://github.com/matplotlib/matplotlib/pull/8403 for one way to test
interactivity.

On Thu, Apr 13, 2017 at 4:53 AM Juan Nunez-Iglesias <jni.soma at gmail.com>
wrote:

> Hello,
>
> We just got an exciting PR in scikit-image to do manual image segmentation
> with matplotlib:
> https://github.com/scikit-image/scikit-image/pull/2584
>
> The manual_lasso_segmentation function in particular is astoundingly
> simple ? a testament to the ease of use of the mpl interactive bindings.
> Thanks!
>
> Because it relies on interactive clicking and click-and-dragging after a
> blocking call to plt.show(block=True), though, it?s tricky if not
> impossible to test. I?m wondering whether mpl has a testing framework for
> the interactive components?
>
> Juan.
>
> PS: Also, the layout of the undo button is a bit tricky? If you have any
> tips for that, we are all ears! =)
>
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170413/b7604bfd/attachment.html>

From ben.v.root at gmail.com  Thu Apr 13 09:51:08 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Thu, 13 Apr 2017 09:51:08 -0400
Subject: [Matplotlib-users] Testing of interactive functions
In-Reply-To: <CAA48SF9UyT1H0uGCaPL=GHm8maTHF3tR2BArtUTUBeGoFdZh-Q@mail.gmail.com>
References: <6098a775-4f32-4315-9b74-e533268ac0d8@Spark>
 <CAA48SF9UyT1H0uGCaPL=GHm8maTHF3tR2BArtUTUBeGoFdZh-Q@mail.gmail.com>
Message-ID: <CANNq6FmjA8tr0wU_wkm9rVgAQy1mZsvdva9Xb_-252ttsgSo3g@mail.gmail.com>

Here is something I did several years ago to have reproducible
interactivity for testing purposes. It was limited to GTK, and there are
probably better ways to do it now, but it is something.

http://matplotlib.1069221.n5.nabble.com/scripting-interaction-td28629.html

Cheers!
Ben Root


On Thu, Apr 13, 2017 at 9:11 AM, Thomas Caswell <tcaswell at gmail.com> wrote:

> See https://github.com/matplotlib/matplotlib/pull/8403 for one way to
> test interactivity.
>
> On Thu, Apr 13, 2017 at 4:53 AM Juan Nunez-Iglesias <jni.soma at gmail.com>
> wrote:
>
>> Hello,
>>
>> We just got an exciting PR in scikit-image to do manual image
>> segmentation with matplotlib:
>> https://github.com/scikit-image/scikit-image/pull/2584
>>
>> The manual_lasso_segmentation function in particular is astoundingly
>> simple ? a testament to the ease of use of the mpl interactive bindings.
>> Thanks!
>>
>> Because it relies on interactive clicking and click-and-dragging after a
>> blocking call to plt.show(block=True), though, it?s tricky if not
>> impossible to test. I?m wondering whether mpl has a testing framework for
>> the interactive components?
>>
>> Juan.
>>
>> PS: Also, the layout of the undo button is a bit tricky? If you have any
>> tips for that, we are all ears! =)
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-users
>>
>
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170413/b94f7999/attachment.html>

From pmhobson at gmail.com  Thu Apr 13 10:04:05 2017
From: pmhobson at gmail.com (Paul Hobson)
Date: Thu, 13 Apr 2017 07:04:05 -0700
Subject: [Matplotlib-users] Line mode of RectangleSelector broken or no
 longer intuitive
In-Reply-To: <CAOmr_7NOv3ob8SyTu9q=pW6WAxfsg94rv=ni3tKT5xgmZ-Qncw@mail.gmail.com>
References: <CAOmr_7NOv3ob8SyTu9q=pW6WAxfsg94rv=ni3tKT5xgmZ-Qncw@mail.gmail.com>
Message-ID: <CADT3MED+BMyNRnia5JLwumLs-DkwAgy8CR_U6itkqi-c0+jCnA@mail.gmail.com>

Lars,

Thanks for tracking this down and creating a fix. Would you mind submitting
a PR? If that's not an option for now, let us know and we'll dig further.
-paul

On Wed, Apr 12, 2017 at 7:47 AM, Lars Bittrich <lars.bittrich at gmail.com>
wrote:

> Dear all,
>
> I recently upgraded to matplotlib 2.0 and found a regression with
> RectangleSelector with drawtype='line'. A line is no longer draw between
> start point and end point, but from lower left to upper right of an
> imaginary rectangle. So you can no longer select a downward slope.
>
> This behavior may have been around for some time and most users will just
> use RectangleSelector with a rectangle and not a line. There has been a
> mail on this list regarding the return values only:
>
> http://matplotlib.1069221.n5.nabble.com/widgets-RectangleSelector-return-
> values-td47623.html
>
> But also the interactive drawing is affected. I looked into the
> corresponding code and found quite a lot of sorting of x and y values
> separately. To restore the old behavior one would need many changes to the
> worse from my point of view.
>
>
> Please note, that the docstring for RectangleSelector still advertises the
> ?line?-mode even if the ?box? mode is default now. This example clearly
> illustrates the problem.
>
> However, I suggest and request for people like me, who want so select a
> line in a plot to add a LineSelector instead of changing RectangleSelector
> to the old behavior and maybe break some code for the ?box?-mode again.
> This would be much more intuitive for new users.
>
>
> I added such a LineSelector and attached a patch for widgets.py based on a
> much reduced copy of RectangleSelector. There still is some code duplicated
> in the _release method, which could be resolved with a common base class,
> but would require more changes. Additionally, there are some changes in the
> docstring of RectangleSelector to use the box-mode and change the print
> statement to clearly state that start point and end point are no longer
> returned. In future one could add a deprecation warning and point users to
> LineSelector if the RectangleSelector is used in line-mode.
>
>
> Best regards,
>
> Lars
>
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20170413/edba85ad/attachment-0001.html>

From has2k1 at gmail.com  Tue Apr 25 19:10:41 2017
From: has2k1 at gmail.com (Hassan Kibirige)
Date: Tue, 25 Apr 2017 18:10:41 -0500
Subject: [Matplotlib-users] plotnine v0.1.0, a grammar of graphics for Python
Message-ID: <20170425231041.l5a5ojdmh4pqpfqa@System>

Matplotlib users,

I am happy to announce plotnine -- a grammar of graphics package for python.
plotnine is a fork and rewrite of "ggplot for python" (now known as ggpy).
The grammar implementation is a detailed adaptation of ggplot2 and the
plotting backend is all Matplotlib.

Although this is the first release, it should be pleasant to work with and
where it falls short, I apologise.

You can checkout the code at https://github.com/has2k1/plotnine,
the documentation at http://plotnine.readthedocs.io/en/stable/ and
if you encounter any issues please report them at
https://github.com/has2k1/plotnine/issues.

Hassan