ANN: matplotlib-0.87.1

Development matplotlib-devel
1

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.

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.

simple_plot.ps (140 KB)

2

John,

it looks centered with KGhostView (debian sarge)

3

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

···

On Tuesday 07 March 2006 19:10, John Hunter wrote:

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

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.

4

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

5

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.

6

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.

7

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.

– Paul

···

On 3/10/06, Gary Ruben <gruben@…1…> 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.

8

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.

···

On Friday 10 March 2006 07:40, Gary Ruben wrote:

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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

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

dd55@...143...
office: (607) 255-9894
fax: (607) 255-9001

9

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:54, Paul Barrett wrote:

On 3/10/06, Gary Ruben <gruben@...1...> 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.

10

Darren Dale <dd55@...143...> writes:

> 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 3:14 am, Gary Ruben wrote: