Evince produces low-res, pixelated output when printing PDF's

Since posting the bug I have started getting the same problem when printing from Firefox and Openoffice, so it's clearly not a problem with evince. It is, however, a big problem here on my Dell Latitude D620 to not be able to print reliably. The printer I'm using is a Brother MFC-J615W with Brother's drivers installed and previously working fine. Really need a fix or workaround as I depend on this computer.

Same (type of) problem for me. I had a Brother MFC-9465CDN with Brother's drivers installed. Everything perfect in Oneiric. Since upgrade (and also fresh reinstall from scratch) to Precise, I get awfull pixelized printing from (particulary):

- openoffice
- konqueror
- kate/kwrite

Strange thing: if I print some text from openoffice, the result is unusable. If I print to file (pdf) and then print the pdf (from acrobat reader or okular), the result is OK.

I'ts really a big issue...

Best regards

Olivier Subilia

Status changed to 'Confirmed' because the bug affects multiple users.

Can everyone with the problem

1. Follow the instructions of the sections "CUPS error_log" and "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems for each application which shows the problem?

2. install the cups-pdf package and print the same files from the dame applications to the PDF printer and tell whether they come out correctly? cups-pdf drops PDF files in ~/PDF/.

Hi,
I was trying to pritnt a pdf file and I got same bad results in case of using both "Document viewer" & "Google chrome"

I attached the error log resulting from following instructions in section 1.

By following the instructions in section 2 I always get bad printed results in all cases although the "printout" pdf file looks OK when opening it and contains no problems.

I attached the original file "original" and the "printout" files.

I was trying to print page 36 in the original file.

Capture data:

a) openoffice.
Stop printer and print text. Output document in Cups queue is perfect (pdf data). When I restart the printer, the document is printed awfully. The problem seems to come with cups and not with openoffice

b) cups-pdf.
output document in ~/PDF is perfect. Printing this PDF gives a correct document (as always).

A workaround for the problem could then be:
- to always print with cups-pdf;
- to write a script something like

#!/bin/bash
for rep in `ls /home`;do
prep=/home/$rep/PDF
if [[ -d $prep ]];then
for file in `ls $prep`;do
lp "$prep/$file" && rm "$prep/$file"
done
fi
done

and to put this file in /etc/cron.d to have it run every minute.

But it's a bit dirty...

Best regards

Olivier Subilia

Okay, I have added debug log data for a job printed from Evince. Short on time, but I verified that Evince and Firefox are sending good data to cups when the printouts look bad. I've attached examples from Evince of an original PDF, the ~/printout file retrieved from the spool, and the output of cups-pdf, as well as the error log from the last print job and scan of the results.

In contrast Olivier's experience, in my case cups-pdf is also producing bad output.

Sorry, forgot to add the cups-pdf output file. Here it is.

I had the same behaviour - printing from pdf files was at 100 dpi. In the cups error.log there was a "Using image rendering resolution 100 dpi" information. I found on pdftops sources that 2012-04-10 in change #6926 there was a change for setting a resolution setup in ppd options ('Resolution', 'DefaultResolution'). But my ppd doesn't contains such options.

I found a workaround for my system. I have brother DCPJ315W printer and in original ppd file I have such similar options:

*%==== Resolution Features =================================
*OpenUI *BRResolution/Quality: PickOne
*OrderDependency: 14 AnySetup *BRResolution
*DefaultBRResolution: 600x600dpi
*BRResolution 150x150dpi/Fast: " "
*BRResolution 300x300dpi/Fast Normal: " "
*BRResolution 600x600dpi/Normal: " "
*BRResolution 1200x1200dpi/Fine: " "
*BRResolution 1200x2400dpi/Photo: " "
*BRResolution 1200x6000dpi/Highest: " "
*CloseUI: *BRResolution

I added similar options before this one:

*%==== Resolution auto Features =================================
*OpenUI *Resolution/Quality Auto: PickOne
*OrderDependency: 14 AnySetup *Resolution
*DefaultResolution: 600x600
*Resolution 150x150/Fast: " "
*Resolution 300x300/Fast Normal: " "
*Resolution 600x600/Normal: " "
*Resolution 1200x1200/Fine: " "
*Resolution 1200x2400/Photo: " "
*Resolution 1200x6000/Highest: " "
*CloseUI: *Resolution

Now I have two options in printer preferences: 'auto' for setting pdftops and original BRResolution for Brother's filters.

That workaround worked for me, too, printing to a Brother MFC-J615W. It would be even cooler if I wasn't too much of a newbie to understand *why* it worked.

That workaround worked also for me. Using "Resolution" instead of "BRResolution" does the job properly.

So now, who doesn't understand who ? Is it a problem of Cups ? of the Brother Driver (same before and after upgrade to Precise) ?

Best regards

Olivier Subilia

I have similar problems with my Brother HL3040CN printer. Took a Libre Office document and exported as pdf. Printing pdf file from evince generates text at about 100dpi. Printing to HP F2180 is OK. Printing direct from Libre Office to Brother HL3040CN was OK.

Similar problem with my Brother HL-4150CDN, I posted an unsuccesful askubuntu question here http://askubuntu.com/questions/132353/brother-hl-4150cdn-prints-text-with-wrong-resolution-on-ubuntu-12-04-where-can ;

I can confirm that some fonts actually print with 100 dpi resolution.

pdftops must be the component to blame.

I have found out what is happening here: The pdftops filter is not able to find out what the printing resolution for this job is, due to no "Resolution" option in the PPD and also no PostScript commands for setting the device resolution in any other options in the PPD. This leads to the wrong assumtion of a 100-dpi resolution. I have done an upstream change now to make the fallback in such a situation being 300 dpi, as it was originally intended.

This will soon be made available as an update, after checking whether there are perhaps other bugs to fix in the cups-filters package.

Your solution to setup 300dpi in case there is no "Resolution" option could be not the best one - users with such PPD files will be not able to print in different resolution. Is it possible to not setup resolution at all if there is no "Resolution" option?

Pawel, this resolution entry is used if Ghostscript has to turn graphical content of the PDF into a bitmap if PostScript does not support this type of graphical content, especially transparency. A bitmap always needs a resolution, also if the source data is entirely vector graphics. If the resolution is not specified Ghostscript uses 720 dpi and Poppler (/usr/bin/pdftops) uses 300 dpi, which caused the slower rendering of Ghostscript's output in a PostScript printer (http://bugs.ghostscript.com/show_bug.cgi?id=693016). Also the mismatch of the resolution raster, as 720 dpi on a printer with 300/600/1200 dpi, can cause slow rendering of a bitmap in the printer.

To overcome these problems I have introduced to specify the resolution and for that choosing the one fitting best to the job, usually taking the setting of the "Resolution" option. Unfortunately, there are PPD files without "Resolution" option or choice names do not tell about the actually used resolution, some have marketing-designed choice names with numbers much higher than the actually used resolution. If there is no "Resolution" option I have used CUPS library functions to analyse the PostScript code in the PPD to discover which resolution is actually used.

Now I have changed the code to start with analysing the PostScript in the PPD and falling back to the choice names of the "Resolution" option if the PostScript does not deliver anything useful. This I will soon make available as an update.

In any case, if there is no hint to the resolution used for printing a job we fall back to 300 dpi, as this works with most PostScript (laser) printers and output quality is not behind Poppler.

Confirming identical behaviour with a Brother MFC-J6710DW. It printed perfectly under Oneric, but reverts to mostly but not uniformly low-resolution after a clean Precise install. Pawel's workaround edit of the PPD file has temporally solved the issue.

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

---------------
cups-filters (1.0.18-1) unstable; urgency=low

  * 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. Default limit is 1440 dpi. This prevents slow
       processing by the printer if very high resolutions are used or
       if the printing resolution is mis-detected by the pdftops filter.
     - 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.
     - pdftops: If printing resolution is determined by
       cupsRasterInterpretPPD() do not stick on 100 dpi if the
       resolution cannot be determined (LP: #984082).
     - pdftopdf: Fixed segmentation fault when printing selected pages
       ("page-ranges" option, LP: #980673).
 -- Martin Pitt <email address hidden> Wed, 16 May 2012 11:45:03 +0200

I have uploaded a fixed cups-filters package to precise-proposed now. 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 for turning PDF to PosdtScript and changing the resolution limit for image rendering. Especially if the output quality with the new package is still not satisfying you should do the tests and tell here in the bug report which is the best compromise between speed and quality.

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 (in dpi, current setting is 360) 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.

Hello Till, I'm sorry if my English is not as good as I would.

I had the same problem with an Brother HL-4150CDN with 12.04 version but I've solved (provisional) by changing the driver (HL-4150CDN for CUPS) for another (HL-4050-CDN) that had a problem in previous versions (with the same printer) but now it works perfectly.

I found the HL4150CDN driver at http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_prn.html and it worked fine from 10.?? to 11.10 versions but no with 12.04.

Perhaps this information wuld be useful for you.

Hello Anthony, 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!

Added precise-proposed as a software source and updated system. Printed from PDF files to Brother HL-3040CN printer - resolution now as expected. Great result. Thanks. Will there be advice of when patch is accepted into precise libraries?

Michael

Thank you very much. I have marked the bug as verified now.

Found this thread while my Brother DCP-9055CDN has the same problem.

Just updated to cups-filters 1.0.18 (proposed) and it prints fine now! Thanks!

Not yet had the time to check, sorry (you know, it's all about this crazy little thing called work). But I'll do it ASAP.

@ Till: just to be sure to have understood correctly. When you write in the diff:

        - 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.
      - pdftops: If printing resolution is determined by
        cupsRasterInterpretPPD() do not stick on 100 dpi if the
        resolution cannot be determined (LP: #984082).

Does it means that it will understand that BRResolution means Resolution (see posts #11 and #13) and interpret the setting correctly, or that it won't understand this setting at all and always set a fixed resolution of something like 600 dpi ?

Thanks for the work.

Best regards

Olivier Subilia

The cupsRasterInterpretPPD() of the CUPS image library understands the PostScript code in the PPD. So the selected setting of an option contains the code to set the output resolution to 600 dpi the function finds this, regardless of the name of the option and the name of the setting, for example also in the "Medium" setting of a "Quality" option. This is more reliable than option and setting names. I have found a PPD where the resolution option has the choices "1200dpi" and "4800CQ". You will think that the latter is the higher resolution, but the first contains the PostScript code for 1200 dpi the second for 600 dpi. Only if no resolution setting in the PPDs PostScript code is found, option and choice names are used and only if also this fails a default of 300 dpi is used.

Thank you for the explanation.

Olivier Subilia

I tested your changes - I have a correct printing now without workaround. Thank you, Till.

Thank you, the changes seem to have solved the problem for me now as well.

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

Hello evryone,
I still have this issue with a Cannon BJC 210, LPT printer. The text on the printed paper looks exactly as the scaned one attached by Anthony Hertzler on 2012-05-02: #8. I am using the default ubuntu font ...

What sould I do?

Thanks in advance for any help.

Romeo, your printer is not affected by this bug, this bug treats mostly PostScript printers and some others (with driver foo2zjs or proprietary driver).

If you have used the fully automatic printer setup of Ubuntu to set up your printer, you are not affected by this bug and you are observing another bug. Pleas create a new bug report then and follow the instructions of the sections "CUPS error_log" and "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.

If you have downloaded a driver from Canon, you can perhaps be affected. Then try the commands of comment #21 and tell here with which configuration you get the best quality.