3.10.2 prints black stripes on CM1312nfi MFP

Bug #561264 reported by Kas-fi on 2010-04-12
32
This bug affects 4 people
Affects Status Importance Assigned to Milestone
HPLIP
Undecided
Sanjay Kumar
Gentoo Linux
Fix Released
Medium
hplip (Fedora)
Fix Released
High
hplip (Ubuntu)
Medium
Unassigned
Lucid
Medium
Unassigned
system-config-printer (Ubuntu)
Medium
Unassigned
Lucid
Undecided
Unassigned

Bug Description

The latest update of hplip/hpijs broke printing to Color LaserJet CM1312nfi MFP
printer - every page has black stripes instead of rows with all white pixels.
Printing from a web browser or OpenOffice.org has the same problem.

My system is Fedora 12, and the downstream bug report is
https://bugzilla.redhat.com/show_bug.cgi?id=579461

This is with 3.10.2, while 3.9.8 works as expected.

As an example, the scanned output of "lpr /etc/profile" is attached to the above bug:
https://bugzilla.redhat.com/attachment.cgi?id=404474

This bug _might_ be related to #555126.

Created attachment 404474
sample of an incorrectly printed document

Description of problem:
The latest update of hplip/hpijs broke printing to Color LaserJet CM1312nfi MFP printer - every page has black stripes instead of rows with all white pixels. I will attach the sample (lpr /etc/profile). Printing from a web browser or OpenOffice.org has the same problem.

Version-Release number of selected component (if applicable):
hpijs-3.10.2-2.fc12.x86_64
hplip-3.10.2-2.fc12.x86_64

How reproducible:
100%

Steps to Reproduce:
1. connect the CM1312nfi printer over USB
2. configure it (I have set up only one non-default option - A4 paper instead of the default US Letter)
3. try to print a document (e.g. lpr /etc/profile)

Actual results:
Rows with at least one non-white pixel are printed correctly, all-white rows are printed all-black instead.

Expected results:
All-white rows should be printed white.

Additional info:
This is a regression - downgrading to 3.9.8-28.fc12.x86_64 versions of hpijs, hplip, etc. and recreating the printer queue fixes the problem.

In addition, I have also reproduced the bug #579355 on my setup.

