matplotlib-devel Mailing List for matplotlib (Page 487)

When using the Qt backend, resize events were not
getting passed along properly so the window was created
based off of some other criteria. The attatched patch
file will fix the problem and make the window be
resized appropriatly on construction.

I am uploading a newer patch that is against the SVN
repository as of "MAR 10, 2006 13:55".  This also
contains a few minor cosmetic fixes/tweaks.

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

> On Friday 10 March 2006 3:14 am, Gary Ruben wrote:
> > Are you saying you will have replace it with auto as a papertype option
> > as you suggested previously? Autosizing is a good idea if it can be made
> > to work properly since it should negate the requirement to then compute
> > a bounding box if you're including the resulting file in LaTeX. This is
> > easy enough to do with eps using separate tools, but not for pdf's.
> > Hopefully, a pdf backend will appear at some point and when it does mpl
> > should support pdfs able to be included directly in pdflatex.
> 
> I am considering whether to have an "auto" key, which was suggested by Ted. 
> For sure, auto sizing will be done behind the scenes for eps files with the 
> usetex option (necessary to avoid clipping during postprocessing). 
> 
> It will take a lot of work to support the usetex option with a pdf
> backend. We use the PSFrags latex package to insert the text in our
> figures, so an intermediate postscript file will be necessary for
> the foreseeable future.

Replacing PSFrags is relatively easy - I posted code in January 
to do so see: 

http://sourceforge.net/mailarchive/message.php?msg_id=14356597
http://sourceforge.net/mailarchive/message.php?msg_id=14367311

Essentially, instead of inserting a marker in the postscript at the
position you want your text, and then using psfrag to replace it, you
put the text in the right position using a latex picture environment.

I didn't persue it as I came to the, possibly incorrect, conclusion
that _all_ "dvips -E"[1] output contains postscript commands that are not
valid in eps[2].


If it were easy to write pdf rather than eps (and I'd been assuming it
would be complicated), then the approach I outlined would avoid the
necessity to use eps. 

Chris

[1] Dvips -E is used to produce eps files 

[2] The output contains statusdict and userdict, which I believe to be
not permitted in eps files.  Perhaps this is not normally a problem -
otherwise what is the point of dvips -E?

On Friday 10 March 2006 07:54, Paul Barrett wrote:
> On 3/10/06, Gary Ruben <gr...@bi...> wrote:
> > Hi Darren,
> > Given your statements about eps and pdfs, I don't see a problem with
> > removing autosizing. Will it make life harder for users generating png's
> > for websites? If not, I don't see any problem.
> > Gary R.
> >
> > Darren Dale wrote:
> > > On Friday 10 March 2006 3:14 am, Gary Ruben wrote:
> > >> Are you saying you will have replace it with auto as a papertype
> > >> option as you suggested previously? Autosizing is a good idea if it
> > >> can be
> >
> > made
> >
> > >> to work properly since it should negate the requirement to then
> > >> compute a bounding box if you're including the resulting file in
> > >> LaTeX. This is easy enough to do with eps using separate tools, but
> > >> not for pdf's. Hopefully, a pdf backend will appear at some point and
> > >> when it does mpl should support pdfs able to be included directly in
> > >> pdflatex.
> > >
> > > I am considering whether to have an "auto" key, which was suggested by
> >
> > Ted.
> >
> > > For sure, auto sizing will be done behind the scenes for eps files with
> >
> > the
> >
> > > usetex option (necessary to avoid clipping during postprocessing).
> > >
> > > It will take a lot of work to support the usetex option with a pdf
> >
> > backend. We
> >
> > > use the PSFrags latex package to insert the text in our figures, so an
> > > intermediate postscript file will be necessary for the foreseeable
> >
> > future.
>
> Is a landscape option also available?  It would also be nice to specify
> that the plot be printed in landscape mode at the same time as specifying
> the paper size.

landscape orientation is currently available without usetex, but is broken 
with usetex. I spent most of last night trying to get that fixed, and made 
some progress. Maybe I'll have it fixed by this time tomorrow.

On Friday 10 March 2006 07:40, Gary Ruben wrote:
> Hi Darren,
> Given your statements about eps and pdfs, I don't see a problem with
> removing autosizing. Will it make life harder for users generating png's
> for websites? If not, I don't see any problem.
> Gary R.

Papersize and orientation are only used for postscript output, so autosizing 
does not effect png output.

> Darren Dale wrote:
> > On Friday 10 March 2006 3:14 am, Gary Ruben wrote:
> >> Are you saying you will have replace it with auto as a papertype option
> >> as you suggested previously? Autosizing is a good idea if it can be made
> >> to work properly since it should negate the requirement to then compute
> >> a bounding box if you're including the resulting file in LaTeX. This is
> >> easy enough to do with eps using separate tools, but not for pdf's.
> >> Hopefully, a pdf backend will appear at some point and when it does mpl
> >> should support pdfs able to be included directly in pdflatex.
> >
> > I am considering whether to have an "auto" key, which was suggested by
> > Ted. For sure, auto sizing will be done behind the scenes for eps files
> > with the usetex option (necessary to avoid clipping during
> > postprocessing).
> >
> > It will take a lot of work to support the usetex option with a pdf
> > backend. We use the PSFrags latex package to insert the text in our
> > figures, so an intermediate postscript file will be necessary for the
> > foreseeable future.
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

On 3/10/06, Gary Ruben <gr...@bi...> wrote:
>
> Hi Darren,
> Given your statements about eps and pdfs, I don't see a problem with
> removing autosizing. Will it make life harder for users generating png's
> for websites? If not, I don't see any problem.
> Gary R.
>
> Darren Dale wrote:
> > On Friday 10 March 2006 3:14 am, Gary Ruben wrote:
> >> Are you saying you will have replace it with auto as a papertype optio=
n
> >> as you suggested previously? Autosizing is a good idea if it can be
> made
> >> to work properly since it should negate the requirement to then comput=
e
> >> a bounding box if you're including the resulting file in LaTeX. This i=
s
> >> easy enough to do with eps using separate tools, but not for pdf's.
> >> Hopefully, a pdf backend will appear at some point and when it does mp=
l
> >> should support pdfs able to be included directly in pdflatex.
> >
> > I am considering whether to have an "auto" key, which was suggested by
> Ted.
> > For sure, auto sizing will be done behind the scenes for eps files with
> the
> > usetex option (necessary to avoid clipping during postprocessing).
> >
> > It will take a lot of work to support the usetex option with a pdf
> backend. We
> > use the PSFrags latex package to insert the text in our figures, so an
> > intermediate postscript file will be necessary for the foreseeable
> future.
>

Is a landscape option also available?  It would also be nice to specify tha=
t
the plot be printed in landscape mode at the same time as specifying the
paper size.

 -- Paul

Hi Darren,
Given your statements about eps and pdfs, I don't see a problem with 
removing autosizing. Will it make life harder for users generating png's 
for websites? If not, I don't see any problem.
Gary R.

Darren Dale wrote:
> On Friday 10 March 2006 3:14 am, Gary Ruben wrote:
>> Are you saying you will have replace it with auto as a papertype option
>> as you suggested previously? Autosizing is a good idea if it can be made
>> to work properly since it should negate the requirement to then compute
>> a bounding box if you're including the resulting file in LaTeX. This is
>> easy enough to do with eps using separate tools, but not for pdf's.
>> Hopefully, a pdf backend will appear at some point and when it does mpl
>> should support pdfs able to be included directly in pdflatex.
> 
> I am considering whether to have an "auto" key, which was suggested by Ted. 
> For sure, auto sizing will be done behind the scenes for eps files with the 
> usetex option (necessary to avoid clipping during postprocessing). 
> 
> It will take a lot of work to support the usetex option with a pdf backend. We 
> use the PSFrags latex package to insert the text in our figures, so an 
> intermediate postscript file will be necessary for the foreseeable future.

On Friday 10 March 2006 3:14 am, Gary Ruben wrote:
> Are you saying you will have replace it with auto as a papertype option
> as you suggested previously? Autosizing is a good idea if it can be made
> to work properly since it should negate the requirement to then compute
> a bounding box if you're including the resulting file in LaTeX. This is
> easy enough to do with eps using separate tools, but not for pdf's.
> Hopefully, a pdf backend will appear at some point and when it does mpl
> should support pdfs able to be included directly in pdflatex.

I am considering whether to have an "auto" key, which was suggested by Ted. 
For sure, auto sizing will be done behind the scenes for eps files with the 
usetex option (necessary to avoid clipping during postprocessing). 

It will take a lot of work to support the usetex option with a pdf backend. We 
use the PSFrags latex package to insert the text in our figures, so an 
intermediate postscript file will be necessary for the foreseeable future.

Are you saying you will have replace it with auto as a papertype option 
as you suggested previously? Autosizing is a good idea if it can be made 
to work properly since it should negate the requirement to then compute 
a bounding box if you're including the resulting file in LaTeX. This is 
easy enough to do with eps using separate tools, but not for pdf's. 
Hopefully, a pdf backend will appear at some point and when it does mpl 
should support pdfs able to be included directly in pdflatex.

Gary R.

> 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 

>>>>> "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

I can accept that auto sizing is a bad idea. What I would really like is to 
find an option that centered the image in the middle of any page, no matter 
what size. Then we wouldnt even have to specify the page size. But I'm not 
sure such a beast exists in the postscript language.

On Tuesday 07 March 2006 7:47 pm, Ted Drain wrote:
> In general I think that auto paper size is a bad idea.  My thought process
> goes something like this:
>
> - I select letter size because I'm making some type of presentation/paper.
> - Make a plot
> - Plot is b4 size.
> - What the heck?
>
> However, I can also see the usefulness of auto-sizing when someone doesn't
> care about the exact paper size that results.
>
> How about a paper size "auto" that let's the system pick the size to fit
> the plot?  Or maybe an addition rc boolean to indicate if the plot can
> autogrow the size so you can select your preferred size which is used until
> it's too small.
>
> TD
>
> At 04:41 PM 3/7/2006, John Hunter wrote:
> > >>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:
> >
> >     Malte> John, it looks centered with KGhostView (debian sarge)
> >
> >Thanks for the input.  I should have mentioned, I made the figure on
> >my linux server and then scp'd it over to my powerbook on which I'm
> >working.  When I view it in preview, it is first converted over to pdf
> >and this may be where the bug is, not on the mpl side.
> >
> >When I open it in ggv over X11 it now looks centered, but it appears
> >to be b4 paper 10.11 x 14.33, even though I have selected letter in my
> >rc file and as my default in ggv.  I guess this is the spill-over
> >effect Darren described earlier, in which a larger papersize is
> >selected if you he figure doesn't fit on the default papersize.
> >
> >Yep, I just confirmed by looking in the ps file, it is selecting b4.
> >Anyone else have an opinion on the desirability of auto-papersize
> >selection?
> >
> >JDH
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language that extends applications into web and mobile media. Attend the
> > live webcast and join the prime developer group breaking into this new
> > coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> >Matplotlib-devel mailing list
> >Mat...@li...
> >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
dd...@co...

In general I think that auto paper size is a bad idea.  My thought process 
goes something like this:

- I select letter size because I'm making some type of presentation/paper.
- Make a plot
- Plot is b4 size.
- What the heck?

However, I can also see the usefulness of auto-sizing when someone doesn't 
care about the exact paper size that results.

