PDF/SVG output problems

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

PDF/SVG output problems

Jordan Ilott
I've noticed a strange problem with PDF and SVG output. Using the demo(noninteractive.py) in the examples directory will generate an SVG or PDF; however, the axis labels are not rendered. Their doesn't seem to be a problem with PNG. Strangely, if the plot is added to an OverlayPlotContainer, the axis renders normally.

A probably unrelated but parallel observation has to do with multi-page PDF output. It appears to be quite possible, simply use the same PdfGraphicsContext to render multiple plots and call PdfGraphicsContext.gc.showPage() in between renders. This calls the showPage() method of the ReportLab canvas which will put any new drawing commands on a new page. The problem: when doing this, the plots on the second and subsequent pages are shifted toward the page origin(bottom left corner) for some reason. If there is an Enable/Kiva wizard who can explain this, I would appreciate it. Replacing the draw_pdf method in the noninteractive.py with the following code demonstrates the multi-page technique and when run, the formatting problem.

def draw_pdf(filename, size=(800,600)):
    from chaco.pdf_graphics_context import PdfPlotGraphicsContext
    container = create_plot()
    container.bounds = list(size)
    container.do_layout(force=True)
    gc = PdfPlotGraphicsContext(filename=filename, dest_box = (0.5, 0.5, 5.0, 5.0))
    gc.render_component(container)
   
    #Start a new page for subsequent draw commands.
    gc.gc.showPage()

    gc.render_component(container)
    gc.save()


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: PDF/SVG output problems

John Wiggins
On Apr 9, 2013, at 9:48 AM, Jordan Ilott wrote:

> I've noticed a strange problem with PDF and SVG output. Using the demo(noninteractive.py) in the examples directory will generate an SVG or PDF; however, the axis labels are not rendered. Their doesn't seem to be a problem with PNG. Strangely, if the plot is added to an OverlayPlotContainer, the axis renders normally.

There is a bug in the PdfGraphicsContext which is ignoring the padding on the component. If I account for the padding when self.clip_to_rect() is called, the axis labels show up. If I can come up with a robust solution, I'll create a pull request.

> A probably unrelated but parallel observation has to do with multi-page PDF output. It appears to be quite possible, simply use the same PdfGraphicsContext to render multiple plots and call PdfGraphicsContext.gc.showPage() in between renders. This calls the showPage() method of the ReportLab canvas which will put any new drawing commands on a new page. The problem: when doing this, the plots on the second and subsequent pages are shifted toward the page origin(bottom left corner) for some reason. If there is an Enable/Kiva wizard who can explain this, I would appreciate it. Replacing the draw_pdf method in the noninteractive.py with the following code demonstrates the multi-page technique and when run, the formatting problem.

Not sure about this one. In my limited experience with the PDF backend, output has always been placed in the bottom left corner of the page. One page or many, it doesn't change.

> def draw_pdf(filename, size=(800,600)):
>     from chaco.pdf_graphics_context import PdfPlotGraphicsContext
>     container = create_plot()
>     container.bounds = list(size)
>     container.do_layout(force=True)
>     gc = PdfPlotGraphicsContext(filename=filename, dest_box = (0.5, 0.5, 5.0, 5.0))
>     gc.render_component(container)
>    
>     #Start a new page for subsequent draw commands.
>     gc.gc.showPage()
>
>     gc.render_component(container)
>     gc.save()
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev


-- John
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: PDF/SVG output problems

John Wiggins
Jordan,

I think I came up with an appropriate solution[1]. It works with your multipage example and doesn't have any of the bad behavior that you identified. Can you try it with your more complicated code and see if it still holds up?

[1] https://github.com/enthought/chaco/pull/109

-- John


On Apr 9, 2013, at 1:50 PM, John Wiggins wrote:

