expected endstream+endobj,seems new bug

[GoogleCodeExporter]

F:\2009\pdfsizeopt\win32>python pdfsizeopt.py cube.pdf
info: This is pdfsizeopt.py rUNKNOWN.
info: loading PDF from: cube.pdf
info: loaded PDF of 14208 bytes
info: separated to 5 objs
info: found 0 Type1 fonts loaded
info: found 0 Type1C fonts loaded
info: writing Multivalent input PDF: pso.conv.mi.tmp.pdf
info: saving PDF with 4 objs to: pso.conv.mi.tmp.pdf
info: generated 14203 bytes (100%)
info: executing Multivalent to optimize PDF: java -cp Multivalent.jar
tool.pdf.C
ompress pso.conv.mi.tmp.pdf
file:/F:/2009/pdfsizeopt/win32/pso.conv.mi.tmp.pdf, 14203 bytes
additional compression may be possible with:
         -compact
=> new length = 14042, saved 1%, elapsed time = 0 sec
info: Multivalent generated pso.conv.mi.tmp-o.pdf of 421 bytes (3%)
Traceback (most recent call last):
  File "pdfsizeopt.py", line 6121, in <module>
    main(sys.argv)
  File "pdfsizeopt.py", line 6114, in main
    pdf.SaveWithMultivalent(output_file_name)
  File "pdfsizeopt.py", line 5948, in SaveWithMultivalent
    data = self.FixPdfFromMultivalent(data)
  File "pdfsizeopt.py", line 5722, in FixPdfFromMultivalent
    obj_num_by_ofs_out=obj_num_by_in_ofs)
  File "pdfsizeopt.py", line 5475, in ParseSequentially
    objs=length_objs)
  File "pdfsizeopt.py", line 450, in __init__
    (endstream_str, file_ofs + stream_end_idx))
__main__.PdfTokenParseError: expected endstream+endobj in '' at 13911

Original issue reported on code.google.com by roc...@gmail.com on 31 Oct 2009 at 6:37

Attachments:

• cube.pdf
• pso.conv.mi.tmp.pdf
• pso.conv.mi.tmp-o.pdf

[GoogleCodeExporter]

This works for me on Linux. There is no Win32 version of pdfsizeopt.py!

> info: This is pdfsizeopt.py rUNKNOWN.

Next time, please svn checkout pdfsizeopt.py, so it will report the proper 
revision
number instead of rUNKNOWN.

These lines look strange in your output:

=> new length = 14042, saved 1%, elapsed time = 0 sec
info: Multivalent generated pso.conv.mi.tmp-o.pdf of 421 bytes (3%)

In my output on Linux:

=> new length = 14041, saved 1%, elapsed time = 0 sec
info: Multivalent generated pso.conv.mi.tmp-o.pdf of 14063 bytes (99%)

Why is it so that on Windows pdfsizeopt.py reads only 421 bytes of the 14042 
bytes
generated by Multivalent? This is for you to figure out. Maybe you have to use
open(filename, 'rb') instead open(filename)? If you find out, please let me 
know.

Original comment by pts...@gmail.com on 31 Oct 2009 at 7:34

• Changed state: Started

[GoogleCodeExporter]

yes, in windows, need open(filename,'rb'), it is a bug of windows.

it works on my Linux environment.

Original comment by roc...@gmail.com on 1 Nov 2009 at 6:52

[GoogleCodeExporter]

Although there is still no official port of pdfsizeopt to Win32, in r148 I made 
it a bit easier to use pdfsizeopt on Windows: now it opens every file and pipe 
in binary mode.

Feel free to volunteer to write a Windows port. Maybe the post complicated part 
would be making Ghostscript invocations work with os.popen.

Original comment by pts...@gmail.com on 10 Feb 2011 at 10:44

• Changed state: Fixed