matplotlib-devel Mailing List for matplotlib

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" <the...@jp...> 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-----
>> From: Michael Droettboom [mailto:md...@st...]
>> Sent: Friday, January 02, 2009 7:27 AM
>> To: mat...@li...
>> 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

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
>
> efiring@manini:~/programs/py/mpl/mpl_trunk$ svnmerge merge -S 
> v0_98_5_maintproperty 'svnmerge-integrated' set on '.'
>
> property 'svnmerge-blocked' deleted from '.'.
>
> --- Merging r6717 through r6732 into '.':
> U lib/matplotlib/path.py
>
> property 'svnmerge-integrated' set on '.'
>
> property 'svnmerge-blocked' deleted from '.'.
>
> efiring@manini:~/programs/py/mpl/mpl_trunk$ svn status
> M .
> ? svnmerge-commit-message.txt
> ? doc/build
> ? doc/examples
> ? doc/_static/inheritance0ca9968ee0.pdf
> ? doc/_static/inheritance1bda3e63b5.pdf
> ? doc/_static/inheritance829eaf436e.pdf
> ? doc/_static/inheritance47732b7b79.pdf
> ? doc/_static/inheritance0ca9968ee0.png
> ? doc/_static/inheritancecbc02086c0.pdf
> ? doc/_static/inheritance1bda3e63b5.png
> ? doc/_static/inheritance829eaf436e.png
> ? doc/_static/inheritance47732b7b79.png
> ? doc/_static/mathmpl
> ? doc/_static/inheritancecbc02086c0.png
> ? doc/_static/plot_directive
> ? doc/_static/examples
> M doc/sphinxext/gen_gallery.py
> M doc/sphinxext/gen_rst.py
> M doc/pyplots/README
> ? lib/matplotlib/cbook0.py
> ? lib/matplotlib/colors0.py
> ? lib/matplotlib/transform.py
> ? lib/matplotlib/axes0.py
> M lib/matplotlib/path.py
> ? examples/tests/ps
> ? examples/tests/agg
> ? examples/tests/svg
> ? examples/tests/pdf
> ? examples/tests/template
These other modified files all look to be no-ops (they are property-only 
-- no diffs) -- probably the result of someone else manually backporting 
changes to the branch and not merging back to the trunk yet. All seemed 
harmless, so I went ahead and committed the merge.
Mike

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@manini:~/programs/py/mpl/mpl_trunk$ svnmerge merge -S 
v0_98_5_maintproperty 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' deleted from '.'.
--- Merging r6717 through r6732 into '.':
U lib/matplotlib/path.py
property 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' deleted from '.'.
efiring@manini:~/programs/py/mpl/mpl_trunk$ svn status
 M .
? svnmerge-commit-message.txt
? doc/build
? doc/examples
? doc/_static/inheritance0ca9968ee0.pdf
? doc/_static/inheritance1bda3e63b5.pdf
? doc/_static/inheritance829eaf436e.pdf
? doc/_static/inheritance47732b7b79.pdf
? doc/_static/inheritance0ca9968ee0.png
? doc/_static/inheritancecbc02086c0.pdf
? doc/_static/inheritance1bda3e63b5.png
? doc/_static/inheritance829eaf436e.png
? doc/_static/inheritance47732b7b79.png
? doc/_static/mathmpl
? doc/_static/inheritancecbc02086c0.png
? doc/_static/plot_directive
? doc/_static/examples
 M doc/sphinxext/gen_gallery.py
 M doc/sphinxext/gen_rst.py
 M doc/pyplots/README
? lib/matplotlib/cbook0.py
? lib/matplotlib/colors0.py
? lib/matplotlib/transform.py
? lib/matplotlib/axes0.py
M lib/matplotlib/path.py
? examples/tests/ps
? examples/tests/agg
? examples/tests/svg
? examples/tests/pdf
? examples/tests/template

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:md...@st...]
> Sent: Friday, January 02, 2009 7:27 AM
> To: mat...@li...
> 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
> > 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()
> >
> >
> >
>
>
> -----------------------------------------------------------------------
> -------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.10.2/1872 - Release Date:
> 1/2/2009 1:10 PM

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
>
> pdf.close()
>
>
> 

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

Mike, Jan,
The thread
http://www.mail-archive.com/mat...@li.../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.
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?
Polar plotting could still use more work, but I doubt I will be able to 
do much any time soon.
Eric