pdftopdf produces non-standard-conform pdf files.

Bug #544636 reported by Duncan Lock on 2010-03-22
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Undecided
Martin Pitt
pdftk (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: pdftk

Since upgrading to 9.10 (Karmic), I've been getting an error processing some pdf files with pdftk.

I get the error trying to process pdf files which have been printed from OpenOffice Writer - but the same document 'exported' as a pdf file from OO Writer (via File -> Export as PDF...) - rather than being printed - works fine with pdftk.

I'm using the version of OpenOffice that comes with Karmic (Openoffice.org 3.1.1 OOO310m19 Build:4920, synaptic says openoffice.org-writer 1:3.1.1-5ubuntu1.1). I think this is the same version of office that I was using in Jaunty before upgrading, as I was using this PPA with Jaunty (https://launchpad.net/~openoffice-pkgs/+archive/ppa), so I'm guessing this might be something to do with the newer version of CUPS-PDF that comes with Karmic?

My two test case pdf files were created by from a completely blank OO Writer document both exported then printed to pdf - one works with pdftk, the other doesn't. I've attached them to this bug.

I get this error when I try to process the printed one:

duncan@duncan-desktop:~/test$ pdftk blank_pdf_printed_settings_default.pdf output printed_output.pdf
Unhandled Java Exception:
java.lang.ClassCastException: com.lowagie.text.pdf.PdfDictionary cannot be cast to com.lowagie.text.pdf.PRIndirectReference
   at com.lowagie.text.pdf.PdfStamperImp.close(itext-2.1.5.jar.so)

This command also produces a zero length file called printed_output.pdf. Doing the same thing with the exported pdf produces no error:

duncan@duncan-desktop:~/test$ pdftk blank_pdf_exported_settings_default.pdf output export_output.pdf

and creates the export_output.pdf, as expected. All three pdf files appear to work fine in evince.

This bug is a problem because the 'Export as PDF' feature in open office doesn't produce faithful pdf's in all cases - printing to PDF seems to work better - but now pdftk doesn't like my printed pdf's, thus messing up my workflow. If there's any more information that I can provide that would help debug this issue, please just let me know.

CVE References

Duncan Lock (dunc) wrote :
Duncan Lock (dunc) wrote :
description: updated
Johann Felix Soden (johfel) wrote :

pdftk uses the itext library and a mail on its mailing list gave me the right hint:
 http://thread.gmane.org/gmane.comp.java.lib.itext.general/46855/focus=46859

The printed pdf file is not standard conform [1].
The information dictionary of the document is a direct object, not an indirect reference as in the pdf that works.
So this is mainly a bug in the used pdf generator, not in pdftk. However, pdftk should produce a more user-friendly error message.

Can you provide the version of the cups / cups-pdf package which you have installed, please?

[1]: See table 3.11 on page 61 in http://partners.adobe.com/public/developer/en/pdf/PDFReference13.pdf :
"Info dictionary (Optional; must be an indirect reference)"

Changed in pdftk (Ubuntu):
status: New → Confirmed
summary: - java.lang.ClassCastException: com.lowagie.text.pdf.PdfDictionary cannot
- be cast to com.lowagie.text.pdf.PRIndirectReference
+ pdftopdf produces non-standard-conform pdf files.
Johann Felix Soden (johfel) wrote :

The bug is in pdftopdf from the cups package. It wrongly writes the document information dictionary as a direct object.
The attached patch should solve the problem.

tags: added: patch
Till Kamppeter (till-kamppeter) wrote :

Johann Felix Soden, thank you for the patch. I have tried it, but after patching pdftopdf pdftopdf dumps core:

cat ~/ghostscript/gpl/testfiles/CityMap-evince.pdf | PPD=/etc/cups/ppd/pxl.ppd /usr/lib/cups/filter/pdftopdf 1 1 1 1 "" > ~/ghostscript/gpl/testfiles/CityMap-evince-pdftopdf2.pdf*** glibc detected *** /usr/lib/cups/filter/pdftopdf: free(): invalid pointer: 0x00007fefeed46b88 ***

It always dumps core, independent of the input file and the PPD file. The backtrace in gdb is:

#0 0x00007f3aa7c20a85 in raise () from /lib/libc.so.6
#1 0x00007f3aa7c24520 in abort () from /lib/libc.so.6
#2 0x00007f3aa7c5a3e7 in ?? () from /lib/libc.so.6
#3 0x00007f3aa7c64406 in ?? () from /lib/libc.so.6
#4 0x00007f3aa7c6ac93 in free () from /lib/libc.so.6
#5 0x00007f3aa89b3ad9 in Dict::~Dict() () from /usr/lib/libpoppler.so.5
#6 0x00007f3aa8f29690 in P2PDoc::output (this=<value optimized out>,
    str=0x7f3aaa484ba0, deviceCopies=<value optimized out>,
    deviceCollate=<value optimized out>) at P2PDoc.cxx:124
#7 0x00007f3aa8f285cb in main (argc=<value optimized out>,
    argv=<value optimized out>) at pdftopdf.cxx:716

I am on Lucid 64-bit.

Duncan Lock (dunc) wrote :

Doing

dpkg -l cups cups-pdf

gives me:

||/ Name Version Description
+++-==============-==============-============================================
ii cups 1.4.1-5ubuntu2 Common UNIX Printing System(tm) - server
ii cups-pdf 2.5.0-8ubuntu1 PDF printer for CUPS

Oh, I'm also on 64bit, Karmic, btw.

Johann Felix Soden (johfel) wrote :

Thanks, Till Kamppeter, for testing the patch! (Testing is really needed - I have not much experience with poppler).
I found the error: some missing strdup commands. The corrected patch is attached.

The patch works now, thank you.

Changed in cups (Ubuntu):
status: New → In Progress

Committed to Debian/Ubuntu BZR repository of CUPS. Fix will be in the next CUPS package of Lucid.

Changed in cups (Ubuntu):
status: In Progress → Fix Committed
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

Till, I don't see the commit. Did you perhaps forget to push or so?

Changed in pdftk (Ubuntu):
status: Confirmed → Invalid

I have done the push now, this "bzr push" is really my every-time-forgetter.

Johann Felix Soden (johfel) wrote :

Thanks for accepting the patch!

The "bug" with non-conform pdf files in pdftk is still not really solved yet: There should be a clear error message why pdftk fails.

PS: There is a a small mistake in the bzr commit: Duncan Lock found and reported this bug. I am responsible for the patch.

Thanks for your help guys - really appreciated the first class service!! :)

Is there any way to get this updated version of CUPS if I'm running Karmic,
except compiling it myself? Is this likely to get backported, or upstreamed,
or whatnot? Is there anything I can do to help this process?

Thanks,
Dunc

On 23 March 2010 15:22, Johann Felix Soden <email address hidden> wrote:

> Thanks for accepting the patch!
>
> The "bug" with non-conform pdf files in pdftk is still not really solved
> yet: There should be a clear error message why pdftk fails.
>
>
> PS: There is a a small mistake in the bzr commit: Duncan Lock found and
> reported this bug. I am responsible for the patch.
>
> --
> pdftopdf produces non-standard-conform pdf files.
> https://bugs.launchpad.net/bugs/544636
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cups - 1.4.2-10

---------------
cups (1.4.2-10) unstable; urgency=low

  [ Till Kamppeter ]
  * debian/local/filters/pdf-filters/pdftopdf/P2PDoc.cxx: Output of the
    pdftopdf filter was not completely complying with the Adobe specs for PDF.
    Thanks to Duncan Lock for finding and reporting the bug and supplying a
    fix (LP: #544636).

  [ Martin Pitt ]
  * Add no-conffile-timestamp.dpatch: Disable time stamps in conffiles, to
    avoid ever-changing files in /etc. Thanks Joey Hess!
    (Rejected upstream, STR#3067; Closes: #549673)
  * CVE-2010-0393.dpatch: Replace with patch from upstream, and tag
    header. (Closes: #572940)
  * debian/local/filters/pdf-filters/*: Disable call of setErrorFunction() on
    armel for now, since armel's libpoppler is broken. This works around
    #575262, so that cups can finally go into testing again (which is more
    than overdue).

cups (1.4.2-9.1) unstable; urgency=high

  * Non-maintainer upload by the Security Team.
  * Fix loading of localized message string from arbitrary files
    through exporting the LOCALEDIR environment variable when lppasswd
    has a setuid bit set (CVE-2010-0393).
 -- Martin Pitt <email address hidden> Wed, 24 Mar 2010 16:50:56 +0100

Changed in cups (Ubuntu):
status: Fix Committed → Fix Released
Narcis Garcia (narcisgarcia) wrote :

Please, a link or explanation about how to apply the patch to an Ubuntu 9.10 system?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers