black squares appearing instead of some letters when printing

When printing from Oo.o the black box appears on some letters, on other ones when printing from evince

Jaunty beta

I'm printing on a Gestetner-DSm725 with the following ppd:

http://openprinting.org/foomatic-db/db/source/PPD/Gestetner/PXL/Gestetner-DSm725_PXL.ppd

The same driver printed perfectly in intrepid.

The boxes doesn't appear if using the driver installed by ubuntu when discovering the printer. Supposedly a problem with the driver http://openprinting.org/foomatic-db/db/source/PPD/Gestetner/PXL/Gestetner-DSm725_PXL.ppd

apparently a problem with a ppd file

I have the same problem with the driver "Gestetner-MP_C2800_PXL.ppd" for a "MP C2800" printer and the driver "Gestetner-MP_5000_PXL.ppd" for a MP5000 when changing to jaunty.

The default driver for MPC2800 does not support color, so this is not an option. And the default driver for MP5000 does not support finisher, so no stampling of printing jobs

This problem is caused by a Ghostscript bug:

http://bugs.ghostscript.com/show_bug.cgi?id=690025

Just upgraded from intrepid to jaunty. Went to print a simple OpenOffice spreadsheet and getting those black squares for some letters/numbers. Not a problem in intrepid.

Forgot to mention that my printer is a HP Laserjet 3200.

Shame problem with Ricoh Aficio MP C2500 PX. No problems in Intrepid but some black square instead of the right letters in Jaunty.
Someone can tell us how to solve the problem till the bug in ghostscript is solved?

In order to print correctly, I have to print firs in cups-pdf (sudo apt-get install cups-pdf), open with document viewer the created pdf file and printing it in the real printer. Doing this there are no black squares in my printing job, but it takes too much time.

Same problem. Jaunty final, HP LaserJet 3200 squares instead of some characters. Either black (white bg) or white (black bg) in test pages and from Oo.o. Using default recommended foomatic driver.

Forgot to add this was a clean install, not an upgrade. Printer worked fine in 8.10, 8.04, and earlier.

Switching to hpijs 3.9.2 driver fixes the problem so the foomatic/pxlmono driver is buggy.

hpijs driver is very slow for HP Laserjet 1200 (~5 times slower), so its not a good workaround.

Everyone who has black squares in his output, please attach your actually used PPD file (in /etc/cups/ppd/) and follow the instructions under "CUPS error_log" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Attach also the file you tried to print and tell from which application you tried to print it. Do not compress any of the attached files.

OK, Till, I'll play. Laserjet 1200 printing the attached pdf file (generated by pdflatex from small2e.tex) with lp has the black squares at random places.

error_log and ppd attached.

Thanks,

---Fran

Ummm...can't see how to attach multiple files so I will tar them all up...

Architecture: i386
DistroRelease: Ubuntu 9.04
Lpstat:
 device for HP-LaserJet-1200: hp:/usb/HP_LaserJet_1200?serial=00CNCF755836
 device for HP-LaserJet-1200-2: hp:/usb/HP_LaserJet_1200?serial=00CNCF755836
MachineType: IBM 2373WBZ
Package: ghostscript 8.64.dfsg.1-0ubuntu8
PackageArchitecture: i386
Papersize: letter
PpdFiles:
 HP-LaserJet-1200-2: HP LaserJet 1200 Foomatic/pxlmono (recommended)
 HP-LaserJet-1200: HP LaserJet 1200 hpijs, 3.9.2
ProcCmdLine: root=UUID=bd666f4b-018a-4871-82fa-6e63b3a93854 ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.28-11.42-generic
Uname: Linux 2.6.28-11-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Whoo, "ubuntu-bug cups" and "apport-collect BUGNUMBER" have just uploaded these 1001 attachments. I'll add some files:
* ppd for hpjis; it's named "1200" on my computer (works quite fine, except I have to activate "scale to fit" in the job options, else it shifts everything up by at least one or two centimetres so the first lines get cut)
* ppd for pxlmono; it's named "1200_2" (produces the ugly squares and works slower)
* The OOo Writer document I used as an example
* scan of the result of hpjis (OK)
* scan of the result of pxlmono (not OK)

forgot to say: I printed from OOo Writer 3.0.1 (OOO300m15 Build:9379)
$ apt-cache policy openoffice.org
openoffice.org:
  Installed: 1:3.0.1-9ubuntu3
  Candidate: 1:3.0.1-9ubuntu3
  Version table:
 *** 1:3.0.1-9ubuntu3 0
        500 http://ch.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

Fran Burstall, thank you very much for your files. With these I have found out what the problem is. It is an upstream bug in foomatic-db-engine, the Foomatic PPD generator. The Foomatic-generated PPD file is broken and therefore an unnecessary conversion of the incoming PDF to PostScript happens which lets you run into the mentioned Ghostscript bug. I have another printer where the PPD file got generated correctly and therefore I could not reproduce the bug. With a correct PPD file the mentioned Ghostscript bug does not affect Ubuntu (at least not when using PPDs coming with Ubuntu packages).

Christoph, also thank you for your files. Your PPD exposes the same problem.

Lars, the problem is that if JCL options are member options of a composite option (not forced, in our case "PrintoutMode"), they loose their "*JCLOpenUI:"..."*JCLCloseUI:". This removes all evidence that they are JCL options from them and so they are considered PostScript options. This makes foomatic-rip converting the PDF job into PostScript (using Ghostscript with "pswrite") and after that Ghostscript is called again with the "pxlmono" driver, triggering Ghostscript upstream bug #690025 (the bug causing the squares).

What has to be done is either

- Keep the "*JCLOpenUI:"..."*JCLCloseUI:" in the options even if they are member options of a composite options, but check whether foomatic-rip still works correctly with them, also whether cupstestppd does not choke on the "FromPrintoutMode" choice whose code is not correct PJL, and whether pstops or pdftopdf do not insert "%% FoomaticRIPOptionSetting: FastRes=@PrintoutMode" into the PJL header.

or

- If one of the problems mentioned above happens, return to the old Foomatic-keyword-based scheme of JCL options for the case that a JCL option is member option of a composite option.

This does not occur for forced composite options (in our case "PrinterResolution"), as they are completely based on Foomatic keywords.

Here are the broken JCL options of the PPD file for the HP LaserJet 1200 with pxlmono (PPD from Fran Burstall or HP-LaserJet-1200-2.ppd from Christoph):

*OpenUI *FastRes/Fast Res.: PickOne
*OrderDependency: 100 AnySetup *FastRes
*DefaultFastRes: FromPrintoutMode
*FastRes FromPrintoutMode/Controlled by 'Printout Mode': "%% FoomaticRIPOptionSetting: FastRes=@PrintoutMode"
*FastRes Off/Off: "@PJL SET BITSPERPIXEL=1<0A>"
*FastRes On/On: "@PJL SET BITSPERPIXEL=2<0A>"
*CloseUI: *FastRes

*OpenUI *Economode/Toner Saving: PickOne
*OrderDependency: 100 AnySetup *Economode
*DefaultEconomode: FromPrintoutMode
*Economode FromPrintoutMode/Controlled by 'Printout Mode': "%% FoomaticRIPOptionSetting: Economode=@PrintoutMode"
*Economode Off/Off: "@PJL SET ECONOMODE=OFF<0A>"
*Economode On/On: "@PJL SET ECONOMODE=ON<0A>"
*CloseUI: *Economode

Anyone who suffers this problem with a Foomatic PPD (mainly HP printers) should try to choose the "Generic PCL 6/XL printer" with the pxlmono or pxlcolor driver as printer model. Then the printer should work correctly and with high speed, only the Economode and FastRes are not available then.

If you have a Ricoh, Gestetner, Infotec, Lanier, NRG, or Savin printer, please install the openprinting-ppds-extra package and set up a new print queue with the PPDs coming with this package.

Thanks, Till.

"Generic PCL 6/XL printer" with pxlmono works perfectly for my Laserjet 1200.

My Laserjet 3200 prints perfectly now and faster using "Generic PCL 6/XL printer" with pxlmono.

Thanks, Till.

Ok Till, this is my error_log

I am attaching now pending files:

Printer Ricoh Aficio MP C2500 PXL

Printing file: NVIDIA-Instalar.txt

ppd file: Fotocopiadora.ppd

Scanned file with printing problem: Ricoh-Aficio-MP-C2500 PXL-BadPrinting

I have printed this file with gedit in Ubuntu 9.04.

Image file with bad printing in png format

Till, thanks for the hint! The generic "PCL6/PCL XL Printer" with "pxlmono" works perfectly, better than hpjis: The page margins are fine, no shifting to the top, printing is fast.
I just wonder why the generic ppd produces better results than the HP specific one...

Maybe the generic version should be set as default in Ubuntu, instead of hpjis?

I have tried to print in the Ricoh Aficio MP C2500 PXL with openprinting-ppds-extra package, but printer does nothing, printer do not print anything. I do not know if the user code I have to add to the ppd file can be the problem, but with the older ppd the printer worked (with the mentioned black squares).

Any new idea?

Thanks.

I am sorry. It was a problem with my user code.

Ricoh Aficio MP C2500 PXL with openprinting-ppds-extra package work fine.

Thanks for your help Till.

I am sorry. It was a problem with my user code.

Ricoh Aficio MP C2500 PXL with openprinting-ppds-extra package works fine.

Thanks for your help Till.

If you are on Jaunty or Karmic and suffer shifted printouts (in most cases around 2 cm to the top) with hpijs (or any other driver) please make sure that you have applied all updates, as the shift is a known bug and got already fixed. If you have still shifted printouts, please file a new bug.

Till: Yes, you're right, hpijs (on Jaunty) has been fixed without my realising!

The openprinting-ppds-extra install worked perfectly, and the PPD's were updated automatic.
Thank for your help Till

Here is another thing worth testing:

Use a PPD which leads to the black boxes (PCL-XL PPD for Ricoh and OEM printers from OpenPrinting or pxlmono PPD for HP LaserJet 1200), replace your /usr/lib/cups/filter/pdftops file by the attached one (do not forget to make the new file executable with "chmod 755 /usr/lib/cups/filter/pdftops") and print again. Do the black boxes disappear?

Absolutely YES! It works like a charm.
Both printing directly from OpenOffice and from a PDF in Evince!
Great job!
The current pdftops is a binary file, while your is a shell script, so cannot compare them. What was the problem?

Thank you! :-)
Luca

Till: No, the new pdftops does not fix the squares for "HP LaserJet 1200 Foomatic/pxlmono", printing the document above (https://bugs.launchpad.net/ubuntu/+source/foomatic-db-engine/+bug/361772/comments/33 from OOo). The result is exactly the same as before. The system (Xubu Jaunty) is up to date.

Both filters call Ghostscript to convert PDF into PostScript. The original one (binary) calls Ghostscript with the "pswrite" output device and the new one (script) calls Ghostscript with the "ps2write" output device. The "pswrite" output device turns all text characters into bitmaps whereas the "ps2write" conserves the fonts. The conversion of the characters into bitmaps causes several problems, the squares when the data is fed into the "pxlmono" driver (this bug and the Ghostscript bug #690025 linked above), large output files (bug 44989), and corrupted characters on PostScript printers (bug 362186).

So principally one should prefer "pswrite" over "ps2write", but "ps2write" has also a disadvantage: The output is not DSC-compliant, so page manipulation utilities (like CUPS' pstops filter) will not fully work with these files. In our case it works well, as page m,anipulation was done already before by the pdftopdf filter. After the pdftops filter we only embed Postscript code for the option settings into the job, and this does not need DSC compliance.

Christoph, in your case the pdftops filter is not used, only for the users of Ricoh and OEM printers it gets called. So for you no change happens. Please stay with the "Generic PCL 6/XL printer until the fixed foomatic-db-engine will be available.

Forgot to mention, the PPD in use is for a Ricoh MP C2050 PCL printer.
It is from OpenPrinting:
*PPD-Adobe: "4.3"
*%
*% Printer Description file
*% for "Ricoh Aficio MP C2050 PXL"
*%
*% CreationDate: 2007/12/17
*% Modified: 2009/02/11

Very good job Till. Rico Aficio MP C2500 PXL old driver works fine with your new pdftops file.

Should I use this new file or should I recover the old one (pdftops)?

Thanks.

Fixed upstream in foomatic-db-engine BZR repositories head branch (rev 240) and 4.0 branch (rev 240).

This bug was fixed in the package foomatic-db-engine - 4.0.0-0ubuntu7

---------------
foomatic-db-engine (4.0.0-0ubuntu7) karmic; urgency=low

  * debian/patches/20_fix-jcl-options-as-members-of-composite-options.patch:
    Upstream fix in the PPD generator: In Foomatic PPDs JCL options were
    broken when they where member options of a composite options. In addition
    to these options not being correctly applied this made them also be
    interpreted as a PostScript options which in turn made foomatic-rip
    converting PDF jobs to PostScript. This made some printers suffering
    LP: #361772 which usually is worked around by the PDF printing workflow.

 -- Till Kamppeter <email address hidden> Thu, 7 May 2009 22:00:49 +0200

I propose this fix also as an SRU for Jaunty. debdiff attached and package uploaded to jaunty-proposed and waiting for approval.

To reproduce:

Currently the PPD file for the HP LaserJet 1200 contains broken FastRes and EconoMode options as shown in

https://bugs.edge.launchpad.net/ubuntu/+source/foomatic-db-engine/+bug/361772/comments/38

With the fix applied they will get generated correctly and they look like

*OpenUI *FastRes/Fast Res.: PickOne
*FoomaticRIPOption FastRes: enum JCL A
*OrderDependency: 100 AnySetup *FastRes
*DefaultFastRes: FromPrintoutMode
*FastRes FromPrintoutMode/Controlled by 'Printout Mode': "%% FoomaticRIPOptionSetting: FastRes=@PrintoutMode"
*FastRes Off/Off: "%% FoomaticRIPOptionSetting: FastRes=Off"
*FoomaticRIPOptionSetting FastRes=Off: "SET BITSPERPIXEL=1"
*FastRes On/On: "%% FoomaticRIPOptionSetting: FastRes=On"
*FoomaticRIPOptionSetting FastRes=On: "SET BITSPERPIXEL=2"
*CloseUI: *FastRes

*OpenUI *Economode/Toner Saving: PickOne
*FoomaticRIPOption Economode: enum JCL A
*OrderDependency: 100 AnySetup *Economode
*DefaultEconomode: FromPrintoutMode
*Economode FromPrintoutMode/Controlled by 'Printout Mode': "%% FoomaticRIPOptionSetting: Economode=@PrintoutMode"
*Economode Off/Off: "%% FoomaticRIPOptionSetting: Economode=Off"
*FoomaticRIPOptionSetting Economode=Off: "SET ECONOMODE=OFF"
*Economode On/On: "%% FoomaticRIPOptionSetting: Economode=On"
*FoomaticRIPOptionSetting Economode=On: "SET ECONOMODE=ON"
*CloseUI: *Economode

You can quickly generate said PPD with

foomatic-ppdfile -p HP-LaserJet_1200 -d pxlmono > lj1200.ppd

With the corrected PPD foomatic-rip will not convert PDF input into PostScript any more but feed PDF directly into Ghostscript. This makes the Ghostscript bug not being triggered any more and one is able to use the EconoMode and FastRes options.

Looks okay. Waiting for feedback in bug 373371.

To make also older PPDs for Ricoh and OEM printers working, we are al;so looking in using the "ps2write" output device of Ghostscript in our pdftops filter. See bug 369503.

The use of the "ps2write" output device of Ghostscript in the pdftops filter is not yet possible in CUPS, due to http://bugs.ghostscript.com/show_bug.cgi?id=690475

For the time being, use the PPD files from the openprinting-ppds-extra Ubuntu package. The PPDs on OpenPrinting will be updated soon.

Anyone using an HP printer, please use Generic PPD files for now and remove and re-create your queue as soon as you have installed the update of foomatic-db-engine from -proposed.

The PPD files from Ricoh and OEM are all updated now on the OpenPrinting server, both as single files and packages.

Everyone who has installed a PPD package from there should get a fixed package and an automatic update of the existing print queues within the next 24 hours (or he can do it immediately entering the following commands in a terminal window: "sudo apt-get update; sudo apt-get upgrade".

Everyone who has downloaded a single PPD, please download and install it again.

The bug in the "ps2write" device of Ghostscript (http://bugs.ghostscript.com/show_bug.cgi?id=690475) is fixed. I will apply the patch to Karmic's Ghostscript package soon.

For Jaunty the problem is solved by the SRU for foomatic-db-engine and by the updates on the OpenPrinting web site. Therefore all unneeded Jaunty tasks will be closed now.

Accepted foomatic-db-engine into jaunty-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!

Martin, HP LaserJet 1200 Foomatic/pxlmono (recommended) has just printed a page fine after installing the jaunty-proposed version (it's the same document I always used, see above). Before, pxlmono had always produced the squares in jaunty. So i suppose the bug is dead. Thanks to everyone!

I assume it's a good idea to get rid of the -proposed repository if want a stable system?

This bug was fixed in the package foomatic-db-engine - 4.0.0-0ubuntu6.1

---------------
foomatic-db-engine (4.0.0-0ubuntu6.1) jaunty-proposed; urgency=low

  * debian/patches/25_fix-driver-in-printer-xml-without-driver-xml.patch:
    If a printer XML entry has a driver in its driver list but for which
    there is no driver XML entry, this printer/driver combo was considered
    as producing a PPD because the driver is not in the list of drivers
    without command line prototype. This leads for example to non-working
    "Foomatic/Gutenprint" driver entries in the printer setup tools
    (LP: #373371).

  * debian/patches/20_fix-jcl-options-as-members-of-composite-options.patch:
    Upstream fix in the PPD generator: In Foomatic PPDs JCL options were
    broken when they where member options of a composite options. In addition
    to these options not being correctly applied this made them also be
    interpreted as a PostScript options which in turn made foomatic-rip
    converting PDF jobs to PostScript. This made some printers suffering
    LP: #361772 which usually is worked around by the PDF printing workflow.

 -- Till Kamppeter <email address hidden> Fri, 8 May 2009 12:57:49 +0200

The pdftops CUPS filter script, replacing /usr/lib/cups/filter/pdftops fixes this problem for me (using a Ricoh MP C2000).

Unfortunately, installing the CUPS security upgrade today replaced the script with the original binary blob, which in turn brought the problem back.

Any way to avoid this happening again on the next CUPS upgrade? Can the logic of the script not be incorporated somehow into the original pdftops filter?

Neil Robinson, the pdftops filter which I have attached was only for testing. I have attached it to very many bugs (see bug 382379). If I get enough positive answers and no negative ones (or find fixes/workarounds for these users) I will integrate the new filter in our CUPS package so that it flows in automatically with updates. As long as the testing is not completed you will have to reinstall the file aftyer each CUPS update. There should not be too many CUPS updates when you are using a released Jaunty and not Karmic.

The pdftops which you have tested is already obsolete, as there is a new one fixing more regressions. So please install now the pdftops attached to this comment and tell whether it also helps you.

Till, the old filter still worked fine for me. I've installed the new one and will see what happens when I need to print again.

You can safely assume that it still works fine if you don't hear from me again on this bug.

Thanks for all your friendly assistance.

Neil Robinson, we will need also your positive answer, so that we will quickly know whether the attached file really fixes this bug. So I ask you kindly to post here also if you have a positive result.

We will also soon upload a new CUPS package with the modified filter for testing and make a call for testing in this bug report. As soon as this happens, please test the uploaded packages and tell whether they work for you.

(HP Laserjet 1200) I've installed the new, poppler based pdftops CUPS filter. It seems to work fine through a newly created foomatic/pxlmono printer. However, I've not tested it after the CUPS update and before I installed the new filter.

I printed a text file yesterday with no problems, so I can positively confirm that the script works for the Ricoh MP C2000 (and will probably work for MP C2500 and MP C3000 -- models which share the same printer manual).

Thanks again.

After last upgrade of cups (1.3.9-17ubuntu3) to 1.3.9-17ubuntu3.1 of yesterday, the problem of black squares is back again.

The upgrade replaced /usr/lib/cups/filter/pdftops and I lost the pdftops posted by Till here:
https://bugs.launchpad.net/ubuntu/+source/foomatic-db-engine/+bug/361772/comments/55

Replacing the pdftops again all is fine.

Any ideas?

Thanks!

Liuk, note that a package update overwrites all files (except files in /etc) with the files contained in the package, so manual changes get lost. The files which we are asking you to install manually are to find out how to fix this and other bugs in an update which we will provide soon and also for the next Ubunru release.

Please install the pdftops attached to this comment as it contains an additional fix.

Hi Till,

yes I know, but I was confused by the fact that this bug seemed fixed by foomatic-db-engine, instead it seems to be a cups issue still not fixed.

Anyway, I've tested your last pdftops and it seems to work fine!

BTW, the printer involved is a Ricoh MP C2050.

Thanks,
Luca

The fix in foomatic-db-engine is only a workaround. The real fix is the replacement of the pdftops filter by a filter which does not use Ghostscript with the "pswrite" output device.

Sorry, I attached the wrong file. Please use the one attached to this comment.

It works fine!

Tryed with the Ricoh MP C2050, printing from Thunderbird and from a PDF in Evince.

Thank you!
Luca

When will this be released? I'm so tired of fixing every single Ubuntu machine. Some time ago a "fix" overwrote the pdf2ps I installed, and thus made problems again. People were not happy.

What's keeping it? Anything we can do to make it come into jaunty-updates soon?

This task is covered by bug 382379 which is fixed now.

Odin Hørthe Omdal, the CUPS filter update is released now (bug 382379). So your next automatic system update will include it.

This bug was fixed in the package ghostscript - 8.70.dfsg.1-0ubuntu4

---------------
ghostscript (8.70.dfsg.1-0ubuntu4) lucid; urgency=low

  * debian/patches/pxl-driver-fixes.dpatch: Several upstream bug fixes
    on the PCL-XL drivers ("pxlcolor"/"pxlmono") in Ghostscript, especially
    also for PDF input. Thanks to Hin-Tak Leung on putting all that work
    into this driver which stayed nearly untouched for around 10 years.
    (LP: #361772).
 -- Till Kamppeter <email address hidden> Mon, 7 Dec 2009 20:23:23 +0100

This is still happening to me on Natty. I have an HP cp1518ni. I've attached my PPD. What other debugging information would you like?

Richard, please follow the instructions in the sections "CUPS error_log" and "Capturing print job data" of https://wiki.ubuntu.com/DebuggingPrintingProblems.