Misplaced spaces on printout on Canon ir 3035

Bug #960989 reported by karaluh on 2012-03-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
ghostscript (Ubuntu)

Bug Description

As in summary. See test case and scanned printout. It only happens on Canon ir3035 and only in Okular, Evince prints the document correctly on this printer, so is Okular on other printers. According to Okular devs, it's not Okular bug:

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cups 1.5.0-8ubuntu7
ProcVersionSignature: Ubuntu 3.0.0-16.29-generic 3.0.20
Uname: Linux 3.0.0-16-generic i686
ApportVersion: 1.23-0ubuntu4
Architecture: i386
Date: Wed Mar 21 10:07:36 2012
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
Papersize: a4
 PATH=(custom, user)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-16-generic root=UUID=d6d9b55b-2a61-4793-a5ba-982b43f9a7f4 ro quiet splash vt.handoff=7
SourcePackage: cups
UpgradeStatus: Upgraded to oneiric on 2011-10-18 (154 days ago)
dmi.bios.date: 06/11/2004
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1002.002
dmi.board.name: P4P800-MX
dmi.board.vendor: ASUSTek Computer Inc.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1002.002:bd06/11/2004:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASUSTekComputerInc.:rnP4P800-MX:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

karaluh (karaluh) wrote :
karaluh (karaluh) wrote :
Till Kamppeter (till-kamppeter) wrote :

Can you check whether with the corrected PPD file from bug 953962 your printing works correctly again?

Changed in cups (Ubuntu):
status: New → Incomplete
karaluh (karaluh) wrote :

Unfortunately no, the bug is still there.

Changed in cups (Ubuntu):
status: Incomplete → New
Till Kamppeter (till-kamppeter) wrote :

For bug 953962 you have created a test queue with the "Generic PCL-5e printer Foomatic/ljet4". Can you try to print this file through this queue? Does it print correctly now?

Changed in cups (Ubuntu):
status: New → Incomplete
Till Kamppeter (till-kamppeter) wrote :

Can you also attach the original (PDF) file? Thanks.

karaluh (karaluh) wrote :

The spaces also are misplaced on the Generic queue.

karaluh (karaluh) wrote :
Changed in cups (Ubuntu):
status: Incomplete → New
Till Kamppeter (till-kamppeter) wrote :

Can you also post the original PDF file which you tried to print? Thanks.

karaluh (karaluh) wrote :

Sorry, misread PDF as PPD :). The original PDF is attached, it's "Test case", the first attachment on the list.

affects: cups (Ubuntu) → ghostscript (Ubuntu)
Changed in ghostscript (Ubuntu):
importance: Undecided → High
milestone: none → ubuntu-12.04
status: New → Confirmed

This is a bug in Ghostscript. It appears if Ghostscript is converting PDF into a raster format (not into PostScript). For you it occurs because both the proprietary PPD and the generic PPD call Ghostscript with the "ljet4" driver, a driver which sends raster data (in PCL 5e) to the printer.The difference of the proprietary PPD is that the Ghostscript output is passed through a filter which adds printer-model-specific control commands (for trays, finishing, ...).

You can simply reproduce it by printing your PDF file with Okular into a PDF file. This Okular-mangled PDF file is attached. Convert this file to a PNG file with Ghostscript:

gs -sDEVICE=png16m -r300 -sOutputFile=out.png UNI-ZM1_v-.pdf

and look at it with any photo viewer, for example:

eog out.png

The problem occurs also here.

Sorry, have done more checks, it is Okular. If you display the attached file with any PDF reader (Adobe Reader, evince, Okular, Ghostscript, ...) you see that it is broken. Okular has already broken it for you.

affects: ghostscript (Ubuntu) → okular (Ubuntu)

It can also be Poppler or any Ubuntu patches on Okular or Poppler.

It is really strange, there are several ways to get the broken file.

Yesterday I discovered that it happened with "Print to a file (PDF)" in Okular. This is a bug of Okular or the underlying Poppler, but not this bug.

When I print into an actual print queue (with ljet4 as driver) Okular sends PostScript (most apps send PDF nowadays) and this PostScript is still correct (therefore this bug is not an Okular bug). CUPS calls the pstopdf filter to turn this PostScript to PDF and this filter uses Ghostscript. On this step the file breaks.

You can reproduce it by running the following command with the attached PostScript file:

gs -sDEVICE=pdfwrite -sOutputFile=out.pdf printout.ps

This means that the bug is actually in Ghostscript, with Ghostscript's "pdfwrite" output device.

Moving to Ghostscript ...

affects: okular (Ubuntu) → ghostscript (Ubuntu)

Reported to Ghostscript upstream as


Changed in gs-gpl:
importance: Unknown → High
status: Unknown → Confirmed

The real bug here is a problem of the PostScript file. It embeds a font with missing space glyph. This is caused by either Okular or an underlying library like Poppler or it is already caused by the original PDF input file, which itself was converted from a PostScript file using an old version of Ghostscript.

The Ghostscript developers have now introduced a workaround which makes such files being displayed/printed/converted correctly. This workaround I have now included in the Ghostscript package for Ubuntu, version 9.05~dfsg-0ubuntu4. The package is uploaded and will get available as update for Precise soon after the beta2 release.

Changed in ghostscript (Ubuntu):
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ghostscript - 9.05~dfsg-0ubuntu4

ghostscript (9.05~dfsg-0ubuntu4) precise; urgency=low

  * debian/patches/020120329-be64563-pdfwrite-when-a-charstring-is-not-found-for-a-glyph-use-the-notdef-width-instead-of-0.patch:
    The "pdfwrite" output device uses zero and not the width of /.notdef whn
    using /.notdef for a glyph not found in an embedded font. This leads to
    wrong spacing in a PostScript file missing a space glyph (LP: #960989,
    upstream bug #692944).
 -- Till Kamppeter <email address hidden> Thu, 29 Mar 2012 15:41:13 +0100

Changed in ghostscript (Ubuntu):
status: Fix Committed → Fix Released
Changed in gs-gpl:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.