How about a paper size "auto" that let's the system pick the size to fit 
the plot?  Or maybe an addition rc boolean to indicate if the plot can 
autogrow the size so you can select your preferred size which is used until 
it's too small.

TD

At 04:41 PM 3/7/2006, John Hunter wrote:
> >>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:
>
>     Malte> John, it looks centered with KGhostView (debian sarge)
>
>Thanks for the input.  I should have mentioned, I made the figure on
>my linux server and then scp'd it over to my powerbook on which I'm
>working.  When I view it in preview, it is first converted over to pdf
>and this may be where the bug is, not on the mpl side.
>
>When I open it in ggv over X11 it now looks centered, but it appears
>to be b4 paper 10.11 x 14.33, even though I have selected letter in my
>rc file and as my default in ggv.  I guess this is the spill-over
>effect Darren described earlier, in which a larger papersize is
>selected if you he figure doesn't fit on the default papersize.
>
>Yep, I just confirmed by looking in the ps file, it is selecting b4.
>Anyone else have an opinion on the desirability of auto-papersize
>selection?
>
>JDH
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:

    Malte> John, it looks centered with KGhostView (debian sarge)

Thanks for the input.  I should have mentioned, I made the figure on
my linux server and then scp'd it over to my powerbook on which I'm
working.  When I view it in preview, it is first converted over to pdf
and this may be where the bug is, not on the mpl side.

When I open it in ggv over X11 it now looks centered, but it appears
to be b4 paper 10.11 x 14.33, even though I have selected letter in my
rc file and as my default in ggv.  I guess this is the spill-over
effect Darren described earlier, in which a larger papersize is
selected if you he figure doesn't fit on the default papersize.

Yep, I just confirmed by looking in the ps file, it is selecting b4.
Anyone else have an opinion on the desirability of auto-papersize
selection?

JDH

John,


it looks centered with KGhostView (debian sarge)

On Tuesday 07 March 2006 15:21, John Hunter wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
>     Charlie> Bugfix release including imshow problem from 0.87.  This
>     Charlie> is the first release from the new subversion repository.
>     Charlie> The cvs tree is dead at this point.
>
> Oops, it looks like the PS backend is broken.  I just got back from
> lunch and ran backend driver and there is a figure centering /
> clipping problem in backend_ps.  Darren, might this have been
> introduced when you made the changes to the figure width / height
> handling in the update for portrait mode?
>
> Problem is exposed in svn revision 2129 (latest) with
>
>   > python simple_plot.py -dPS

When the image wont fit on the default letter page, backend_ps tries to find a 
page it will fit on. It turns out that the C0-C6 page sizes were causing 
problems, I guess they are not postscript approved. This is fixed in svn.

Darren

Oh brother. I'm looking into it.

On Tuesday 07 March 2006 15:21, John Hunter wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
>     Charlie> Bugfix release including imshow problem from 0.87.  This
>     Charlie> is the first release from the new subversion repository.
>     Charlie> The cvs tree is dead at this point.
>
> Oops, it looks like the PS backend is broken.  I just got back from
> lunch and ran backend driver and there is a figure centering /
> clipping problem in backend_ps.  Darren, might this have been
> introduced when you made the changes to the figure width / height
> handling in the update for portrait mode?
>
> Problem is exposed in svn revision 2129 (latest) with
>
>   > python simple_plot.py -dPS
>
> JDH
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> Bugfix release including imshow problem from 0.87.  This
    Charlie> is the first release from the new subversion repository.
    Charlie> The cvs tree is dead at this point.

Oops, it looks like the PS backend is broken.  I just got back from
lunch and ran backend driver and there is a figure centering /
clipping problem in backend_ps.  Darren, might this have been
introduced when you made the changes to the figure width / height
handling in the update for portrait mode?

Problem is exposed in svn revision 2129 (latest) with 

  > python simple_plot.py -dPS



JDH