> On Apr 9, 2013, at 9:48 AM, Jordan Ilott wrote:
>
>> I've noticed a strange problem with PDF and SVG output. Using the demo(noninteractive.py) in the examples directory will generate an SVG or PDF; however, the axis labels are not rendered. Their doesn't seem to be a problem with PNG. Strangely, if the plot is added to an OverlayPlotContainer, the axis renders normally.
>
> There is a bug in the PdfGraphicsContext which is ignoring the padding on the component. If I account for the padding when self.clip_to_rect() is called, the axis labels show up. If I can come up with a robust solution, I'll create a pull request.
>
>> A probably unrelated but parallel observation has to do with multi-page PDF output. It appears to be quite possible, simply use the same PdfGraphicsContext to render multiple plots and call PdfGraphicsContext.gc.showPage() in between renders. This calls the showPage() method of the ReportLab canvas which will put any new drawing commands on a new page. The problem: when doing this, the plots on the second and subsequent pages are shifted toward the page origin(bottom left corner) for some reason. If there is an Enable/Kiva wizard who can explain this, I would appreciate it. Replacing the draw_pdf method in the noninteractive.py with the following code demonstrates the multi-page technique and when run, the formatting problem.
>
> Not sure about this one. In my limited experience with the PDF backend, output has always been placed in the bottom left corner of the page. One page or many, it doesn't change.
>
>> def draw_pdf(filename, size=(800,600)):
>>    from chaco.pdf_graphics_context import PdfPlotGraphicsContext
>>    container = create_plot()
>>    container.bounds = list(size)
>>    container.do_layout(force=True)
>>    gc = PdfPlotGraphicsContext(filename=filename, dest_box = (0.5, 0.5, 5.0, 5.0))
>>    gc.render_component(container)
>>
>>    #Start a new page for subsequent draw commands.
>>    gc.gc.showPage()
>>
>>    gc.render_component(container)
>>    gc.save()
>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>
> -- John

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: PDF/SVG output problems

Jordan Ilott-2
Thanks for looking at this John. It looks good, I've tried outputting PDF files from both DataView and VPlotContainer containers and in both cases, the axis and offset is working as expected.

I do have a thought about the add_page() method though. It's convenient to duplicate the behavior of ReportLab's showPage() because after showPage() is called, a new page is only generated if a drawing command is sent. So, if for example you're looping through plots to be stuffed into a PDF, showPage() can be placed at the end of the loop and on the last iteration, no blank page is inserted. If I use the add_page() method that you've added, the call to _initialize_page() is causing ReportLab to insert a blank page. Not calling _initialize_page() causes the offset that I described before. I'm not sure what the best solution would be. Obviously, I could add a little more logic to the loop to solve this. Your chosen name for the method should make the behavior clear but maybe _initialize_page() should be called from render? Or maybe that would break something else.

Jordan


On Tue, Apr 9, 2013 at 3:08 PM, John Wiggins <[hidden email]> wrote:
Jordan,

I think I came up with an appropriate solution[1]. It works with your multipage example and doesn't have any of the bad behavior that you identified. Can you try it with your more complicated code and see if it still holds up?

[1] https://github.com/enthought/chaco/pull/109

-- John


On Apr 9, 2013, at 1:50 PM, John Wiggins wrote:

> On Apr 9, 2013, at 9:48 AM, Jordan Ilott wrote:
>
>> I've noticed a strange problem with PDF and SVG output. Using the demo(noninteractive.py) in the examples directory will generate an SVG or PDF; however, the axis labels are not rendered. Their doesn't seem to be a problem with PNG. Strangely, if the plot is added to an OverlayPlotContainer, the axis renders normally.
>
> There is a bug in the PdfGraphicsContext which is ignoring the padding on the component. If I account for the padding when self.clip_to_rect() is called, the axis labels show up. If I can come up with a robust solution, I'll create a pull request.
>
>> A probably unrelated but parallel observation has to do with multi-page PDF output. It appears to be quite possible, simply use the same PdfGraphicsContext to render multiple plots and call PdfGraphicsContext.gc.showPage() in between renders. This calls the showPage() method of the ReportLab canvas which will put any new drawing commands on a new page. The problem: when doing this, the plots on the second and subsequent pages are shifted toward the page origin(bottom left corner) for some reason. If there is an Enable/Kiva wizard who can explain this, I would appreciate it. Replacing the draw_pdf method in the noninteractive.py with the following code demonstrates the multi-page technique and when run, the formatting problem.
>
> Not sure about this one. In my limited experience with the PDF backend, output has always been placed in the bottom left corner of the page. One page or many, it doesn't change.
>
>> def draw_pdf(filename, size=(800,600)):
>>    from chaco.pdf_graphics_context import PdfPlotGraphicsContext
>>    container = create_plot()
>>    container.bounds = list(size)
>>    container.do_layout(force=True)
>>    gc = PdfPlotGraphicsContext(filename=filename, dest_box = (0.5, 0.5, 5.0, 5.0))
>>    gc.render_component(container)
>>
>>    #Start a new page for subsequent draw commands.
>>    gc.gc.showPage()
>>
>>    gc.render_component(container)
>>    gc.save()
>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>
> -- John

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: PDF/SVG output problems

John Wiggins
Jordan,

Thanks for testing this. I've implemented your suggestion. Now _initialize_page() is not immediately called in add_page(), It waits until the next call to render_component(). I changed the noninteractive.py example so that it included a loop with add_page() at the end. It works just fine and nothing weird needs to be done in the PdfPlotGraphicsContext to accomplish that.

Take a look at the PR <https://github.com/enthought/chaco/pull/109> and let me know if it needs anything else.

-- John

On Apr 9, 2013, at 9:52 PM, Jordan Ilott wrote:

> Thanks for looking at this John. It looks good, I've tried outputting PDF files from both DataView and VPlotContainer containers and in both cases, the axis and offset is working as expected.
>
> I do have a thought about the add_page() method though. It's convenient to duplicate the behavior of ReportLab's showPage() because after showPage() is called, a new page is only generated if a drawing command is sent. So, if for example you're looping through plots to be stuffed into a PDF, showPage() can be placed at the end of the loop and on the last iteration, no blank page is inserted. If I use the add_page() method that you've added, the call to _initialize_page() is causing ReportLab to insert a blank page. Not calling _initialize_page() causes the offset that I described before. I'm not sure what the best solution would be. Obviously, I could add a little more logic to the loop to solve this. Your chosen name for the method should make the behavior clear but maybe _initialize_page() should be called from render? Or maybe that would break something else.
>
> Jordan
>
>
> On Tue, Apr 9, 2013 at 3:08 PM, John Wiggins <[hidden email]> wrote:
> Jordan,
>
> I think I came up with an appropriate solution[1]. It works with your multipage example and doesn't have any of the bad behavior that you identified. Can you try it with your more complicated code and see if it still holds up?
>
> [1] https://github.com/enthought/chaco/pull/109
>
> -- John
>
>
> On Apr 9, 2013, at 1:50 PM, John Wiggins wrote:
>
> > On Apr 9, 2013, at 9:48 AM, Jordan Ilott wrote:
> >
> >> I've noticed a strange problem with PDF and SVG output. Using the demo(noninteractive.py) in the examples directory will generate an SVG or PDF; however, the axis labels are not rendered. Their doesn't seem to be a problem with PNG. Strangely, if the plot is added to an OverlayPlotContainer, the axis renders normally.
> >
> > There is a bug in the PdfGraphicsContext which is ignoring the padding on the component. If I account for the padding when self.clip_to_rect() is called, the axis labels show up. If I can come up with a robust solution, I'll create a pull request.
> >
> >> A probably unrelated but parallel observation has to do with multi-page PDF output. It appears to be quite possible, simply use the same PdfGraphicsContext to render multiple plots and call PdfGraphicsContext.gc.showPage() in between renders. This calls the showPage() method of the ReportLab canvas which will put any new drawing commands on a new page. The problem: when doing this, the plots on the second and subsequent pages are shifted toward the page origin(bottom left corner) for some reason. If there is an Enable/Kiva wizard who can explain this, I would appreciate it. Replacing the draw_pdf method in the noninteractive.py with the following code demonstrates the multi-page technique and when run, the formatting problem.
> >
> > Not sure about this one. In my limited experience with the PDF backend, output has always been placed in the bottom left corner of the page. One page or many, it doesn't change.
> >
> >> def draw_pdf(filename, size=(800,600)):
> >>    from chaco.pdf_graphics_context import PdfPlotGraphicsContext
> >>    container = create_plot()
> >>    container.bounds = list(size)
> >>    container.do_layout(force=True)
> >>    gc = PdfPlotGraphicsContext(filename=filename, dest_box = (0.5, 0.5, 5.0, 5.0))
> >>    gc.render_component(container)
> >>
> >>    #Start a new page for subsequent draw commands.
> >>    gc.gc.showPage()
> >>
> >>    gc.render_component(container)
> >>    gc.save()
> >>
> >> _______________________________________________
> >> Enthought-Dev mailing list
> >> [hidden email]
> >> https://mail.enthought.com/mailman/listinfo/enthought-dev
> >
> >
> > -- John
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: PDF/SVG output problems

Jordan Ilott-2

Thanks for making this changes John. I've been wondering how often pull requests are reviewed for merging and what is the preferred method for the general public to contribute changes. I've noticed some pull requests that have had no discussion at all and have remained unmerged for a long time.

I've found myself making very minor changes/fixes in my own fork, but I would like to see them pulled the into the upstream so that I have fewer difficulties managing the code. Should I be tying every pull request to a feature request or issue? The changes I've made typically only involve a couple  of lines.

Jordan

On Apr 16, 2013 1:51 PM, "John Wiggins" <[hidden email]> wrote:
Jordan,

Thanks for testing this. I've implemented your suggestion. Now _initialize_page() is not immediately called in add_page(), It waits until the next call to render_component(). I changed the noninteractive.py example so that it included a loop with add_page() at the end. It works just fine and nothing weird needs to be done in the PdfPlotGraphicsContext to accomplish that.

Take a look at the PR <https://github.com/enthought/chaco/pull/109> and let me know if it needs anything else.

-- John

On Apr 9, 2013, at 9:52 PM, Jordan Ilott wrote:

> Thanks for looking at this John. It looks good, I've tried outputting PDF files from both DataView and VPlotContainer containers and in both cases, the axis and offset is working as expected.
>
> I do have a thought about the add_page() method though. It's convenient to duplicate the behavior of ReportLab's showPage() because after showPage() is called, a new page is only generated if a drawing command is sent. So, if for example you're looping through plots to be stuffed into a PDF, showPage() can be placed at the end of the loop and on the last iteration, no blank page is inserted. If I use the add_page() method that you've added, the call to _initialize_page() is causing ReportLab to insert a blank page. Not calling _initialize_page() causes the offset that I described before. I'm not sure what the best solution would be. Obviously, I could add a little more logic to the loop to solve this. Your chosen name for the method should make the behavior clear but maybe _initialize_page() should be called from render? Or maybe that would break something else.
>
> Jordan
>
>
> On Tue, Apr 9, 2013 at 3:08 PM, John Wiggins <[hidden email]> wrote:
> Jordan,
>
> I think I came up with an appropriate solution[1]. It works with your multipage example and doesn't have any of the bad behavior that you identified. Can you try it with your more complicated code and see if it still holds up?
>
> [1] https://github.com/enthought/chaco/pull/109
>
> -- John
>
>
> On Apr 9, 2013, at 1:50 PM, John Wiggins wrote:
>
> > On Apr 9, 2013, at 9:48 AM, Jordan Ilott wrote:
> >
> >> I've noticed a strange problem with PDF and SVG output. Using the demo(noninteractive.py) in the examples directory will generate an SVG or PDF; however, the axis labels are not rendered. Their doesn't seem to be a problem with PNG. Strangely, if the plot is added to an OverlayPlotContainer, the axis renders normally.
> >
> > There is a bug in the PdfGraphicsContext which is ignoring the padding on the component. If I account for the padding when self.clip_to_rect() is called, the axis labels show up. If I can come up with a robust solution, I'll create a pull request.
> >
> >> A probably unrelated but parallel observation has to do with multi-page PDF output. It appears to be quite possible, simply use the same PdfGraphicsContext to render multiple plots and call PdfGraphicsContext.gc.showPage() in between renders. This calls the showPage() method of the ReportLab canvas which will put any new drawing commands on a new page. The problem: when doing this, the plots on the second and subsequent pages are shifted toward the page origin(bottom left corner) for some reason. If there is an Enable/Kiva wizard who can explain this, I would appreciate it. Replacing the draw_pdf method in the noninteractive.py with the following code demonstrates the multi-page technique and when run, the formatting problem.
> >
> > Not sure about this one. In my limited experience with the PDF backend, output has always been placed in the bottom left corner of the page. One page or many, it doesn't change.
> >
> >> def draw_pdf(filename, size=(800,600)):
> >>    from chaco.pdf_graphics_context import PdfPlotGraphicsContext
> >>    container = create_plot()
> >>    container.bounds = list(size)
> >>    container.do_layout(force=True)
> >>    gc = PdfPlotGraphicsContext(filename=filename, dest_box = (0.5, 0.5, 5.0, 5.0))
> >>    gc.render_component(container)
> >>
> >>    #Start a new page for subsequent draw commands.
> >>    gc.gc.showPage()
> >>
> >>    gc.render_component(container)
> >>    gc.save()
> >>
> >> _______________________________________________
> >> Enthought-Dev mailing list
> >> [hidden email]
> >> https://mail.enthought.com/mailman/listinfo/enthought-dev
> >
> >
> > -- John
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: PDF/SVG output problems

