Ubuntu port of acroread degrades images (works on Win7)

jimav, thank you for reporting this and helping make Ubuntu better. We would want to investigate any possible printing issue(s) with cups first before claiming Adobe Reader has some discrepancy between OSs. Please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 997728
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.
As well, could you please attach all relevant information from https://wiki.ubuntu.com/DebuggingPrintingProblems ?

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Ok I ran the apport-collect command. Incidentally, I -did- use ubuntu-bug to file the bug report; don't know why it looks otherwise.

The printer is a postscript (level 2 only) printer. So CUPS should not be doing anything significant to a PDF file, should it?

Attached is information from https://wiki.ubuntu.com/DebuggingPrintingProblems, as requested.

NOTE: If the PDF file (attached to comment #1) is printed directly with
   lpr AcrobatTestImage.pdf
then it prints fine. But if that file is opened with acroread and printed from acroread, it is degraded.

If CUPS is the culprit, then acroread must be either using a different API than the 'lpr' command, or else it is sending different bits than are in the .pdf file.

Attaching /var/log/cups/error_log immediately after running

$ cupsctl LogLevel=debug
$ acroread AcrobatTestImage.pdf
(printing from acroread)

jimav, does anything change if you print from acroread in a Live CD of Precise http://www.ubuntu.com/download/desktop ?

Hmm. There is no acroread command and "sudo apt-get install acroread" says there is no such package.

I am running the Xubuntu 64-bit 12.04 Desktop system in a VM. Don't know if it exists for 32-bit, but that's not very relevant.

I just needed to enable the correct repository. Sorry for the false alarm.

Anyway, Ubuntu 12.04 is same as before - degraded images when printing thru acroread

The problem is most probably caused by switching the pdftops CUPS filter from Poppler to Ghostscript and allowing higher image rendering resolutions when the pdftops filter has to turn graphical structures of the PDF input file into bitmaps when converting to PostScript and PostScript does not support these structures.

I have uploaded a cups-filters package to precise-proposed now which switches back to Poppler and limits the image rendering resolution to 360 dpi. Please test the package as soon as it gets available for download and give feedback here. This is required to make the new package an official update for Precise. Another comment with testing instructions will get posted here.

With the new package you can also test the behavior when switching between use of Poppler and Ghostscript and changing the resolution limit. Run the following commands in a terminal window for switching between Ghostscript and Poppler:

lpadmin -p <printer> -o pdftops-renderer-default=gs
lpadmin -p <printer> -o pdftops-renderer-default=pdftops

and

lpadmin -p printer -R pdftops-renderer-default

to remove the setting. To change the resolution limit run a command like

lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440

and set unlimited resolution via

lpadmin -p <printer> -o pdftops-max-image-resolution-default=0

or remove your setting with

lpadmin -p <printer> -R pdftops-max-image-resolution-default

Always replace "<printer>" by your printer's queue name (enter "lpstat -v" to find your printer's queue name).

See also

/usr/share/doc/cups-filters/README.txt.gz

See and tell us in this bug report which works best for you.

A debdiff of the changes is attached.

The problem is most probably caused by switching the pdftops CUPS filter from Poppler to Ghostscript and allowing higher image rendering resolutions when the pdftops filter has to turn graphical structures of the PDF input file into bitmaps when converting to PostScript and PostScript does not support these structures.

I have uploaded a cups-filters package to precise-proposed now which switches back to Poppler and limits the image rendering resolution to 360 dpi. Please test the package as soon as it gets available for download and give feedback here. This is required to make the new package an official update for Precise. Another comment with testing instructions will get posted here.

With the new package you can also test the behavior when switching between use of Poppler and Ghostscript and changing the resolution limit. Run the following commands in a terminal window for switching between Ghostscript and Poppler:

lpadmin -p <printer> -o pdftops-renderer-default=gs
lpadmin -p <printer> -o pdftops-renderer-default=pdftops

and

lpadmin -p printer -R pdftops-renderer-default

to remove the setting. To change the resolution limit run a command like

lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440

and set unlimited resolution via

lpadmin -p <printer> -o pdftops-max-image-resolution-default=0

or remove your setting with

lpadmin -p <printer> -R pdftops-max-image-resolution-default

Always replace "<printer>" by your printer's queue name (enter "lpstat -v" to find your printer's queue name).

See also

/usr/share/doc/cups-filters/README.txt.gz

See and tell us in this bug report which works best for you.

A debdiff of the changes is attached.

To the SRU team: The relevant changes for the fix are in the file filter/pdftops.c. The file in the debdiff looks very cluttered as there are many lines where only white space (indentation) changed. Attached to this comment is a cleaner diff for this file with white space changes ignored (diff -b), here one especially sees how the conditional compiling for Ghostscript/Poppler is replaced by "if"s so that the Ghostscript/Poppler decision can be made at run time.

Questions:

1. Why does acroread end up using a different pdf->ps filter than lpr/CUPS?

2. Since they apparently use different filters, how will changing CUPS resolve this problem?
(lpr/CUPS already produces better output than acroread)

The PDF->PS filter I am talking about is not part of Adobe Reader but of the CUPS filters. Many people have problems when printing on their PostScript printers since the update to 12.04. Therefore I have done some fixes/improvements, especially to go back to 11.10 state as default, and I am simply trying to find out whether it solves the problems which the users report. Adobe Reader did not change AFAIK.

So please try out the fixed package as soon as it gets available and if it does not help, we need to investigate further.

That sounds like an unrelated problem to this bug report.

But ifit is related (as it might be), it would be good to understand why acroread exhibits bad behavior but lpr does not. In other words, if the CUPS filters are the root of the problem with acroread, then just fixing the CUPS filters will leave undiagnosed why 'lpr' was not affected but acroread was.

Hello jimav, or anyone else affected,

Accepted cups-filters into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

New cups-filters does NOT fix the problem. Images are still degraded when printing via acroread, but not degraded using lpr.

(Tested cups-filters 1.0.18-0ubuntu0.1 and acroread 9.4.7-1oneiric1 on Xubuntu 12.04)

This isn't very surprising, since the old cups-filters did not show the problem either when using lpr. The evidence STRONGLY points to something in acroread specifically, since both acroread and lpr presumably use the same CUPS printing back-end.

This looks much like that the data coming from acroread is already bad quality.

Sorry, I have overlooked the special case for acroread. acroread sends jobs in PostScript format AFAIK and due to DRM (Digital Rights Management) problems we do not convert this PostScript into PDF, regardless whether the printer is a PostScript printer or not. So only the pstops CUPS filter will be called. And this means that no graphical elements of the original input are turned into bitmaps (rasterized) and so if some parts of the printed output are bad quality, this bad quality must come already for the input.

So I fear we are hitting a bug in the Adobe Reader (acroread) here.

Moved bug to acroread package. As this software is closed-source it will be most probably an upstream bug which can only be fixed by Adobe. Please correct the bug tasks appropriately, report the problem to Adobe, and close the acroread task if appropriate.

jimav, please execute the following via the Terminal:
apport-collect -p acroread 997728

apport information

jimav, as per your apport data you are using an old version of acroread. If you update it to the newest (9.5.1-1oneiric1), does it improve the print quality?

On 05/23/2012 03:57 PM, Christopher M. Penalver wrote:
> jimav, as per your apport data you are using an old version of acroread.
> If you update it to the newest (9.5.1-1oneiric1), does it improve the
> print quality?

Christopher,
How do I get that updated version of acroread? The 'newest' version in
the repos seems to be 9.4.7-1oneiric

  Here's what I see:

$ sudo apt-get -qq update
$ sudo apt-get install acroread
acroread is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$ dpkg-query -l acroread
ii acroread 9.4.7-1oneiric Adobe Reader

Here is what is in my /etc/apt/sources.list (note -proposed at the end):

deb http://us.archive.ubuntu.com/ubuntu/ precise main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ precise main restricted

deb http://us.archive.ubuntu.com/ubuntu/ precise-updates main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ precise-updates main restricted

deb http://us.archive.ubuntu.com/ubuntu/ precise universe
deb-src http://us.archive.ubuntu.com/ubuntu/ precise universe
deb http://us.archive.ubuntu.com/ubuntu/ precise-updates universe
deb-src http://us.archive.ubuntu.com/ubuntu/ precise-updates universe

deb http://us.archive.ubuntu.com/ubuntu/ precise multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ precise multiverse
deb http://us.archive.ubuntu.com/ubuntu/ precise-updates multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ precise-updates multiverse

deb http://us.archive.ubuntu.com/ubuntu/ precise-backports main
restricted universe multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ precise-backports main
restricted universe multiverse

deb http://security.ubuntu.com/ubuntu precise-security main restricted
deb-src http://security.ubuntu.com/ubuntu precise-security main restricted
deb http://security.ubuntu.com/ubuntu precise-security universe
deb-src http://security.ubuntu.com/ubuntu precise-security universe
deb http://security.ubuntu.com/ubuntu precise-security multiverse
deb-src http://security.ubuntu.com/ubuntu precise-security multiverse

deb http://archive.canonical.com/ubuntu precise partner
deb-src http://archive.canonical.com/ubuntu precise partner

