matplotlib-devel Mailing List for matplotlib (Page 7)

After testing this patch, I tried checking it in, but I'm getting an error:
$ svn commit src
Authentication realm: <https://svn.sourceforge.net:443> SourceForge
Subversion area
Password for 'astraw':
svn: Commit failed (details follow):
svn: MKACTIVITY of
'/svnroot/matplotlib/!svn/act/451cc94f-c20e-0410-914b-b8458948145c': 403
Forbidden (https://svn.sourceforge.net)
svn: Your commit message was left in a temporary file:
svn: 
'/home/astraw/other-peoples-src/matplotlib/matplotlib.svn/svn-commit.2.tmp'
I tried a couple of times to make sure I got the password right, but it
still didn't go. Does anyone know what's going on? This would have been
my first commit since we switched to subversion.
Anyhow, it looks like I can't apply the other patches right now, so I'm
giving up for the time being.
James Evans wrote:
>When compiling with less forgiving compilers 
>('MSVC', 'g++ --pedantic') there are a few sections of
>code that will fail. The attatched SVN diff file will
>patch the code to remedy this.
>
>The patch is as follows:
>-- In several places arrays are initialized with a
>variable for the length. As per Stroustrup arrays can
>only be specified with constants or using 'new' .
>
>-- in strict forms of C all variable declarations in a
>function must be finished before any actual code is run
>(cntr.c) 
> 
>

I just made some changes to svn that I want to mention. Sometimes, usetex's 
external dependencies could fail silently. Andrew suggested that the 
subprocess module included in python-2.4 could be used to catch the exit 
status and therefore report such problems. I added this module to mpl; tests 
on both linux systems with python-2.3 and python-2.4 were successful. Now if 
you pass give latex bad syntax, an exception is raised and you will see the 
report from latex. 
I also added a papertype kwarg for postscript. You can do something like
savefig('test.eps', papertype='letter')
or if you want the pagesize to scale automatically:
savefig('test.eps', papertype='auto')
Adding the papertype kwarg actually required a small change to every backend. 
I tested my work with backend_driver, and no problems turned up. Please let 
me know if you experience problems.
Finally, I got landscape orientation working properly with the usetex option. 
This wasnt an easy task, and I'll leave out the gory details, but I will say 
I've been pulling my hair out all weekend and my eyes are crossed.
Darren

When compiling with less forgiving compilers 
('MSVC', 'g++ --pedantic') there are a few sections of
code that will fail. The attatched SVN diff file will
patch the code to remedy this.
The patch is as follows:
-- In several places arrays are initialized with a
variable for the length. As per Stroustrup arrays can
only be specified with constants or using 'new' .
-- in strict forms of C all variable declarations in a
function must be finished before any actual code is run
(cntr.c) 

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