headers
Jouni K. Seppänen | 1 Jan 23:43
Face
Picon
Picon
Picon
Favicon
Gravatar

Multipage pdf files

I added support to the pdf backend for multipage pdf files. The current
API (which I'm not entirely happy with) is that you create a PdfFile
object, plot your figures, saving each one to the PdfFile object, and
then close the object. The part I'm unhappy about is that because
PdfFile is a file-like object - it has a write method - you can
accidentally save your figure as a png into it and get a broken pdf
file. You have to specify format='pdf' to savefig to avoid this.

Here's an example:

from matplotlib.backends.backend_pdf import PdfFile

pdf = PdfFile('multipage_pdf.pdf')

figure(...)
# build your figure
savefig(pdf, format='pdf')

# repeat for all your figures

pdf.close()

--

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

------------------------------------------------------------------------------
Permalink | Reply | 4 comments |
headers
Eric Firing | 2 Jan 05:01
Favicon
Gravatar

polar plotting and theta wrapping

Mike, Jan,

The thread
http://www.mail-archive.com/matplotlib-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f <at> public.gmane.org/msg08342.html

culminated in changeset r6106, which seemed to fix the immediate 
problem, but in fact introduced a major bug: polar plotting was broken 
for lines or patches with angles crossing zero.

The real solution to the original problem is not a change to mpl, but to 
user code.  In the example from the thread,

r = np.transpose(.1+np.arange ( 0 , 0.7 , 0.001))
theta = -4.5 * np.pi *r
freq = r*10e9
data = np.multiply(r,np.exp(1j*theta))
ax.plot(np.unwrap(angle(data)),abs(data))  # note added call to unwrap

the original problem was that the angle was jumping from near minus pi 
to near plus pi, and the solution is to use the unwrap function, or 
equivalent, to make the angle vary smoothly from start to finish, with 
no jumps.

Any attempt to normalize the angles to a fixed range of length 2 pi 
inside of mpl is sure to wreck valid user code; it merely moves the 
trouble spot to a different angle.

In 6731 I reverted the normalization change from 6106, and also improved 
the r-tick locations in cases where the actual r-data range is small.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Droettboom | 2 Jan 15:09

Re: polar plotting and theta wrapping

Eric Firing wrote:
> Mike, Jan,
>
> Any attempt to normalize the angles to a fixed range of length 2 pi 
> inside of mpl is sure to wreck valid user code; it merely moves the 
> trouble spot to a different angle.
Thanks for catching this.  Clearly that was a bone-headed fix on my 
part... :(
>
> In 6731 I reverted the normalization change from 6106, and also 
> improved the r-tick locations in cases where the actual r-data range 
> is small.
>
> Mike, of course I realized too late that I should have made the change 
> in the maintenance branch and used svnmerge to propagate it to the 
> trunk; should I just make the change manually in the branch?
That should work fine.  Then run "svnmerge merge ; svn commit" back on 
the trunk to mark it as merged.
>
> Polar plotting could still use more work, but I doubt I will be able 
> to do much any time soon.

Yeah -- there's lots of tricky side issues.

Cheers,
Mike

------------------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Michael Droettboom | 2 Jan 16:27

Re: Multipage pdf files

It's slightly hackish, but would it be possible to do an "isinstance" 
check in savefig, and if the first arg is a PdfFile, set "format" to 
"pdf" automatically, and if "format" is set to something else raise an 
exception?  A little hackish because it doesn't necessarily scale to 
other formats easily, but it would prevent the user from shooting 
herself in the foot.

Mike

Jouni K. Seppänen wrote:
> I added support to the pdf backend for multipage pdf files. The current
> API (which I'm not entirely happy with) is that you create a PdfFile
> object, plot your figures, saving each one to the PdfFile object, and
> then close the object. The part I'm unhappy about is that because
> PdfFile is a file-like object - it has a write method - you can
> accidentally save your figure as a png into it and get a broken pdf
> file. You have to specify format='pdf' to savefig to avoid this.
>
> Here's an example:
>
> from matplotlib.backends.backend_pdf import PdfFile
>
> pdf = PdfFile('multipage_pdf.pdf')
>
> figure(...)
> # build your figure
> savefig(pdf, format='pdf')
>
> # repeat for all your figures
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Drain, Theodore R | 2 Jan 17:56
Picon
Picon
Favicon

Re: Multipage pdf files

Another (still slightly hacky) way might be to define an optional attribute of the file object.  Something
like this:

if hasattr( outputFile, "mplFormat" ):
   format = getattr( outputFile, "mplFormat" )

Then have set PdfFile.mplFormat to be "pdf".  This is a little less hacky in that it doesn't depend on coding a
specific class into savefig.

Ted

> -----Original Message-----
> From: Michael Droettboom [mailto:mdroe@...]
> Sent: Friday, January 02, 2009 7:27 AM
> To: matplotlib-devel@...
> Subject: Re: [matplotlib-devel] Multipage pdf files
>
> It's slightly hackish, but would it be possible to do an "isinstance"
> check in savefig, and if the first arg is a PdfFile, set "format" to
> "pdf" automatically, and if "format" is set to something else raise an
> exception?  A little hackish because it doesn't necessarily scale to
> other formats easily, but it would prevent the user from shooting
> herself in the foot.
>
> Mike
>
> Jouni K. Seppänen wrote:
> > I added support to the pdf backend for multipage pdf files. The
> current
> > API (which I'm not entirely happy with) is that you create a PdfFile
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Firing | 2 Jan 18:29
Favicon
Gravatar

Re: polar plotting and theta wrapping

Michael Droettboom wrote:
> Eric Firing wrote:
>> Mike, Jan,
>>
>> Any attempt to normalize the angles to a fixed range of length 2 pi 
>> inside of mpl is sure to wreck valid user code; it merely moves the 
>> trouble spot to a different angle.
> Thanks for catching this.  Clearly that was a bone-headed fix on my 
> part... :(
>>
>> In 6731 I reverted the normalization change from 6106, and also 
>> improved the r-tick locations in cases where the actual r-data range 
>> is small.
>>
>> Mike, of course I realized too late that I should have made the change 
>> in the maintenance branch and used svnmerge to propagate it to the 
>> trunk; should I just make the change manually in the branch?
> That should work fine.  Then run "svnmerge merge ; svn commit" back on 
> the trunk to mark it as merged.

Mike,

The following is the result of svnmerge merge and svn status; I have not 
yet run svn commit because the status output suggests to me that things 
are getting merged that perhaps should not, since I don't know anything 
about them.  Advice?

Eric

efiring <at> manini:~/programs/py/mpl/mpl_trunk$ svnmerge merge -S
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Droettboom | 2 Jan 18:57

Re: polar plotting and theta wrapping

Eric Firing wrote:
> Michael Droettboom wrote:
>> Eric Firing wrote:
>>> Mike, Jan,
>>>
>>> Any attempt to normalize the angles to a fixed range of length 2 pi 
>>> inside of mpl is sure to wreck valid user code; it merely moves the 
>>> trouble spot to a different angle.
>> Thanks for catching this.  Clearly that was a bone-headed fix on my 
>> part... :(
>>>
>>> In 6731 I reverted the normalization change from 6106, and also 
>>> improved the r-tick locations in cases where the actual r-data range 
>>> is small.
>>>
>>> Mike, of course I realized too late that I should have made the 
>>> change in the maintenance branch and used svnmerge to propagate it 
>>> to the trunk; should I just make the change manually in the branch?
>> That should work fine.  Then run "svnmerge merge ; svn commit" back 
>> on the trunk to mark it as merged.
>
> Mike,
>
> The following is the result of svnmerge merge and svn status; I have 
> not yet run svn commit because the status output suggests to me that 
> things are getting merged that perhaps should not, since I don't know 
> anything about them.  Advice?
>
> Eric
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jouni K. Seppänen | 2 Jan 19:01
Face
Picon
Picon
Picon
Favicon
Gravatar

Re: Multipage pdf files

Or perhaps the user-visible object doesn't need to be the same PdfFile
that is used internally (which I think should be file-like, since when
we add better image compression, we will want to pass the PdfFile to the
png/jpeg/whatever library to write to). Something like

class PdfFileProxy:
    def __init__(self, filename):
        self.pdf_file = PdfFile(filename)

except the name should be better.

--

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

"Drain, Theodore R" <theodore.r.drain@...> writes:

> Another (still slightly hacky) way might be to define an optional attribute of the file object.  Something
like this:
>
> if hasattr( outputFile, "mplFormat" ):
>    format = getattr( outputFile, "mplFormat" )
>
>
> Then have set PdfFile.mplFormat to be "pdf".  This is a little less hacky in that it doesn't depend on coding
a specific class into savefig.
>
> Ted
>
>> -----Original Message-----
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jae-Joon Lee | 5 Jan 07:01
Picon
Gravatar

usetex w/ preview.sty

Hello,

I committed a patch to optionally use preview.sty with usetex=True.
This is to support a baseline alignment.

A summary of changes:

 * added a get_text_width_height_descent() method in the TexManager
class, and modified the agg, ps and pdf backends to utilize this
method.

 * added a new rc parameter, 'text.latex.preview'. If True,
preview.sty is used to generate dvi files and baseline information of
each dvi file is stored in a separate file.
TexManager.get_text_width_height_descent() method uses this
information.

 * If text.latex.preview==False,
TexManager.get_text_width_height_descent() method uses dviread module
(this is what the pdf backend has been using), but the returned
descent value of the text is sometimes incorrect.

 * added an example ("usetex_baseline_test.py" ). The output is
attached with this email.

If you have a preview.sty installed, please test this (set
"text.latex.preview=True" in you rc file) and report any problems.
Regards,

-JJ
(Continue reading)

Permalink | Reply | 9 comments |
headers
Sandro Tosi | 5 Jan 10:52
Picon
Favicon

What would you like to see in a book about Matplotlib?

Hello and Happy 2009!

I received the interesting proposal to author a book on Matplotlib,
the powerful 2D plotting library for Python.

While preparing the arguments list, I'd like to hear even your
opinion, because different points-of-view will lead to a better
product.

Some basic question I'd like to ask are:

- what are you using matplotlib for?
- what are the things you like the most of matplotlib, that you want
to give emphasis to? And why?
- what are the (basic) things that, when you were beginning to use
matplotlib, you wanted to see grouped up but couldn't find?
- what would you like to see in a book about matplotlib?
- what are some those advanced feature that made you yell "WOW!!" ?
- what are the things you'd like to explore of matplotlib and never
had time to do?

Your suggestions are really appreciated :) And wish me good luck!

Cheers,
--

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 24 comments |

Gmane