Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
Same here running Debian/squeeze - and a real problem, as the 2nd
pages with same content as before disappeared (generated by
pdflatex, viewed with evince and okular). gs works.
Maybe a special condition: AabcBabc > AabcB - the lost duplicated (by
LaTeX-source, no binary 'PDFtricks') pages at the tail of the
document.
Solution: --do-unify-pages=false
Result: 214325/40092/40101 bytes. Only nine bytes more!
Seems to be no problem of pdfsizeopt itself. No errors with evince@Debian/sid.
Original comment by cartho...@googlemail.com
on 3 Sep 2011 at 9:26
Oddly enough --use-mutivalent=yes here generates book.psom.pdf, which is not
viewable at all in evince. It's worth a closer look investigating what's going
on.
In the meantime, do you have a smaller document with similar problems?
Original comment by pts...@gmail.com
on 15 Apr 2012 at 9:18
Please discard my previous comment about --use-multivalent=yes . As of r191, it
works as the following: with --do-unify-pages=yes, old evince displays the
output it without any messages; with --do-unify-pages=no, Evince on Ubuntu
Lucid print
Error: Loop in Pages tree
Error: Loop in Pages tree
Error: Loop in Pages tree
Error: Loop in Pages tree
Error: Loop in Pages tree
Error: Loop in Pages tree
Error: Loop in Pages tree
Error: Loop in Pages tree
Error: Page count in top-level pages object is incorrect
to stdout before displaying the PDF correctly.
There is nothing here to fix in pdfsizeopt, this seems to be a bug in xpdf,
evince and libpoppler (all using the same codebase). Please report this bug
against those projects, or use --do-unify-pages=no (or =false) as a workaround.
If you think pdfsizeopt creates incorrect or invalid PDF, please leave a
comment containing a reason why (preferably pointing to a paragraph into the
PDF reference).
Original comment by pts...@gmail.com
on 15 Apr 2012 at 10:25
Original issue reported on code.google.com by
pts...@gmail.com
on 10 Feb 2011 at 8:16