Almut Behrens wrote:
On Thu, Sep 08, 2005 at 03:03:24PM +0200, Jean-Louis Crouzet wrote:
D [08/Sep/2005:10:45:57 +0200] [Job 20] Spooler: cups
D [08/Sep/2005:10:45:57 +0200] [Job 20] Printer: HPLaserJet1100CUPSv1.1.x
D [08/Sep/2005:10:45:57 +0200] [Job 20] PPD file:
/etc/cups/ppd/HPLaserJet1100CUPSv1.1.x.ppd
D [08/Sep/2005:10:45:57 +0200] [Job 20] Printer model: Raw queue
I don't think this should be "Raw queue" -- raw means that any PS code
will be sent through to the printer _as is_. As the HP LJ 1100 cannot
natively handle Postscript, the result is exactly what you described in
your first post: many pages of PS code are being printed verbatim as
plain text, instead of being rendered (via ghostscript).
From taking a peek at the source code of foomatic-rip, it becomes
rather clear that "Printer model: Raw queue" is only being set when
there's no "*FoomaticRIPCommandLine:" directive found in the .ppd file:
(...)
} elsif (m!^\*FoomaticRIPCommandLine:\s*\"(.*)$!) {
# "*FoomaticRIPCommandLine: <code>"
my $line = $1;
(...)
$line =~ m!^([^\"]*)\"!;
$cmd .= $1;
$dat->{'cmd'} = unhtmlify($cmd);
(...)
# Was the RIP command line defined in the PPD file? If not, we assume a
# PostScript printer and do not render/translate the input data
if (!defined($dat->{'cmd'})) {
$dat->{'cmd'} = "cat%A%B%C%D%E%F%G%H%I%J%K%L%M%Z";
if ($dontparse) {
# No command line, no options, we have a raw queue, don't check
# whether the input is PostScript and ignore the "docs" option,
# simply pass the input data to the backend.
$dontparse = 2;
$model = "Raw queue";
}
}
## Summary for debugging
print $logh "${added_lf}Parameter Summary\n";
print $logh "-----------------${added_lf}\n";
print $logh "Spooler: $spooler\n";
print $logh "Printer: $printer\n";
print $logh "PPD file: $ppdfile\n";
print $logh "Printer model: $model\n";
Typically, for non-PS printers, there's a line such as
*FoomaticRIPCommandLine: "gs -q -dBATCH ... ..."
in the PPD file. So that's what I would check first. Maybe you have
a messed up PPD file -- for whatever reason. It claims to be reading
/etc/cups/ppd/HPLaserJet1100CUPSv1.1.x.ppd, so obviously that's the
file to look at. Also, could it be that different PPD files are being
used under different circumstances? (which might explain why the test
page from within the wizard did work, but no printing attempts
afterwards...)
Almut
Hello Almut,
thanks very much for your very interesting inputs. I found in the
etc/cups/ppd/HPLaserJet1100CUPSv1.1.x.ppd file the following, which
looks to me quiet in line with expectation!
*FoomaticIDs: HP-LaserJet_1100 hpijs
*FoomaticRIPCommandLine: "gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPA&&
USE -sDEVICE=ijs -sIjsServer=hpijs%A%B%C -dIjsUseOutputFD%Z -sOutputFi&&
le=- -"
*End
*FoomaticRIPOption Model: enum CmdLine A 100
*FoomaticRIPOptionSetting Model=HP-LaserJet_1100: " -sDeviceManufactur&&
er="HEWLETT-PACKARD" -sDeviceModel="HP LaserJet""
*End
But I do not understand you ask me to rebuild package with additionnal
log? Well I guess this was only a setup issue and didn't recompile the
package grabbed from aptitude.
But your track is definitely the one, raw data are sent to LaserJet
that's for sure.
I was just willing to understand why this couldn't work in the place ;-)
Anyhow, many thanks (forum on CUPS web site just suck compare to the
level of your answer).
Have a nice day,
JL
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
