pdftopdf filter on PowerPC corrupts data

Till can you have a look at this possible regression?

Matteo, could you run the script referenced here to gather more information? Thanks.
https://wiki.ubuntu.com/PrintingBugInfoScript

Can you start system-config-printer (System -> Administration -> Printing) and inside system-config-printer call Help -> Troubleshoot in the menu? Go throgh the steps of the wizard to do printing tests with appropriate logging and recording of all relevant data. Attach the resulting file to this bug report. Attach also files which failed to get printed.

I had to cancel printing of test pages, because as you can see in the attached log it says there was an ubalanced ">>" at the trailing of input and >7000000 of pages were to be printed. So I stopped that.

The <stdin> job is "man -Tps pthread_create | lpr".

The other job is from trying to print a page in evince.

None of them worked (no pages printed at all).

Can you do the following:

sudo mv /usr/lib/cups/filter/pdftopdf /usr/lib/cups/filter/pdftopdf.orig
sudo cat > /usr/lib/cups/filter/pdftopdf << EOF
cat \$6
EOF
chmod 755 /usr/lib/cups/filter/pdftopdf

This short-circuits the pdftopdf filter (page management filter). Can you try your jobs again now? Can you print correctly now?

Nope, no success. Nothing gets printed.

Can you post the error_log with the short-circuited pdftopdf filter?

Sorry for the delay, the printer was connected to a x86 machine for some time (it has *other* problems with that... like printing for a certain frame of time and then it says the printer is disconnected even if it isn't).

Anyway, I got round to connect the printer back to the PPC machine, and this is the error log.

Is the short-circuited pdftopdf file right to print the six parameter passed?
It says "D [06/Oct/2008:21:06:22 +0200] [Job 40] /usr/lib/cups/filter/pdftopdf: Exec format error"

Just guessing. Thanks!

Sorry, the short-circuit filter was wrong. I have found it out when using it by myself to track down another bug. The right way to create it is

sudo mv /usr/lib/cups/filter/pdftopdf /usr/lib/cups/filter/pdftopdf.orig
sudo cat > /usr/lib/cups/filter/pdftopdf << EOF
#!/bin/sh
cat \$6
EOF
chmod 755 /usr/lib/cups/filter/pdftopdf

The dummy pdftopdf does only use the 6th parameter as input file name (and reads stdin if the 6th parameter does not exist). The first five are ignored, and therefore page management options (like number-up, page-ranges, ...) will not work. This way we can see whether the damage of the PDF data comes from pdftopdf or not.

Please try also to update your system to the current state of Intrepid. Several bugs in the PDF filters got fixed.

Of course, it lacked the shebang! I should have thought about that myself. Anyway, now printing works, so it may very well be due to pdftopdf.

By the way, printing a PDF from evince results in wrong paper margins, but I believe that's the job of pdftopdf, so I guess it is to be expected.

My system is upgraded to all the latest packages (cups is at version 1.3.8-12). I'm attaching error_log just for the sake of completeness.

I got the same problem with a Pixma iP4300, see the bug #286456, my printer stopped working just after update to Intrepid, with a "Specified ColorSpace is not supported" error.

jfyi, problem still present on todays intrepid packages (and maybe duplicate Bug #283605 contains some useful additional information...)

I got the same problem with a Pixma iP1800, my printer stopped working just after update to Intrepid.

Mi problem is solved. It was a cartridge issue. Now mi printer works fine.

I have the same problem, my network printer (Xereox Phaser 8400) stopped working after updating to 8.10 : after an attempted printing, I get the "stopped" message.
the problem is probably due to some filters : I can use "lp" from command line and send pdf or text files to the printer and it works fine. From within cups however, printing test pages get the "stopped" message.

Sorry, I forgot to mention that the workaround "pdftopdf" does not work for me.

bhouchmandzadeh, please check whether your problem is bug 289759 and try the suggested fix (new pstopdf filter) there.

Anyone else, please try this, too.

Alas, I'll have to wait for the cups 1.3.9-2ubuntu1 powerpc build to hit the intrepid-proposed archives before I can test...

after updating cups, still the same issue as I reported in (duplicate) bug #283605

After updating cups, I'm still affected by this issue.
Also, now sending the test page to the printer results in 100% CPU usage until I don't cancel the printing job.

I have just tried printing for the first time since updating to Intrepid.
PowerPc
TiBook G4
Latest Intrepid updates
I get a few lines when trying to print a PDF but no text.
I ran the troubleshooting and here's the output attached.
I'll try the pdftopdf short circuit workaround and see if that helps.
BTW, how to undo the workaround?

Hmmm...tried to run the workaround this way. Is this right? seems weird....
$ sudo mv /usr/lib/cups/filter/pdftopdf /usr/lib/cups/filter/pdftopdf.orig
[sudo] password for brianokeefe:
brianokeefe@ubuntu:/usr/lib/cups/filter$ ls
commandtocanon hplipjs pstopdf rastertogutenprint.5.2
commandtoepson imagetopdf pstops rastertohp
commandtoescpx imagetops pstopxl rastertolabel
commandtopclx imagetoraster pstoqpdl rastertopclx
cpdftocps oopstops pstoraster rastertoqpdl
cupsomatic pdftoijs pstoturboprint rastertoturboprint
foomatic-rip pdftopdf.orig rastertodymo textonly
gziptoany pdftops rastertoepson texttopdf
hpgltops pdftoraster rastertoescpx texttops
brianokeefe@ubuntu:/usr/lib/cups/filter$ sudo cat > /usr/lib/cups/filter/pdftopdf << EOF
>
> #!/bin/sh
> cat \$6
> EOF
bash: /usr/lib/cups/filter/pdftopdf: Permission denied
brianokeefe@ubuntu:/usr/lib/cups/filter$ sudo cat > /usr/lib/cups/filter/pdftopdf << EOF
> #!/bin/sh
> cat \$6
> sudo EOF
> chmod 755 /usr/lib/cups/filter/pdftopdf
>
>
brianokeefe@ubuntu:/usr/lib/cups/filter$ ls
commandtocanon hplipjs pstopdf rastertogutenprint.5.2
commandtoepson imagetopdf pstops rastertohp
commandtoescpx imagetops pstopxl rastertolabel
commandtopclx imagetoraster pstoqpdl rastertopclx
cpdftocps oopstops pstoraster rastertoqpdl
cupsomatic pdftoijs pstoturboprint rastertoturboprint
foomatic-rip pdftopdf.orig rastertodymo textonly
gziptoany pdftops rastertoepson texttopdf
hpgltops pdftoraster rastertoescpx texttops

the short circuit got a complaint from test page printing that the pdftopdf file didn't exist. I moved the file back and the test page printed all of the color but no text on the page. PDF's did the same as before-a few lines but no text.

The short-circuit filter did not get created for you. Do the following commands:

sudo -s
mv /usr/lib/cups/filter/pdftopdf /usr/lib/cups/filter/pdftopdf.orig
cat > /usr/lib/cups/filter/pdftopdf << EOF
#!/bin/sh
cat \$6
EOF
chmod 755 /usr/lib/cups/filter/pdftopdf
exit

Note that all commands between "sudo -s" and "exit" are executed as root (you have a prompt ending with "#").

Does your printing work correctly now?

If you get the same broken results as before after doing my pdftopdf short circuit, do not undo the short circuit for the following test. Otherwise, undo it with

sudo mv /usr/lib/cups/filter/pdftopdf.orig /usr/lib/cups/filter/pdftopdf

It looks like that one of the filter produces broken PDF and the next filter (most probably cpdtocps which calls pdftops which in turn calls /usr/bin/pdftops and that one uses libpoppler as the PDF renderer). The errors and warnings in the error log show that libpoppler is complaining and not Ghostscript (Linux has two PDF renderers: libpoppler and Ghostscript).

Let us run the filter chain stopping one step before cpdftocps:

cupsfilter -m application/vnd.cups-pdf -p /etc/cups/ppd/<yourbrokenqueue>.ppd > output.pdf 2> error_log.txt

Attach the two output files output.pdf and error_log.txt to this bug report.

Does error_log.txt contain warnings or errors? Does output.pdf get created and is it not empty?

Try to display output.pdf on the screen. Start with evince. Is it correctly displayed? Or does it show artifacts similar to your printouts?

Try to display it with Ghostscript by running

gs output.pdf

Does this work better? Or does it show the same problems?

Try also

cupsfilter -m application/pdf -p /etc/cups/ppd/<yourbrokenqueue>.ppd > output2.pdf 2> error_log2.txt

This leaves out the pdftopdf filter (so doing this test makes only sense if you did not short-circuit pdftopdf). Do the same steps as described above with the output files.

Try finally

cupsfilter -m application/vnd.cups-postscript -p /etc/cups/ppd/<yourbrokenqueue>.ppd > output3.ps 2> error_log3.txt

This adds the execution of cpdftocps. Proceed with the output files as described above. For screen-displaying the output, use only Ghostscript:

gs output3.ps

Does this file display correctly?

Thanks Till! The short-circuit filter got created and printing is working. Good job.
(now to figure out why my key-mapping got screwed up...)

Great. Thank you.

So undo the short-circuit and do the tests of my last posting.

I will do that but I have a question. Do I need to re-do the short circuit to print again?
Here's what happened with the tests:
None of the error_log.txt contain anything.
The output.pdf and output3.pd fwill not open at all with any viewer.
root@ubuntu:~/Desktop# gs output.pdf
GPL Ghostscript 8.63 (2008-08-01)
Copyright (C) 2008 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /undefined in Usage:
Operand stack:

Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
   --dict:1148/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)--
Current allocation mode is local
Current file position is 7
GPL Ghostscript 8.63: Unrecoverable error, exit code 1

root@ubuntu:~/Desktop# gs output3.ps
GPL Ghostscript 8.63 (2008-08-01)
Copyright (C) 2008 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /undefined in Usage:
Operand stack:

Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
   --dict:1148/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)--
Current allocation mode is local
Current file position is 7
GPL Ghostscript 8.63: Unrecoverable error, exit code 1

Sorry, I have given you the wrong cupsfilter command lines, so do exactly the following:

Undo the short circuit for the following test doing

sudo mv /usr/lib/cups/filter/pdftopdf.orig /usr/lib/cups/filter/pdftopdf

It looks like that one of the filter produces broken PDF and the next filter (most probably cpdtocps which calls pdftops which in turn calls /usr/bin/pdftops and that one uses libpoppler as the PDF renderer). The errors and warnings in the error log show that libpoppler is complaining and not Ghostscript (Linux has two PDF renderers: libpoppler and Ghostscript).

Let us run the filter chain stopping one step before cpdftocps:

cupsfilter -m application/vnd.cups-pdf -p /etc/cups/ppd/<yourbrokenqueue>.ppd /usr/share/cups/data/testprint.ps > output.pdf 2> error_log.txt

Attach the two output files output.pdf and error_log.txt to this bug report.

Does error_log.txt contain warnings or errors? Does output.pdf get created and is it not empty?

Try to display output.pdf on the screen. Start with evince. Is it correctly displayed? Or does it show artifacts similar to your printouts?

Try to display it with Ghostscript by running

gs output.pdf

Does this work better? Or does it show the same problems?

Try also

cupsfilter -m application/pdf -p /etc/cups/ppd/<yourbrokenqueue>.ppd /usr/share/cups/data/testprint.ps > output2.pdf 2> error_log2.txt

This leaves out the pdftopdf filter (so doing this test makes only sense if you did not short-circuit pdftopdf). Do the same steps as described above with the output files.

Try finally

cupsfilter -m application/vnd.cups-postscript -p /etc/cups/ppd/<yourbrokenqueue>.ppd /usr/share/cups/data/testprint.ps > output3.ps 2> error_log3.txt

This adds the execution of cpdftocps. Proceed with the output files as described above. For screen-displaying the output, use only Ghostscript:

gs output3.ps

Does this file display correctly?

Note that instead of /usr/share/cups/data/testprint.ps you can also use any other PostScript or PDF file, but use the same file for all tests.

Please attach all output* and error_log* files, also if you cannot display the files with Ghostscript and/or evince.

Note that after having done the tests you have to apply the short-circuit workaround again in order to be able to print.

bhouchmandzadeh. did you try my workaround from bug 289759, as I asked you for?

Your problem is not the same as the problem which is subject of this bug. Please open a new bug report. Please tell there also which printer and driver you are using, what is your system architecture and which files/from which applications you tried to print.

Can you start system-config-printer (System -> Administration -> Printing) and inside system-config-printer call Help -> Troubleshoot in the menu? Go through the steps of the wizard to do printing tests with appropriate logging and recording of all relevant data. Attach the resulting file to your new bug report. Attach also files which failed to get printed.

I have informed the upstream author about the PowerPC problem with pdftopdf.

Hello till. I was unavailable for a few days but I have run the tests and the test files are attached.

"Sorry, I have given you the wrong cupsfilter command lines, so do exactly the following:

Undo the short circuit for the following test doing

sudo mv /usr/lib/cups/filter/pdftopdf.orig /usr/lib/cups/filter/pdftopdf

It looks like that one of the filter produces broken PDF and the next filter (most probably cpdtocps which calls pdftops which in turn calls /usr/bin/pdftops and that one uses libpoppler as the PDF renderer). The errors and warnings in the error log show that libpoppler is complaining and not Ghostscript (Linux has two PDF renderers: libpoppler and Ghostscript).

Let us run the filter chain stopping one step before cpdftocps:

cupsfilter -m application/vnd.cups-pdf -p /etc/cups/ppd/<yourbrokenqueue>.ppd /usr/share/cups/data/testprint.ps > output.pdf 2> error_log.txt

Attach the two output files output.pdf and error_log.txt to this bug report.

Does error_log.txt contain warnings or errors? Does output.pdf get created and is it not empty?"

No errors in the log file.

Try to display output.pdf on the screen. Start with evince. Is it correctly displayed? Or does it show artifacts similar to your printouts?"

No text displayed in Evince or XPDF as in the later pdf's from the tests below.

"Try to display it with Ghostscript by running

gs output.pdf

Does this work better? Or does it show the same problems?"
GS crashes immediately.

"Try also

cupsfilter -m application/pdf -p /etc/cups/ppd/<yourbrokenqueue>.ppd /usr/share/cups/data/testprint.ps > output2.pdf 2> error_log2.txt

This leaves out the pdftopdf filter (so doing this test makes only sense if you did not short-circuit pdftopdf). Do the same steps as described above with the output files."

GS displays pdf perfectly, text and all. No errors in log.

"Try finally

cupsfilter -m application/vnd.cups-postscript -p /etc/cups/ppd/<yourbrokenqueue>.ppd /usr/share/cups/data/testprint.ps > output3.ps 2> error_log3.txt

This adds the execution of cpdftocps. Proceed with the output files as described above. For screen-displaying the output, use only Ghostscript:

gs output3.ps

Does this file display correctly?"
GS displays large image that I cannot resize or alter but the tiny bit I can see displays well.

"Note that instead of /usr/share/cups/data/testprint.ps you can also use any other PostScript or PDF file, but use the same file for all tests.

Please attach all output* and error_log* files, also if you cannot display the files with Ghostscript and/or evince."

BTW, Kghostview displays output3.ps well but there is no text.

Brian, thank you for doing the tests,

This shows exactly, that pdftopdf is corrupting the data. As soon as the data passes pdftopdf, the text cannot be displayed any more, and some PDF renderers (Ghostscript, Adobe Reader) even crash. Only Poppler succeeds to render these broken PDF files. Note that evince and the pdftops CUPS filter (which is used by cpdftocps) are Poppler-based.

I had exactly this problem (no real printing after intrepid upgrade on PPC) and this solution (replacing pdftopdf with the simple short-circuit filtere, above) worked great for me.

Thanks very much!

I have got a fix from upstream now and applied it to the Debian BZR repository of CUPS. A fixed package for Jaunty will come soon.

This bug was fixed in the package cups - 1.3.9-8

---------------
cups (1.3.9-8) experimental; urgency=low

  * debian/local/filters/pdf-filters/pdftopdf/P2POutputStream.cxx,
    debian/local/filters/pdf-filters/pdftopdf/P2POutputStream.h: Removed
    an endianess dependency from the pdftopdf filter, so that it also
    works on non-PC platforms like PowerPC (LP: #271350).
  * debian/filters/pstopdf: Do not supply the margins from the PPD to the
    ps2pdf process, as this breaks full-bleed printing and is also disturbs
    the printing if PPDs have too conservative margin definitions (LP: #282186).

 -- Martin Pitt <email address hidden> Wed, 26 Nov 2008 15:14:57 +0100

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Will this repository work for PPC? Aren't the PPC reps "port" not "archive"?
deb http://archive.ubuntu.com/ubuntu/ intrepid-proposed restricted main multiverse universe

Right, they are on ports:

deb http://ports.ubuntu.com/ intrepid-proposed main restricted

Fixed for me in Jaunty. Thanks!

I have libcups2-dev 1.3.9-2 and libcupsys-dev 1.3.9-2 after enabling the proposed repository. I didn't upgrade them yet just in case....

Brian O'Keefe, you MUST update after enabling the proposed repository, only the enabling does not change anything. Your update will bring you to cups 1.3.9-2ubuntu4. Please do the update and tell us whether the problem goes away.

Just to clarify, am I just updating the cups package and not libcups or other cups libraries or packages? It seems as if many others would be removed in any case, like Ubuntu-desktop for some updates.
thanks

You only need to update the CUPS packages. It would probably already be enough only to update the package named "cups" as it contains the pdftopdf filter, but probably you have to updater also other dependent packages.

Try

sudo apt-get update
sudo apt-get install cups

This should pull all needed dependencies.

This bug was found in the Intrepid development cycle; removing regression-potential and marking as regression-release.

As for regression testing, the current version still works fine on i386. I printed out several PDFs and HTML pages, some with 4-on-1.

This bug was fixed in the package cups - 1.3.9-2ubuntu4

---------------
cups (1.3.9-2ubuntu4) intrepid-proposed; urgency=low

  * debian/local/filters/pdf-filters/pdftopdf/P2POutputStream.cxx,
    debian/local/filters/pdf-filters/pdftopdf/P2POutputStream.h: Removed
    an endianess dependency from the pdftopdf filter, so that it also
    works on non-PC platforms like PowerPC (LP: #271350).

 -- Till Kamppeter <email address hidden> Sun, 23 Nov 2008 22:04:55 +0100

I undid the short circuit, installed the cups upgrade and could print nothing either as a PDF or from OpenOffice. I upgraded all of the cups packages that the Intrepid-proposed repository had available and tried again-just blank pages. I reapplied the short circuit and I have printing again.
I can re-run the tests or others that you may suggest.

Matteo, you said that it worked for you in Jaunty? Till, maybe the backport was not complete, and 1.3.9 fixed some other things?

pitti, I have checked the source of the -proposed package (1.3.9-2ubuntu5) and the fix from Koji Otani for the Endianess is really applied.

Brian O'Keefe, Are you sure that the new filter is installed? Cab you do

dpkg -l cups

Version must be 1.3.9-2ubuntu4 or 1.3.9-2ubuntu5.

Here you go Till:
~$ dpkg -l cups
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii cups 1.3.9-2ubuntu4 Common UNIX Printing System(tm) - server

I reinstalled and here's the terminal output. Anything in here, like the ERROR, important?

Preparing to replace cups 1.3.9-2ubuntu4 (using .../cups_1.3.9-2ubuntu4_powerpc.deb) ...
 * Stopping Common Unix Printing System: cupsd [ OK ]
Restarting Xprint server(s): Xprt.
Stopping Xprint servers: Xprt.
Starting Xprint servers: Xprt.
/etc/init.d/xprint: ## ERROR: Can't find "/usr/X11R6/bin/Xprt".
Unpacking replacement cups ...
Processing triggers for doc-base ...
Processing 1 changed doc-base file(s)...
Registering documents with dwww...
Registering documents with scrollkeeper...
Processing triggers for man-db ...
Processing triggers for ufw ...
WARN: uid is 0 but '/' is owned by 501
Setting up cups (1.3.9-2ubuntu4) ...
$Loading AppArmor module: Failed.
invoke-rc.d: initscript apparmor, action "force-reload" failed.
 * Starting Common Unix Printing System: cupsd [ OK ]
Restarting Xprint server(s): Xprt.
Stopping Xprint servers: Xprt.
Starting Xprint servers: Xprt.
/etc/init.d/xprint: ## ERROR: Can't find "/usr/X11R6/bin/Xprt".

@Martin: confirming it's fixed for me in Jaunty.

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the
report. The bug has been fixed in newer releases of Ubuntu.