John Wiggins
Jordan,
Enthought developers try to be fairly vigilant about pull requests in ETS repositories. Often other day-to-day work is more pressing, so they languish. Please don't let that discourage you. We always appreciate contributions from the community. If you have some changes you'd like to propose, then by all means, submit a PR.

-- John

On Apr 16, 2013, at 7:14 PM, Jordan Ilott wrote:

> Thanks for making this changes John. I've been wondering how often pull requests are reviewed for merging and what is the preferred method for the general public to contribute changes. I've noticed some pull requests that have had no discussion at all and have remained unmerged for a long time.
>
> I've found myself making very minor changes/fixes in my own fork, but I would like to see them pulled the into the upstream so that I have fewer difficulties managing the code. Should I be tying every pull request to a feature request or issue? The changes I've made typically only involve a couple  of lines.
>
> Jordan
>
> On Apr 16, 2013 1:51 PM, "John Wiggins" <[hidden email]> wrote:
> Jordan,
>
> Thanks for testing this. I've implemented your suggestion. Now _initialize_page() is not immediately called in add_page(), It waits until the next call to render_component(). I changed the noninteractive.py example so that it included a loop with add_page() at the end. It works just fine and nothing weird needs to be done in the PdfPlotGraphicsContext to accomplish that.
>
> Take a look at the PR <https://github.com/enthought/chaco/pull/109> and let me know if it needs anything else.
>
> -- John
>
> On Apr 9, 2013, at 9:52 PM, Jordan Ilott wrote:
>
> > Thanks for looking at this John. It looks good, I've tried outputting PDF files from both DataView and VPlotContainer containers and in both cases, the axis and offset is working as expected.
> >
> > I do have a thought about the add_page() method though. It's convenient to duplicate the behavior of ReportLab's showPage() because after showPage() is called, a new page is only generated if a drawing command is sent. So, if for example you're looping through plots to be stuffed into a PDF, showPage() can be placed at the end of the loop and on the last iteration, no blank page is inserted. If I use the add_page() method that you've added, the call to _initialize_page() is causing ReportLab to insert a blank page. Not calling _initialize_page() causes the offset that I described before. I'm not sure what the best solution would be. Obviously, I could add a little more logic to the loop to solve this. Your chosen name for the method should make the behavior clear but maybe _initialize_page() should be called from render? Or maybe that would break something else.
> >
> > Jordan
> >
> >
> > On Tue, Apr 9, 2013 at 3:08 PM, John Wiggins <[hidden email]> wrote:
> > Jordan,
> >
> > I think I came up with an appropriate solution[1]. It works with your multipage example and doesn't have any of the bad behavior that you identified. Can you try it with your more complicated code and see if it still holds up?
> >
> > [1] https://github.com/enthought/chaco/pull/109
> >
> > -- John
> >
> >
> > On Apr 9, 2013, at 1:50 PM, John Wiggins wrote:
> >
> > > On Apr 9, 2013, at 9:48 AM, Jordan Ilott wrote:
> > >
> > >> I've noticed a strange problem with PDF and SVG output. Using the demo(noninteractive.py) in the examples directory will generate an SVG or PDF; however, the axis labels are not rendered. Their doesn't seem to be a problem with PNG. Strangely, if the plot is added to an OverlayPlotContainer, the axis renders normally.
> > >
> > > There is a bug in the PdfGraphicsContext which is ignoring the padding on the component. If I account for the padding when self.clip_to_rect() is called, the axis labels show up. If I can come up with a robust solution, I'll create a pull request.
> > >
> > >> A probably unrelated but parallel observation has to do with multi-page PDF output. It appears to be quite possible, simply use the same PdfGraphicsContext to render multiple plots and call PdfGraphicsContext.gc.showPage() in between renders. This calls the showPage() method of the ReportLab canvas which will put any new drawing commands on a new page. The problem: when doing this, the plots on the second and subsequent pages are shifted toward the page origin(bottom left corner) for some reason. If there is an Enable/Kiva wizard who can explain this, I would appreciate it. Replacing the draw_pdf method in the noninteractive.py with the following code demonstrates the multi-page technique and when run, the formatting problem.
> > >
> > > Not sure about this one. In my limited experience with the PDF backend, output has always been placed in the bottom left corner of the page. One page or many, it doesn't change.
> > >
> > >> def draw_pdf(filename, size=(800,600)):
> > >>    from chaco.pdf_graphics_context import PdfPlotGraphicsContext
> > >>    container = create_plot()
> > >>    container.bounds = list(size)
> > >>    container.do_layout(force=True)
> > >>    gc = PdfPlotGraphicsContext(filename=filename, dest_box = (0.5, 0.5, 5.0, 5.0))
> > >>    gc.render_component(container)
> > >>
> > >>    #Start a new page for subsequent draw commands.
> > >>    gc.gc.showPage()
> > >>
> > >>    gc.render_component(container)
> > >>    gc.save()
> > >>
> > >> _______________________________________________
> > >> Enthought-Dev mailing list
> > >> [hidden email]
> > >> https://mail.enthought.com/mailman/listinfo/enthought-dev
> > >
> > >
> > > -- John
> >
> > _______________________________________________
> > Enthought-Dev mailing list
> > [hidden email]
> > https://mail.enthought.com/mailman/listinfo/enthought-dev
> >
> > _______________________________________________
> > Enthought-Dev mailing list
> > [hidden email]
> > https://mail.enthought.com/mailman/listinfo/enthought-dev
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev