matplotlib-devel Mailing List for matplotlib

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> Sounds fine. Why not roll dpi, facecolor, edgecolor and
    Darren> orientation in with the kwargs?

You can, but it is more work this way and no obvious benefit.  In
every backend you would then have to provide this boilerplate

  dpi = kwargs.get('dpi', rcParams[savefig.dpi'])
  facecolor = kwargs.get('facecolor', 'white')
  ...and so on....

and so on.  Since what we have currently works, and you can do what
you want w/o dumping everything into generic kwarg handling, I figured
this falls into the category of "if it ain't broke, don't fix it".
But I don't feel strongly either way.

In the ideal, perhaps, we would provide explicit kwargs that every
backend is expected to abide by (facecolor, edgecolor) and put the
optional ones that only make sense in certain backends (no dpi for ps,
no papersize for agg) into the generic **kwargs framework.

JDH

On Thursday 09 March 2006 15:25, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> On Tuesday 07 March 2006 19:10, John Hunter wrote:
>     >> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> When the image wont fit on the default letter page,
>     Darren> backend_ps tries to find a page it will fit on. It turns
>     Darren> out that the C0-C6 page sizes were causing problems, I
>     Darren> guess they are not postscript approved. This is fixed in
>     Darren> svn.
>
>     >>  Hey Darren,
>     >>
>     >> Thanks for the quick fix.  It now fits on the page, but does
>     >> not appear to be centered -- see attachment below.  If I recall
>     >> correctly, the figures used to be centered....
>     >>
>     >> In general, I'm not sure that automatically selecting papersize
>     >> is a good idea, as it fits into the "failing silently"
>     >> category.  I also think it falls into the "trying to be too
>     >> smart" category.  My vote is to give them what they asked for,
>     >> and the means to fix problems when they arise.
>
>     Darren> I'm going to drop autosizing in favor of passing a
>     Darren> papertype kwarg to savefig.  Any objections?
>
> None from me...
>
>     Darren> Also, I thought I could just add a papertype kwarg to
>     Darren> backend_ps.FigureCanvasPS.print_figure, but that doesnt
>     Darren> work. Would papertype need to be added to all the
>     Darren> backend's print_figure method, or could we just add
>     Darren> **kwargs (or is there something else I have overlooked)?
>
> The problem here is that Agg and other backends will detect the ps
> extensions and create a PS renderer to print the figure.  See for
> example
>
>   FigureCanvasAgg.print_figure
>
> This has bitten me before, and in the past I was lazy and just
> manually added the kwarg to each signature.  This time around, I
> suggest you modify the signature to be
>
>     def print_figure(self, filename, dpi=150,
>                      facecolor='w', edgecolor='w',
>                      orientation='portrait', **kwargs):
>
> Just add a catchall kwargs to each print_figure.  Then in backend_agg,
> for example
>
>             elif ext.find('ps')>=0 or ext.find('ep')>=0:
>                 from backend_ps import FigureCanvasPS # lazy import
>                 ps = self.switch_backends(FigureCanvasPS)
>                 ps.print_figure(filename, dpi, facecolor, edgecolor,
> orientation, **kwargs)
>
> and everywhere else that print_figure is called the kwargs should be
> passed through.
>
> backend_ps can then do
>
>     def print_figure(self, outfile, dpi=72,
>                      facecolor='w', edgecolor='w',
>                      orientation='portrait', **kwargs):
>         papersize = kwargs.get('papersize', rcParams['ps.papersize'])
>
> In this way we can support backend dependent kwargs to print w/o
> having to put them in every backend (and thereby raise false
> expectations).  Eg, agg can just ignore the papersize kwarg and just
> pass it through.
>
> We should, however, document in the Figure.savefig command which
> kwargs are available for which backends, eg
>
>     def savefig(self, *args, **kwargs):
>         """
>         SAVEFIG(fname, dpi=150, facecolor='w', edgecolor='w',
>         orientation='portrait', **kwargs):
>
>         ...snip...
>         optional kwargs
>         papersize = 'letter'|'a4'... PS backend only
>
>
> So it is a fair amount of trivial/tedious work to do this right across
> backends for this one minor change, but it will be worth it because it
> will make it easy to extend next time around.

Sounds fine. Why not roll dpi, facecolor, edgecolor and orientation in with 
the kwargs?

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> On Tuesday 07 March 2006 19:10, John Hunter wrote:
    >> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
    >> 
    Darren> When the image wont fit on the default letter page,
    Darren> backend_ps tries to find a page it will fit on. It turns
    Darren> out that the C0-C6 page sizes were causing problems, I
    Darren> guess they are not postscript approved. This is fixed in
    Darren> svn.
    >>  Hey Darren,
    >> 
    >> Thanks for the quick fix.  It now fits on the page, but does
    >> not appear to be centered -- see attachment below.  If I recall
    >> correctly, the figures used to be centered....
    >> 
    >> In general, I'm not sure that automatically selecting papersize
    >> is a good idea, as it fits into the "failing silently"
    >> category.  I also think it falls into the "trying to be too
    >> smart" category.  My vote is to give them what they asked for,
    >> and the means to fix problems when they arise.

    Darren> I'm going to drop autosizing in favor of passing a
    Darren> papertype kwarg to savefig.  Any objections?

None from me...

    Darren> Also, I thought I could just add a papertype kwarg to
    Darren> backend_ps.FigureCanvasPS.print_figure, but that doesnt
    Darren> work. Would papertype need to be added to all the
    Darren> backend's print_figure method, or could we just add
    Darren> **kwargs (or is there something else I have overlooked)?

The problem here is that Agg and other backends will detect the ps
extensions and create a PS renderer to print the figure.  See for
example

  FigureCanvasAgg.print_figure

This has bitten me before, and in the past I was lazy and just
manually added the kwarg to each signature.  This time around, I
suggest you modify the signature to be

    def print_figure(self, filename, dpi=150,
                     facecolor='w', edgecolor='w',
                     orientation='portrait', **kwargs):

Just add a catchall kwargs to each print_figure.  Then in backend_agg,
for example

            elif ext.find('ps')>=0 or ext.find('ep')>=0:
                from backend_ps import FigureCanvasPS # lazy import
                ps = self.switch_backends(FigureCanvasPS)
                ps.print_figure(filename, dpi, facecolor, edgecolor, orientation, **kwargs)

and everywhere else that print_figure is called the kwargs should be
passed through.

backend_ps can then do

    def print_figure(self, outfile, dpi=72,
                     facecolor='w', edgecolor='w',
                     orientation='portrait', **kwargs):
        papersize = kwargs.get('papersize', rcParams['ps.papersize'])

In this way we can support backend dependent kwargs to print w/o
having to put them in every backend (and thereby raise false
expectations).  Eg, agg can just ignore the papersize kwarg and just
pass it through.

We should, however, document in the Figure.savefig command which
kwargs are available for which backends, eg

    def savefig(self, *args, **kwargs):
        """
        SAVEFIG(fname, dpi=150, facecolor='w', edgecolor='w',
        orientation='portrait', **kwargs):

        ...snip...
        optional kwargs
        papersize = 'letter'|'a4'... PS backend only


So it is a fair amount of trivial/tedious work to do this right across
backends for this one minor change, but it will be worth it because it
will make it easy to extend next time around.

JDH


    Darren> Thanks, Darren


    Darren> -------------------------------------------------------
    Darren> This SF.Net email is sponsored by xPML, a groundbreaking
    Darren> scripting language that extends applications into web and
    Darren> mobile media. Attend the live webcast and join the prime
    Darren> developer group breaking into this new coding territory!
    Darren> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
    Darren> _______________________________________________
    Darren> Matplotlib-devel mailing list
    Darren> Mat...@li...
    Darren> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Tuesday 07 March 2006 19:10, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> When the image wont fit on the default letter page,
>     Darren> backend_ps tries to find a page it will fit on. It turns
>     Darren> out that the C0-C6 page sizes were causing problems, I
>     Darren> guess they are not postscript approved. This is fixed in
>     Darren> svn.
>
> Hey Darren,
>
> Thanks for the quick fix.  It now fits on the page, but does not
> appear to be centered -- see attachment below.  If I recall correctly,
> the figures used to be centered....
>
> In general, I'm not sure that automatically selecting papersize is a
> good idea, as it fits into the "failing silently" category.  I also
> think it falls into the "trying to be too smart" category.  My vote is
> to give them what they asked for, and the means to fix problems when
> they arise.

I'm going to drop autosizing in favor of passing a papertype kwarg to savefig.
Any objections? 

Also, I thought I could just add a papertype kwarg to 
backend_ps.FigureCanvasPS.print_figure, but that doesnt work. Would papertype 
need to be added to all the backend's print_figure method, or could we just 
add **kwargs (or is there something else I have overlooked)?

Thanks,
Darren 

Hi all,

Firstly, I love your software. It's great and largely it Just Works.
However, I came across some weirdness pretty quickly also, without
having to do anything particularly unusual.

I wrote some code to generate a pair of lists about 300 elements long,
and plotted them. I found that the line plot didn't have all the data
points connected.

When I saved to SVG, the output was correct.

Also, when I tried to perform a scatter plot, I got runtime errors and
no plot was drawn. These problems occur 100% of the time on my machine
with my test files.

I'm not sure if this list accepts files or not, but I am happy to
provide the code and sample files which demonstrate this error, and/or
respond to the bugfixing process.

Cheers,
-Tennessee