Re: [matplotlib-devel] pdf output
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 SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pdf output
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 SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pdf output
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pdf output
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] lib/matplotlib/mpl-data/matplotlibrc in SVN
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pdf output
Michael Droettboom <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] lib/matplotlib/mpl-data/matplotlibrc in SVN
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pdf output
Paul Kienzle <[EMAIL PROTECTED]> 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] lib/matplotlib/mpl-data/matplotlibrc in SVN
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pdf output
Has anyone worked with postscript files on windows? I don't know if this is
related, but when I do a savefig('foo.ps',dpi=150) 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 and
could not find a BeginDocument error.
Thanks,
William
On 9/11/07, Jouni K. Seppänen <[EMAIL PROTECTED]> wrote:
>
> Paul Kienzle <[EMAIL PROTECTED]> 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
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pdf output
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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bar plot forget units information
When using the 'bar' plot command, unit information is lost when changing the
units for a given axis. The attached script
demonstrates this.
This is not the case for line plots because of the use of Line2D's 'recache'
method.
--James Evans
"""
plot using a variety of cm vs inches conversions. The example shows
how default unit instrospection works (ax1), how various keywords can
be used to set the x and y units to override the defaults (ax2, ax3,
ax4) and how one can set the xlimits using scalars (ax3, current units
assumed) or units (conversions applied to get the numbers to current
units)
"""
from basic_units import cm, inch
from pylab import figure, show, nx
cms = cm *nx.arange(0, 10, 2)
fig = figure()
ax1 = fig.add_subplot(2,2,1)
ax1.bar(cms, cms)
ax2 = fig.add_subplot(2,2,2)
ax2.bar(cms, cms, xunits=cm, yunits=inch)
ax3 = fig.add_subplot(2,2,3)
ax3.bar(cms, cms, xunits=inch, yunits=cm)
ax3.set_xlim(3, 6) # scalars are interpreted in current units
ax4 = fig.add_subplot(2,2,4)
ax4.bar(cms, cms, xunits=inch, yunits=inch)
#fig.savefig('simple_conversion_plot.png')
ax4.set_xlim(3*cm, 6*cm) # cm are converted to inches
show()
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Several Axes issues
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).
from pylab import *
from matplotlib.patches import Ellipse
delta = 45.0 # degrees
angles = arange(0, 360+delta, delta)
ells = [Ellipse((1, 1), 4, 2, a) for a in angles]
a = subplot(111, aspect='equal')
#BUG 1792567: Setting the autoscale to on does nothing when plotting a patch
a.set_autoscale_on(True)
# set the aspect ratio
a.set_aspect("equal", "datalim")
for e in ells:
e.set_alpha(0.1)
a.add_patch(e)
# Since autoscale does not work for patches we call manually
a.autoscale_view()
# put this here to force the axes to flush whatever caching it is is doing
# so that we can actually invert the axes
a.apply_aspect()
#BUG 1792575: Once the autoscale happens, it doesn't take into account
# the rotation value of an ellipse for calculating the view limits.
#BUG 1792599: Inverting the y-axis does nothing regardless of calling it before
# or after 'a.autoscale_view()
ymin, ymax = a.get_ylim()
a.set_ylim(ymax, ymin)
#BUG 1792603: Inverting the y-axis causes the rendered ellipse to be asymptotic.
show()
#BUG 1792615: Resizing the figure window with winverted axes looses the
inversion.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] annotate fails with unitized data
When passing unitized data into the annotate function it will fail because it attempts to use the data as a float. See the attached script for an example. --James Evans import pylab from basic_units import cm fig = pylab.figure() ax = fig.add_subplot(111) #BUG: This will fail. ax.annotate( "Note 01", [0.5*cm, 0.5*cm] ) pylab.show() - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
