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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]