deb http://extras.ubuntu.com/ubuntu precise main
deb-src http://extras.ubuntu.com/ubuntu precise main

deb http://archive.ubuntu.com/ubuntu/ precise-proposed restricted main
multiverse universe

-Jim

jimav, ah I noticed that you have the Oneiric version of acroread but your using Precise. Try the following via the Terminal:
sudo apt-get -y remove acroread && sudo apt-get update && sudo apt-get -y dist-upgrade && sudo apt-get -y install acroread

That should install the newest acroread for Precise (9.5.1).

Christopher,
I did all that and still get acroread 9.4.7-1oneiric1.

Where are you getting the newer version from? Could you check
/etc/apt/sources.list (and sources.list.d/) on your system to see if you
are pulling from a non-standard repo? Also, are you running a 64-bit
system (maybe it only exists for 32bit...?)

I don't understand repo layouts, but the following looks suspicious:

http://archive.canonical.com/dists/precise/partner/binary-amd64/Packages.bz2
    lists acroread 9.4.7-1oneiric1

http://archive.canonical.com/dists/precise-updates/partner/binary-amd64/Packages.bz2
http://archive.canonical.com/dists/precise-proposed/partner/binary-amd64/Packages.bz2
    both empty

jimav, please ping the acroread maintainer or ask a question about it via:
https://answers.launchpad.net/ubuntu/+source/acroread/+addquestion

lsb_release -rd
Description: Ubuntu 12.04 LTS
Release: 12.04

apt-cache policy acroread
acroread:
  Installed: 9.5.1-1precise1
  Candidate: 9.5.1-1precise1
  Version table:
 *** 9.5.1-1precise1 0
        500 http://archive.canonical.com/ubuntu/ precise/partner i386 Packages
        100 /var/lib/dpkg/status

This bug was fixed in the package cups-filters - 1.0.18-0ubuntu0.1

---------------
cups-filters (1.0.18-0ubuntu0.1) precise-proposed; urgency=low

  [ Till Kamppeter ]
  * New upstream release
     - pdftops: Allow selection whether Ghostscript or Poppler is used
       at runtime, setting the "pdftops-renderer" option to "gs" or
       "pdftops". This way one can switch to Poppler per-queue if there
       are incompatibilities with certain PostScript printers.
     - pdftops: Allow setting an upper limit for the image rendering
       resolution, also at runtime, setting the option
       "pdftops-max-image-resolution-default" to the desired limit in dpi.
       "0" means no limit.
     - pdftops: Fixed crash by wrong usage of sizeof() function when adding
       "Collate" to the fifth command line argument for the "pstops" CUPS
       filter call (LP: #982675).
     - pdftops: Removed newline from copies value when reading it from
       the "%%PDFTOPDFNumCopies" entry of the incoming PDF file.
     - pdftops: Silenced compiler warning about ignoring the return
       value of the write() function.
     - pdftops: Added a crash guard.
     - pdftops: Start determining the printing resolution with
       cupsRasterInterpretPPD(), this is the most reliable as often
       the choice names of the "Resolution" option are marketing names
       with higher numerical values than the actual resolution. Also
       ignore error exit values of cupsRasterInterpretPPD() as the
       function can error out after having found the resolution
       (LP: #984082).
     - pdftops: If printing resolution is determined by
       cupsRasterInterpretPPD() do not stick on 100 dpi if the
       resolution cannot be determined (LP: #984082).
  * debian/rules: Set default renderer for the pdftops filter to Poppler
    due to many printer's buggy interpreters having problems with GhostScript's
    PostScript and set image rendering resolution limit of the pdftops filter
    to 360 dpi to prevents slow processing by the printer if very high
    resolutions are used or if the printing resolution is mis-detected by the
    pdftops filter (LP: #668800, LP #951627 (comment #30), LP: #998087,
    LP: #992982 (comments #26, #27, #30, #31), LP: #997728, LP: #994477,
    LP: #998087, LP: #978120, LP: #862167).

  [ Didier Raboud ]
  * Drop libtiff5-dev, just use libtiff-dev, this fixes the FTBFS due to
    incompatibility with cups.
 -- Till Kamppeter <email address hidden> Wed, 16 May 2012 11:25:03 +0200

As told earlier, bug is in Adobe Reader.

Hi, a new acroread release (0.9.4) is available for update, could you give it a try and tell us if the problem persists?
If you still have this bug please set back the status to "new"
thanks

[Expired for acroread (Ubuntu Precise) because there has been no activity for 60 days.]

[Expired for acroread (Ubuntu) because there has been no activity for 60 days.]