Bugfix release including imshow problem from 0.87.
This is the first release from the new subversion repository.  The cvs
tree is dead at this point.

http://sourceforge.net/project/showfiles.php?group_id=3D80706

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2006-03-07 Released 0.87.1

2006-03-04 backend_cairo.py:
           fix get_rgb() bug reported by Keith Briggs.
           Require pycairo 1.0.2.
           Support saving png to file-like objects. - SC

2006-03-03 Fixed pcolor handling of vmin, vmax - EF

2006-03-02 improve page sizing with usetex with the latex
           geometry package. Closes bug # 1441629 - DSD

2006-03-02 Fixed dpi problem with usetex png output. Accepted a
           modified version of patch # 1441809 - DSD

2006-03-01 Fixed axis('scaled') to deal with case xmax < xmin - JSWHIT

2006-03-01 Added reversed colormaps (with '_r' appended to name) - JSWHIT

2006-02-27 Improved eps bounding boxes with usetex - DSD

2006-02-27 Test svn commit, again!

2006-02-27 Fixed two dependency checking bugs related to usetex
           on Windows - DSD

2006-02-27 Made the rc deprecation warnings a little more human
           readable.

2006-02-26 Update the previous gtk.main_quit() bug fix to use gtk.main_leve=
l()
           - SC

2006-02-24 Implemented alpha support in contour and contourf - EF

2006-02-22 Fixed gtk main quit bug when quit was called before
           mainloop. - JDH

2006-02-22 Small change to colors.py to workaround apparent
           bug in numpy masked array module - JW

2006-02-22 Fixed bug in ScalarMappable.to_rgba() reported by
           Ray Jones, and fixed incorrect fix found by Jeff
           Whitaker - EF

Steve Chaplin wrote:
> Using the latest cairo (git), pycairo (cvs) and matplotlib (svn) and
> running examples/simple_plot.py I get a 22K PDF file. But when I try to
> view it with evince and xpdf I get "unable to open document" type
> errors.

This is just a shot in the dark, but I've been playing with pycairo a 
bit, and found that you need to make sure to call:


cairo.Context.show_page()

When you're done with the rendering. I had similar symptoms before I did 
that.


John,

What are your plans regarding Cairo and the future of rendering for MPL? 
I'm in the need of alpha blended rendering for wxPython stuff, so I've 
been looking at Cairo and Agg. Agg is a great solution for really nice 
rendering, but Cairo has the promise of supporting everything else I 
need, like PDF for instance.

Now that Mozilla seems to be adopting Cairo, it might even live up to 
the promise of a fully cross-platform solution. If so, it would be great 
to develop a really general purpose, robust, numpy-aware, pythonic 
interface for it.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Sunday 26 February 2006 13:54, Ted Drain wrote:
> Hmm - I just ran your test and everything seems to work fine.  I'm using
> MPL 0.85 and Qt 3.3.5.  I did a diff of backend_qt.py and backend_qtagg.py
> from 0.85 to the current CVS repository and they're identical.  So I'm not
> sure what could be going on...

Maybe this is not an issue with qt-3.3.5. 

Another datapoint: when I run the embedding_in_qt.py example, the size of the 
window is correct.

