Thread: [matplotlib-devel] pdf output

A further comment on the windows PDF problems. 

PDF output generated by matplotlib on Windows and on OS X is readable 
in Preview.app on OS X but is not readable in Acrobat 8.1.0 or 7.0.5 
on Windows.

Adobe 7.0.5 produces the message "There were too many arguments".

At this point I have no idea how to proceed, but I will at least post
the correct to ttconv.

	- Paul

Paul Kienzle wrote:
> A further comment on the windows PDF problems. 
> 
> PDF output generated by matplotlib on Windows and on OS X is readable 
> in Preview.app on OS X but is not readable in Acrobat 8.1.0 or 7.0.5 
> on Windows.
> 
> Adobe 7.0.5 produces the message "There were too many arguments".
> 
> At this point I have no idea how to proceed, but I will at least post
> the correct to ttconv.

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

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.

Cheers,
Mike

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

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

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

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

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

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

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
>