Additional note: I would like to report it upstream as well, but I am not sure where the upstream is. I have tried to add a comment to the "Known issues in 3.10.2" page (http://hplipopensource.com/node/340), but the comment is still not published there after three days.

Here's the upstream HPLIP bug tracker:
  https://bugs.launchpad.net/hplip

Sorry this hasn't been looked at yet, it is not forgotten...

I've just confirmed that the raster data looks correct before it is processed by hpcups, so it looks like it really is an hpcups bug of some sort.

Kas-fi (kas-fi) wrote :

*** Bug 582000 has been marked as a duplicate of this bug. ***

Also affects:
  HP Color LasetJet 5550 pcl3, hpcups 3.10.2 (en)
  HP Color LasetJet 4700 pcl3, hpcups 3.10.2 (en)

tom mitchell (hydrotom) wrote :

I am running PClinuxOS 2010KDE and it affects my hp4500dn colour laser. With the standard driver only grayscale is produced, there is no option to get colour, with the PCL3 driver colour is produced with the black lines.

Also affecting:
  HP Color LaserJet CP2025dn pcl3, hpcups 3.10.2 (en)

Jiri,

Thanks but this new build isn't working for we. No black lines where whitespace should be, but page content is being printed in the top 25-33% of the page. The one thing that seems to be controlling how much of the page gets printed upon is the presence of figures within the PDF I was printing.

Text other than that along side the figures on the page is being printed on top of itself at the very top of the page.

Sorry, best way I can explain it - I don't have access to a scanner here to show you what the printout looks like.

I downloaded all the rpms for my system, installed using yum localinstall, logged out/in, then deleted the current printer (HP Color LaserJet CP2025dn) and added it again. The above behaviour was what resulted.

The Test Print page prints out OK.

Is there anything else I can try/provide for you?

G

OK, that came from my bad guess about what to change. What's happened is that we've killed all the "move down [n] raster rows" commands, and changed them into something else (move up or something probably).

Gavin, can you now do: yum downgrade 'hplip*' 'hpijs*' 'libsane-hp*'
and try changing the "Output Mode" option in the Printer Options for the queue from RGB to Gray? Let us know if that gives correct blank lines.

I think I've found a useful clue in this document:
  "HP PCL/PJL Reference (PCL 5 Color) - Technical Reference Manual (bpl13212)"
  http://h20000.www2.hp.com/bc/docs/support/SupportManual/bpl13212/bpl13212.pdf

Take a look at page 139, specifically this bit:

This command zero-fills the offset area. For color printers, zero-fills
are filled with the color of index 0, which is not necessarily white.

So I wonder if this is some problem with the indexed colour palette getting its colours in a twist.

Although it looks like it does set colour 0 to white (0xFF 0xFF 0xFF in Device RGB). That all looks fine. :-/

Here's another approach: I've built another hplip package which disables the "move down [n] raster rows" function altogether, and instead sends blank raster lines.

http://koji.fedoraproject.org/koji/buildinfo?buildID=167170

Could you give that one a go?

Sorry for delay in getting back to you - printer in question is at work.

Tried the new build from comment #15. This works for me with:
  HP Color LaserJet CP2025dn pcl3, hpcups 3.10.2 (en)

The couple of PDFs I tried to print are now printing out as I would expect - the whitespace printing as "black" blocks/lines bug does not now occur.

I'm about the head of travelling for several weeks with work so I won't be able to test anything further. Sorry about that; I'll catch up with the bug when I get back. I head off on Monday so in the meantime if you need anything further just shout.

Thanks for looking at this so quickly.

*** Bug 583056 has been marked as a duplicate of this bug. ***

Jiri Popelka (jpopelka) wrote :

This is "work-around" patch from Tim Waugh.

Work-around solution is to send entire blank raster lines instead of skip them.

Hi Tim and/or Jiri,

I would be willing to try the build Tim mentions in comment 15. What is the procedure I should use to install this test build? Do I have to download each of the rpms listed in the build page, for my architecture, and them rpm -i each of them? Or is there a yum way to install this test build in some simple command?

(In reply to comment #19)
> Hi Tim and/or Jiri,

> Do I have to download each
> of the rpms listed in the build page, for my architecture, and them rpm -i each
> of them? Or is there a yum way to install this test build in some simple
> command?

Geoffrey, to test I just downloaded the set of rpms into a directory, cd'd into that directory and then did:

su -c "yum --nogpgcheck localinstall *.rpm"

Having first checked there were no other rpms in that directory.

HTH

Okay, I've done that. This corrects the problem on my HP cm1312nfi. Output now looks normal.

Thanks much! Seems like this would be good to push out into the updates zone.

3.10.2-6.fc12.x86_64 works for me (Color Laserjet CM1312nfi MFP). Please push it to the updates repository.

And thanks for fixing this so quickly!

hplip-3.10.2-11.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/hplip-3.10.2-11.fc13

hplip-3.10.2-6.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/hplip-3.10.2-6.fc12

hplip-3.10.2-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/hplip-3.10.2-4.fc11

Trying to print anything to HP Color LaserJet 2025n results in black stripes - see URL for details. I have patched hplip-3.9.12-r1 with provided patch and seems to be working fine. I assume it should work fine with 3.10.2 as well as upstream bug report is for 3.10.2 version.

Reproducible: Always

Created attachment 228397
"Work around" patch

hplip-3.10.2-6.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update hplip'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/hplip-3.10.2-6.fc12

hplip-3.10.2-4.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update hplip'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/hplip-3.10.2-4.fc11

hplip-3.10.2-11.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update hplip'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/hplip-3.10.2-11.fc13

*** Bug 584164 has been marked as a duplicate of this bug. ***

hplip-3.10.2-6.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.

Seb James (sebjames) wrote :

This bug affects me for a CM1312nfi and also appears to affect my colleague for a CP3505 printer, using the hplip/hpcups driver version 3.9.12.

Seb James (sebjames) wrote :

Possibly related also to Bug #539354.

hplip-3.10.2-11.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.

hplip-3.10.2-4.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.

Chris Coulson (chrisccoulson) wrote :

This also affects Ubuntu, and makes the printer pretty much unusable (printing from OOo, web browser or Evince yields the same results)

Changed in hplip (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Till Kamppeter (till-kamppeter) wrote :

Problem occurs also on my CM3530 (I did not see it before as my printer sets up as PostScript by default and works perfectly this way),

Will apply the patch ...

Changed in hplip (Ubuntu):
status: Triaged → In Progress
Till Kamppeter (till-kamppeter) wrote :

I have applied the patch and it works for me. Fix will be in the next Maverick package of HPLIP.

Developers at HP: Please apply the patch as soon as possible.

Changed in hplip (Ubuntu):
status: In Progress → Fix Committed
tags: added: patch
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hplip - 3.10.5-4ubuntu1

---------------
hplip (3.10.5-4ubuntu1) maverick; urgency=low

  [ Till Kamppeter ]
  * debian/patches/black-stripes-on-pcl5c-printouts.dpatch: The PCL 5c
    driver (Color LaserJet) printed blank raster lines in black (LP: #561264).

  [ Mark Purcell ]
  * Split libsane-hplip - headless scanner libs

hplip (3.10.5-4) unstable; urgency=high

  * Force Depends: python (>> 2.6), python (<< 2.7) (Closes: #587737)
    - Urgency high for RC bug
  * Ack python transition NMUs - Thanks Bernd
 -- Till Kamppeter <email address hidden> Sun, 18 Jul 2010 12:15:18 +0200

Changed in hplip (Ubuntu):
status: Fix Committed → Fix Released
Changed in hplip (Ubuntu Lucid):
importance: Undecided → Medium
status: New → Triaged
status: Triaged → Fix Committed

SRU for Lucid uploaded to-proposed, waiting for approval. debdiff of the SRU is attached.

To reproduce create a CUPS queue for color PCL laser printer (PCL 5c) and print a plain text file. Without the patch the white space between the lines comes out black, with the patch all is correct.

I have tested on the HP Color LaserJet CM3530 MFP and I could reproduce the bug and with the patch installed the bug disappeared.

Changed in hplip:
status: New → In Progress
status: In Progress → New
Changed in system-config-printer (Ubuntu):
status: New → In Progress
importance: Undecided → Medium
Changed in system-config-printer (Ubuntu Lucid):
status: New → Invalid

Another problem is that your printer is also a PostScript printer but not set up in PostScript mode automatically. The problem is caused because their is only one PPD file for the Color LaserJet CM1312 and the CM1312nfi. Inside the PPD file all supported models are listed in "*Product:" lines, but only the CM1312 is listed in the "*ModelName:" line and current printer setup tools only take the "*ModelName:" line into account. I have fixed this in system-config-printer (for Maverick) now (to be uploaded soon). The new version will also take into account the "*Product:" lines in the PPD files.

For the time being please use your printer in PostScript mode by setting it up manually. Start system-config-printer (System -> Administration -> Printing), right-click the icon of your printer, choose "Properties" in the pop-up menu, click on the "Change" button for "Make and Model", choose "HP" as manufacturer and "Color LaserJet CM1312" (without "nfi") as model. Then on the right choose the entry with "Postscript" in it (should be the first), Then click "Forward" until the wizard completes.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package system-config-printer - 1.2.3+20100713-0ubuntu2

---------------
system-config-printer (1.2.3+20100713-0ubuntu2) maverick; urgency=low

  * debian/patches/53_printer-ppd-association-take-into-account-product-lines.patch:
    If a PPD contains one or more "*Product:" lines, take these into account
    as alternative model names when associating PPDs with detected printer
    models. Some PPDs, especially from HP are for various different printer
    models which are listed in "*Product:" lines. Up to now, no printer setup
    tools made use of these lines. Especially the PostScript PPD file for the
    HP Color LaserJet CM 1312 series mentions taht it supports also the
    CM1312nfi only in one of many "*Product:" lines and therefore this printer
    gets automatically installed in PCL mode, as for PCL there are PPDs having
    this printer in "*ModelName:" (LP: #561264).

  * debian-control: Require version 1.9.51-0ubuntu2 or newer of python-cups.

  * debian/patches/57_backend-integration-dnssd-bluetooth.patch,
    debian/patches/75_use-dnssd-uris-for-hplip.patch,
    debian/patches/88_physicaldevice-get-make-model-also-from-makeandmodel.patch,
    debian/patches/94_cache-and-timeout-for-avahi-browse.patch,
    debian/patches/57_backend-integration-blueto oth.patch,
    debian/patches/95_dnssd-device-identification.patch: Reorganized patches to
    avoid overlapping of the changes.
 -- Till Kamppeter <email address hidden> Wed, 21 Jul 2010 15:33:33 +0200

Changed in system-config-printer (Ubuntu):
status: In Progress → Fix Released

Note that we are currently in SRU freeze for 10.04.1. Therefore no official SRU testing will be possible for two weeks from now. To make the fixes available to you already now and to give you also the possibility to give us our testing period before the official SRU testing I have uploaded a package identical to the SRU to my PPA. Please test this package and report here.

Please go to

https://launchpad.net/~till-kamppeter/+archive/ppa

and see the "Adding this PPA to your system" for instructions to get my PPA added to your system's software download repositories.

After that do a full system update. The new HPLIP and some other packages (for other SRUs) will get downloaded and installed.

If you have manually switched to PostScript for your production print queue, please create another print queue and let the driver selection go automatically. Printing from that queue do not show the black lines.

John Dong (jdong) wrote :

ACK from SRU (after SRU freeze)

Accepted hplip into lucid-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!

tags: added: verification-needed
Chris Coulson (chrisccoulson) wrote :

Confirming the package in lucid-proposed fixes the issue with my CM1312nfi

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hplip - 3.10.2-2ubuntu2.1

---------------
hplip (3.10.2-2ubuntu2.1) lucid-proposed; urgency=low

  * debian/patches/black-stripes-on-pcl5c-printouts.dpatch: The PCL 5c
    driver (Color LaserJet) printed blank raster lines in black (LP: #561264).
 -- Till Kamppeter <email address hidden> Mon, 19 Jul 2010 17:58:18 +0200

Changed in hplip (Ubuntu Lucid):
status: Fix Committed → Fix Released

i have the same with p1005(b&w printer) and it's shown as color printer in cups

Still applicable for version 3.10.9

Changed in gentoo:
importance: Unknown → Medium
Sanjay Kumar (sanjay-kumar14) wrote :

Hi,

Thanks for reporting the issue. We will remove the color option for this device. Just wanted one clarification. Is printing happening fine on p1005(b & w printer), or is it printing black patches.

Also please provide the output of "hp-check -t" command.

Thanks,
Sanjay

Changed in hplip:
status: New → In Progress
assignee: nobody → Sanjay Kumar (sanjay-kumar14)

Over a year later, and this is still an issue with hplip-3.11.12. I can confirm that the patch resolves the problem. Can anyone get word through to the hplip maintainers?

+*hplip-3.11.12-r1 (12 Jan 2012)
+
+ 12 Jan 2012; Daniel Pielmeier <email address hidden> +hplip-3.11.12-r1.ebuild,
+ +files/hplip-3.11.12-black-stripes-pcl5c.patch:
+ Fix bug #316111. Thanks to Marcin Deranek for the report.

Patch from upstream bug applied.

Changed in gentoo:
status: Unknown → Fix Released

Yo the HPLIP developers at HP: Can you apply the patch debian/patches/black-stripes-on-pcl5c-printouts.dpatch of the Ubuntu package of HPLIP to upstream HPLIP? Thanks.

Jaime Carpenter (j.carpenter) wrote :

I have the same problem with HPLIP v3.13.2 and an HP cm2320nf on Ubuntu LTS 10.04.

Jiri Popelka (jpopelka) wrote :

Patch from comment #3 seems to be finally applied in 3.13.9, thanks.

Changed in hplip:
status: In Progress → Fix Released
Changed in hplip (Fedora):
importance: Unknown → High
status: Unknown → 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.