> At 10:30 AM 2/26/2006, Darren Dale wrote:
> >On Sunday 26 February 2006 1:06 pm, Ted Drain wrote:
> > > Darren,
> > > I'll have someone take a look at it soon.  We're right in the middle of
> > > a big delivery so we don't really have a lot of time to spend on this
> > > right now...
> >
> >Thanks, Ted. I'm not in a rush.
> >
> >I'm about to start my first python-based gui project, and want to use Qt.
> >I'll
> >also continue to poke around at these problems myself as I find time.
> >
> >Darren
> >
> > > At 08:20 AM 2/26/2006, Darren Dale wrote:
> > > >Respectfully: Is the QtAgg backend supported?
> > > >
> > > >On Saturday 18 February 2006 6:01 pm, Darren Dale wrote:
> > > > > I'm having two problems with the QtAgg backend. If I do:
> > > > > >>> from pylab import *
> > > > > >>> plot([1,2])
> > > > >
> > > > > [<matplotlib.lines.Line2D instance at 0x2aaab1ead830>]
> > > > >
> > > > > >>> show()
> > > > >
> > > > > My figure window should be 8in x 6in, but instead it is 6in tall
> > > > > and as wide as my screen will allow. So thats the first issue. The
> > > > > second is this: if I close that window, and then do
> > > > >
> > > > > >>> plot([1,2])
> > > > >
> > > > > [<matplotlib.lines.Line2D instance at 0x2aaab1ebbcf8>]
> > > > >
> > > > > >>> show()
> > > > >
> > > > > I get the following traceback:
> > > > >
> > > > > Traceback (most recent call last):
> > > > >   File "<stdin>", line 1, in ?
> > > > >   File
> > > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.
> > > > >py", line 47, in show
> > > > >     manager.window.show()
> > > > > RuntimeError: underlying C/C++ object has been deleted
> > > > >
> > > > > I'm using qt version 3.3.4, with cvs mpl 0.86.2, on a gentoo linux
> > > > > system. The only nondefault rc setting is the choice of backend.
> > > > >
> > > > > Darren
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through
> > > > > log files for problems?  Stop!  Download the new AJAX search engine
> > > > > that makes searching your log files as easy as surfing the  web. 
> > > > > DOWNLOAD SPLUNK!
> > > > >
> > > > > _______________________________________________
> > > > > Matplotlib-devel mailing list
> > > > > Mat...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> > > >
> > > >--
> > > >Darren S. Dale, Ph.D.
> > > >dd...@co...
> > > >
> > > >
> > > >-------------------------------------------------------
> > > >This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > > language that extends applications into web and mobile media. Attend
> > > > the live webcast and join the prime developer group breaking into
> > > > this new coding territory!
> > > > _______________________________________________ Matplotlib-devel
> > > > mailing list
> > > >Mat...@li...
> > > >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > language that extends applications into web and mobile media. Attend
> > > the live webcast and join the prime developer group breaking into this
> > > new coding territory!
> > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164
> > >2 _______________________________________________
> > > Matplotlib-devel mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >--
> >Darren S. Dale, Ph.D.
> >dd...@co...
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language that extends applications into web and mobile media. Attend the
> > live webcast and join the prime developer group breaking into this new
> > coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> >Matplotlib-devel mailing list
> >Mat...@li...
> >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

On Tue, 28 Feb 2006, John Hunter wrote:

> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> None necessary. However, could you post an example of how
>     Darren> to do a dev checkout?  I thought I had followed the
>     Darren> instructions, but commit is asked for a password for the
>
> I did
>
> svn co --username=jdh2358 --password=mypass https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
>
> and then I could make commits with no prompting.

I was just wondering what the recommended check-out command
for "test-users" would be. With
  svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk matplotlib

I get the whole tree:
  56K     ./.svn
  280K    ./CVSROOT
  69M     ./course
  31M     ./htdocs
  50M     ./matplotlib
  194M    ./toolkits
  39M     ./users_guide
which is about 381 MB...

The answer seems to be this one:
  svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib \
       matplotlib

Best, Arnd


P.S. For the above command I get the following:

Error validating server certificate for 'https://svn.sourceforge.net:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *.sourceforge.net
 - Valid: from Dec  8 13:40:07 2005 GMT until Feb  7 13:40:07 2007 GMT
 - Issuer: Equifax Secure Certificate Authority, Equifax, US
 - Fingerprint:
49:b8:cb:87:04:8c:49:39:45:83:dd:4c:cf:c7:54:57:b0:9e:84:5d
(R)eject, accept (t)emporarily or accept (p)ermanently? t