matplotlib-devel Mailing List for matplotlib

=0A=
import pylab=0A=
from basic_units import cm=0A=
=0A=
fig =3D pylab.figure()=0A=
ax =3D fig.add_subplot(111)=0A=
=0A=
#BUG: This will fail.=0A=
ax.annotate( "Note 01", [0.5*cm, 0.5*cm] )=0A=
=0A=
pylab.show()=0A=
=0A=

The attached script demonstrates several bugs that are all related to the Axes class. Areas affected are:
* Autoscaling
* Ellipse
* Inverting Axis objects
* Fixed aspect ratio
1) Auto scaling is not enacted when adding a Patch to an axes (more of a feature)
2) When manually calling axes.autoscale_view(), the boundaries of an Ellipse are incorrectly computed as they do not take into
account the rotation of the ellipse.
3) Inverting the axes using the current method of reversing the axes limits does not always take effect right away. An explicit
call to axes.apply_aspect() fixes this.
4) When the axes are inverted and an Ellipse is rendered, then it becomes asymptotic and not an ellipse.
5) When the axes are inverted and axes.set_aspect('equal', 'datalim') has been called, then resizing the plot window will result in
the axes reverting back to their original state.
When it comes to handling inverted axes I have a proposition on how to better handle this. It seems like every other month a user
asks the question how to do this and perhaps there should be a direct interface to do so. Something like the following...
axes.invert_xaxis()
axes.invert_yaxis()
Each method would set a flag on the corresponding Axis object and all calls to 'axes.set_xlim' & 'axes.set_ylim' would check the
appropriate flag and automatically set the values in the correct order. Additionally all calls to 'axes.get_xlim' and
'axes.get_ylim' would return the values in min, max order. I believe that an interface like this would greatly simplify things for
both the user and the maintainer of the internal code (no need to put in checks to see if the axes have been inverted). A simple
'axes.xaxis_inverted' or 'axes.yaxis_inverted' call would be sufficient to determine if the axes have been inverted (for those users
who would need to check).

"""=0A=
plot using a variety of cm vs inches conversions. The example shows=0A=
how default unit instrospection works (ax1), how various keywords can=0A=
be used to set the x and y units to override the defaults (ax2, ax3,=0A=
ax4) and how one can set the xlimits using scalars (ax3, current units=0A=
assumed) or units (conversions applied to get the numbers to current=0A=
units)=0A=
=0A=
"""=0A=
from basic_units import cm, inch=0A=
from pylab import figure, show, nx=0A=
=0A=
cms =3D cm *nx.arange(0, 10, 2)=0A=
=0A=
fig =3D figure()=0A=
=0A=
ax1 =3D fig.add_subplot(2,2,1)=0A=
ax1.bar(cms, cms)=0A=
=0A=
ax2 =3D fig.add_subplot(2,2,2)=0A=
ax2.bar(cms, cms, xunits=3Dcm, yunits=3Dinch)=0A=
=0A=
ax3 =3D fig.add_subplot(2,2,3)=0A=
ax3.bar(cms, cms, xunits=3Dinch, yunits=3Dcm)=0A=
ax3.set_xlim(3, 6) # scalars are interpreted in current units=0A=
=0A=
ax4 =3D fig.add_subplot(2,2,4)=0A=
ax4.bar(cms, cms, xunits=3Dinch, yunits=3Dinch)=0A=
#fig.savefig('simple_conversion_plot.png')=0A=
ax4.set_xlim(3*cm, 6*cm) # cm are converted to inches=0A=
=0A=
show()=0A=

On Tue, Sep 11, 2007 at 12:31:25PM -0400, Michael Droettboom wrote:
> Did r3829 not work for you? (Or did you miss that in my earlier post?)
> 
> I don't think anything related to Lengths has changed recently, and it 
> did work at one point...
The current svn works --- I must have missed a build step when testing.
Thanks,
	- Paul

Has anyone worked with postscript files on windows? I don't know if this i=
s
related, but when I do a savefig('foo.ps',dpi=3D150) on plot generated by
pcolormesh, I find that ghostview gives the error:
"
DSC Error at line 518:
%%Page: 1 1
This %%Page: line occured in the trailer, which is not legal.
EPS files should be encapsulated in %%BeginDocument/%%EndDocument
It is possible that an EPS file was incorrectly encapsulated
and that we have been confused by the %%Trailer in an EPS file."
This was running with the latest version from SVN. I looked in the file an=
d
could not find a BeginDocument error.
Thanks,
William
On 9/11/07, Jouni K. Sepp=E4nen <jk...@ik...> wrote:
>
> Paul Kienzle <pki...@ni...> writes:
>
> > I'm not sure yet how to fix the problem, but in the sample I sent
> > earlier if I change:
> >
> > 5 0 obj
> > << /Length 11 0 R >>
> > endobj
> >
> > to
> >
> > 5 0 obj
> > << /Length 1239 >>
> > endobj
> >
> > then both gv and acroread can process the file without error.
>
> Putting the length of a stream in an indirect object is allowed by the
> PDF spec, and specifically mentioned as an example of how you can write
> a pdf file in one pass. Does the latest svn version (which has the
> bugfix by Michael) not work for you?
>
> --
> Jouni K. Sepp=E4nen
> http://www.iki.fi/jks
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tuesday 11 September 2007 02:23:49 pm Eric Firing wrote:
> Darren Dale wrote:
> [...]
>
> > Could MANIFEST also be removed? I think it is generated from MANIFEST.in.
>
> It is, but it is not clear to me when or how this occurs. Does
> distutils do it? MANIFEST seems to have special significance, but I
> don't know anything about it beyond that.
It is created when we do "python setup.py sdist". Once it is created, it is 
used to create the source archive. There is a short discussion here:
http://docs.python.org/dist/manifest-options.html. I think it is appropriate 
to remove it from the archive, I'll go ahead and do it.
Darren

Paul Kienzle <pki...@ni...> writes:
> I'm not sure yet how to fix the problem, but in the sample I sent
> earlier if I change:
>
> 5 0 obj
> << /Length 11 0 R >>
> endobj
>
> to
>
> 5 0 obj
> << /Length 1239 >>
> endobj
>
> then both gv and acroread can process the file without error.
Putting the length of a stream in an indirect object is allowed by the
PDF spec, and specifically mentioned as an example of how you can write
a pdf file in one pass. Does the latest svn version (which has the
bugfix by Michael) not work for you?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Darren Dale wrote:
[...]
> 
> Could MANIFEST also be removed? I think it is generated from MANIFEST.in.
It is, but it is not clear to me when or how this occurs. Does 
distutils do it? MANIFEST seems to have special significance, but I 
don't know anything about it beyond that.
Eric

Michael Droettboom <md...@st...> writes:
> There was a small typo in the recently added support for non-rectangular 
> clip paths. Fixed in r3829.
>
> (Jouni -- you may want to review this and verify that my change is
> correct.)
Yes, your change fixes a bug; thanks. Strangely enough, Apple's
Preview.app (Version 3.0.9 (409)) displayed the buggy version of e.g.
polar_demo_pdf.pdf just fine.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Saturday 08 September 2007 09:08:12 pm Eric Firing wrote:
> Michael Droettboom wrote:
> > lib/matplotlib/mpl-data/matplotlibrc is generated at build time by
> > interpolating some fields in matplotlibrc.template.
> >
> > Since it always get changed, it always shows up as a modified file by
> > svn status. This is only a minor annoyance when working on the trunk.
> > However, when working on a branch with svnmerge, svnmerge won't let me
> > merge from trunk if I have any modified files at all, so every time I
> > want to merge, I have to be sure to revert that file.
> >
> > Is there any reason not to just remove this file from SVN?
>
> I could not think of any reason, and I did not see any message to the
> contrary, so I went ahead and removed it.
Could MANIFEST also be removed? I think it is generated from MANIFEST.in.
Darren

Did r3829 not work for you? (Or did you miss that in my earlier post?)
I don't think anything related to Lengths has changed recently, and it 
did work at one point...
Cheers,
Mike
Paul Kienzle wrote:
> On Tue, Sep 11, 2007 at 10:57:18AM -0400, Paul Kienzle wrote:
>> I'm not sure yet how to fix the problem, but in the sample I sent
>> earlier if I change:
>>
>> 5 0 obj
>> << /Length 11 0 R >>
>> endobj
>>
>> to
>>
>> 5 0 obj
>> << /Length 1239 >>
>> endobj
>>
>> then both gv and acroread can process the file without error.
>>
>> 	- Paul
> 
> If I change every instance beginStream in backend_pdf.py to use None 
> rather than a reserved object for the length of the stream then 
> acroread/gv can process the resulting pdf files.
> 
> I'm guessing this will be less efficient for the writer since it has
> to keep the entire stream in memory in order to compute its length
> prior to writing it. The alternative would be to reserve space,
> write the stream, rewind to write the length then seek forward to
> the end, but that won't work if e.g., the pdf is sent to a pipe.
> 
> Let me know if I should post the changes.
> 
> 	- Paul
-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, Sep 11, 2007 at 10:57:18AM -0400, Paul Kienzle wrote:
> I'm not sure yet how to fix the problem, but in the sample I sent
> earlier if I change:
> 
> 5 0 obj
> << /Length 11 0 R >>
> endobj
> 
> to
> 
> 5 0 obj
> << /Length 1239 >>
> endobj
> 
> then both gv and acroread can process the file without error.
> 
> 	- Paul
If I change every instance beginStream in backend_pdf.py to use None 
rather than a reserved object for the length of the stream then 
acroread/gv can process the resulting pdf files.
I'm guessing this will be less efficient for the writer since it has
to keep the entire stream in memory in order to compute its length
prior to writing it. The alternative would be to reserve space,
write the stream, rewind to write the length then seek forward to
the end, but that won't work if e.g., the pdf is sent to a pipe.
Let me know if I should post the changes.
	- Paul

I'm not sure yet how to fix the problem, but in the sample I sent
earlier if I change:
 5 0 obj
 << /Length 11 0 R >>
 endobj
to
 5 0 obj
 << /Length 1239 >>
 endobj
then both gv and acroread can process the file without error.
	- Paul
On Tue, Sep 11, 2007 at 08:49:05AM -0400, Michael Droettboom wrote:
> This seems to be a cross platform bug and unrelated to fonts -- at least 
> I am able to reproduce it on Linux.
> 
> There was a small typo in the recently added support for non-rectangular 
> clip paths. Fixed in r3829.
> 
> (Jouni -- you may want to review this and verify that my change is correct.)
> 
> Cheers,
> Mike
> 
> Paul Kienzle wrote:
> > On Mon, Sep 10, 2007 at 04:19:24PM -0400, Michael Droettboom wrote:
> >> Can you set "pdf.compression : 0" and send me a copy of the troublesome 
> >> PDF (probably best off list if it's a large file.)?
> > 
> > I used the following:
> > 
> > import pylab
> > pylab.rc('pdf',compression=0)
> > plyab.plot([1,2,3],[1,2,3])
> > pylab.savefig('simple.pdf')
> > 
> > See attached.
> > 
> >> Do you know what set of fonts are getting embedded? If their not in the 
> >> mpl set, it's possible they haven't been tested.
> > 
> > Should be the standard set, but I haven't verified.
> > 
> > - Paul
> 
> -- 
> Michael Droettboom
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA

This seems to be a cross platform bug and unrelated to fonts -- at least 
I am able to reproduce it on Linux.
There was a small typo in the recently added support for non-rectangular 
clip paths. Fixed in r3829.
(Jouni -- you may want to review this and verify that my change is correct.)
Cheers,
Mike
Paul Kienzle wrote:
> On Mon, Sep 10, 2007 at 04:19:24PM -0400, Michael Droettboom wrote:
>> Can you set "pdf.compression : 0" and send me a copy of the troublesome 
>> PDF (probably best off list if it's a large file.)?
> 
> I used the following:
> 
> import pylab
> pylab.rc('pdf',compression=0)
> plyab.plot([1,2,3],[1,2,3])
> pylab.savefig('simple.pdf')
> 
> See attached.
> 
>> Do you know what set of fonts are getting embedded? If their not in the 
>> mpl set, it's possible they haven't been tested.
> 
> Should be the standard set, but I haven't verified.
> 
> - Paul
-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA