CUPS print jobs print 1st page OK, but all others are overwritten
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
As far as I can tell this is not printer specific. It's just CUPS and the low default 8 Mb memory for rasterization (see, for example http://lists4.opensuse.org/opensuse-.../msg00555.html). To solve it just edit /etc/cups/cupsd.conf and add a line at the end of the file with
I solved upgrading ghostscript with the Pat's slackbuild a few days ago (hplips and cups are already up to date in slackware 13.37). When upgrading ghostscipt I didn't use the patches provided by Pat.
I had the same problem with an HP Officejet 4500. Not only I faced the overwrite problem, but color printings was in negative.
UPDATE: the new ghostscript-9.02 package is in the -current from yesterday.
And in the changelog, Pat asks: "Is this ready for 13.37/patches now?".
Then I removed my ghostcript and installed the one downloaded from slackware.com and it works fine for me. So I would say yes
Originally Posted by staus
Not sure when CUPS started acting up. I have the latest 13.1 current software installed. The first page to print is always OK, but all succeeding pages are overwritten. The second page shows the first page on top of it, and the third shows the preceding pages on top of it - and so on.
Has anyone else seen this problem?
I guess the printer buffer is not getting flushed correctly. If my configurations were trashed in some way, I don't know where to look for a fix.
Last edited by roberto967; 06-29-2011 at 02:32 AM.
I'm having a similar problem after installing Slackware 13.37 (x86 version). The standard package using the hpijs driver in hplip-3.11.3a with cupsd hung at the end of a 1 page Postscript document. My printer is an HP3650, which uses the HP3320 driver. These are not PCL printers, so the device driver has to convert Ghostscript raster lines to HP's "proprietary" PPA format. The driver does not emit a "print buffer" PPA command after the last data, causing the hang. The dj3320 driver in -3a/prnt/hpijs is a mess of state machine and spaghetti code, and I couldn't figure out how to fix it, so I recompiled and reinstalled hplip to use the "hpcups" backend to ghostscript-9.00, and the problem went away. However, now I get the overprinting described earlier. Haven't had a chance to look at the PPA from the hpcups driver yet, but I'm sure a "buffer clear" is missing at the beginning/end of each page, except the first. For what it's worth, when looking at the postscript directly with a "gs" command, the output looks fine(on the screen), so it is unlikely that Ghostscript itself is screwing up the raster lines. The ijs backend to ghostscript simply forwards the lines to hplip/hpcups, so the high probability candidate is the driver, either the Lidl.cpp file or something in the dj3320...h files. Unlike hpijs, hpcups has a common driver for many different printers...
Last edited by Rod3775; 06-30-2011 at 06:45 PM.
[WORKAROUND] for ghostscript-9.00 slackware overprinting
Contrary to my earlier post, the problem relates to the IJS driver in GS-9.00. Reverting to ghostscript-8.71 (from the Slackware 13.1 release) gets things working again. I sent a bugzilla post upstream to the Ghostscript bug list. Maybe overtaken by events - will try 9.02 based on latest posts...
I've commented on the Ghostscript bugzilla report*:
"We're unlikely to look into this unless you can supply a Ghostscript invocation to reproduce the problem - ""lpr foo.ps" with CUPS installed" doesn't help us to reproduce the issue in a debug environment."
Also, if it turns out that 9.02 does resolve the issue, we'd appreciate updating the bug to that effect.