[cups.general] What does "RAW" means for a queue?

[Kurt Pfeifle]

Ciprian Marius Vizitiu wrote:

> Oh Kurt, thanks a *LOT* for weighting in, I've been struggling with this
> problem for... quite some time now. :-|

Sorry, today my answers will be rather short (and maybe incomplete)...
not so much time right now...

>> A "raw" printqueue in CUPS is one that has *no* PPD assigned 
>> to it. A queue without a driver, if you like.
>>
>> Basically you say: "send all jobs to printer unchanged + 
>> unfiltered, when- ever you receive them, from whichever 
>> client". (This assumes, the job is in a file format that the 
>> target printer will be able to understand and process).
>>
>> "Raw printing" from a Windows client does also mean "File is 
>> print-ready, do not process any further".
> 
> Your explanation sounds *exactly* as I thought it should be, yet facts
> don't...
> 
> Ok the story from the very beginning: I have a small network consisting of
> XP WS using a Samba PDC and CUPS driving a bunch of printers; no
> "WinPrinters" here all "100% Linux compatible" linuxprinting.org "certified
> ware"; Samba 3.0.10 and CUPS 1.1.22.

Both version are rather old... (3.0.10 == December 2004; 1.1.22 == Oct 2004)
I personally haven't used them since quite some time.

Latest CUPS from the 1.1.x series is 1.1.23 (released Jan 2005). And of
course, we since had 1.2.0 to 1.2.12 as well as 1.3.0 ...

Latest Samba is 3.0.25c (released yesterday).

Have a look at http://www.cups.org/relnotes.php and search for keywords that
may be related to your problems (like "PDF" to see if there were fixes in
newer releases).

And if you search for "print" or "cups" in the Samba release notes (see
http://us1.samba.org/samba/history/samba-3.0.25.html as well as
http://us1.samba.org/samba/history/samba-3.0.25a.html as well as
http://us1.samba.org/samba/history/samba-3.0.25b.html as well as
http://us1.samba.org/samba/history/samba-3.0.25c.html) for all printing
related changes and fixes since 3.0.10).

> I could send the smb.conf and
> cupsd.conf if you want to but it's kinda pointless because all setup was
> done as per your very good printing how-to (after drawing you the diagrams
> from the ASCII art for that how-to, time to make some good use of it, don't
> you think?! ;-) ). Drivers for the printer(s) were installed on the Samba
> server via the "add printer wizard" so first time a Windows box connects to
> the printer share the drivers get installed "automagically" on the local
> machine; since "root" has set up his printing preferences, miracle of modern
> technology, all drivers installed have the default values set for duplex,
> toner density, A4 and like. I chose the "smart Windows drivers - dumb CUPS"
> version because the print drivers running on Windows gave me more options
> (and is more "user friendliness") as compared to the CUPS's web page.
> Consequently CUPS queues were set-up as RAW and I'm telling you, this setup
> worked pretty well for more than a year up until (and including) CUPS
> 1.1.17. So I guess the config files should be OK?! :-o Oh and yes, I *DO*
> have "cups options = raw" in smb.conf
> 
> OK, there was one "small problem" though but it's not CUPS related, it's
> Samba. During the initial setup of the rig, for the Lexmarks T430 I had the
> option of installing two type of drivers: PCL or PS. Of course I jumped into
> PCL from the very beginning, but! If one installs a PCL printer driver in
> the above setup (that is Windows XP Pro, all updates in place and a Samba
> printer share, Samba acting as PDC) everything works well until you want to
> change some of the printer settings... Any of them; actually it's not the
> change it's pressing the "Apply" button on the driver's window. :-] The very
> next moment you "Apply" the settings XP freezes for like 2 or 3 minutes...

There were a few notorious PCL drivers (from HP as well as from Lexmark
and others) which caused this type of problems. Especially if the number
of "Dependent Files" for the driver was exceedingly large (I've seen insane
numbers like 70 or 80 .dlls or a single driver....).

This is *much* better now with newer Samba releases (but I'm not sure if
really *all* problems are fixed).

> When it comes back to life no settings have been applied. BTW, if someone
> knows the magic incantation(s) for this problem please step up! 

The only advice I could give (from the distance) is this: testdrive it with
the newest Samba release (and use CUPS 1.1.23 or the latest 1.2.x) and see
if this problem has gone away....

> After one
> frustrating week of mangling permissions and smb.conf I called it a quit and
> hesitantly changed to PS drivers so I can proceed with my installation. Well
> it worked, drivers installed and allowed me to change settings, I could
> set-up the whole thing the way I wanted, Windows PS drivers now outputting
> some sort of PS through Samba and then to CUPS RAW and from there to
> printer... 

This can only work with CUPS raw printing, if the print device is PS-
capable...

(Some devices can take PCL as well as PostScript, but need to be set up
for auto-switching their PDL language).

> All went well until the next update after 1.1.17 (which was like Dec. 2005
> if I remember well). After that date certain jobs submitted as before (I
> haven't changed a thing!) will pass through Samba, make it to CUPS but then
> vanish in a black hole; oh and CUPS will start using some 60% of the
> server's CPU time, 

It would be interesting to see if it is cupsd itself, or a filter or a
backend process which consumes the CPU...

> other jobs will start piling up... Sometimes the printer
> will emit one page with: 
> 
> ERROR: undefined
> OFFENDING COMMAND: @JPL
> 
> STACK:

This may be caused by Ghostscript filter, when a PostScript file has a
PJL header prepended....

But it also means that the printqueue is *not* fed with "raw" job data
(there may be a non-PS printer in the backend?)...

> ... Or something in the line of. I reverted to 1.1.17 for a while; Then
> subsequent CUPS releases in the 1.1 series fixed the CPU usage but didn't
> fix my problem. So here I am with a print server working in 3 cylinders,
> every now and then having to restart CUPS...
> 
> About the problematic documents: the problem shows up in some PDFs 

I assume you're printing the PDFs from some version of Adobe Acrobat
(Reader)? Which version?

The Acrobat printing is somehow different from printing of Office files
(it provides its own PostScript driver, and its print dialog allows for
all kinds of additional tweaks).

Have you played with settings like "print as image" for example? Or
with settings that

> never in
> "text" prints or Microsoft Office generated dox. Chances are "graphics
> intensive" HTML pages *when printed from Firefox* will also produce the
> problem. Adding insult to injury: take the VERY same HTML page and print it
> from Exploiter, works like a charm... makes no sense.

Which version of Firefox?

FF sometimes indeed does have problems creating a clean, valid PS file that
is processed without a problem by older versions of Ghostscript.

Firefox uses its internal PS-producing engine for print job creation, which
is different from what IE uses....

However, I've seen the same thing vice-versa: IE suffering print problems
with pages that printed alright from FF.

>> (Did you 
>> follow the Samba Howto Collection procedures to install the 
>> driver on the Windows Clients? 
> 
> I did! And, as I explained above, I had no choice but to use the PS driver. 
> 
> Maybe I should add some more details, someone might make good use of this.
> It is my deep suspicion that using a PCL driver would fix the problem for
> good! But then how to coerce Samba into cooperation? :-|
> 
> At least for those Lexmark printers (CUPS and Samba aside!) the PCL drivers
> are clearly "smarter" than the PS ones. Simple example(s): one PDF (which
> also produces the CUPS problem...) printed directly from XP to the
> aforementioned Lexmark printer, via USB, has a slightly different appearance
> "via PCL" as compared to "via PS"; fonts are slightly different...

I assume it is at least PCL 5?

PCL driver doesn't necessarily use the same fonts...

> Oh, a PDF
> printed via PS can "override" the page size but it won't do it via PCL... 

Yeah, that's a feature of the individual drivers...

> I
> know it sounds silly but that's how it is. What do you mean "it's a feature,
> it's not a bug!"? :-> Even more, this particular PDF comes out without the
> letters "i" via PS but comes out correctly via PCL! I've opened a case with
> Adobe and they said the PDF is "broken", something about the embedded fonts
> and that Adobe can not be held responsible for...

Did you yourself check the PDF with some kind of "preflight" software?

> Right. If it's broken why
> does it work via PCL? 

Probably, because the PCL driver generates pixelized images of the full pages
(or of the font's characters) and embeds this into the file...

> And why did it print very well via PS on CUPS
> v1.1.17?! :-|

You can still try to change the font settings in the Windows driver dialog
(there are options for TrueType fonts like "send as outline", "send as bit-
map" or "send as softfont")....


>> CUPS is always doing "auto-typing" of the job files 
>> (determine the MIME type of the data) by default (also for 
>> Samba submitted jobs), unless it sees the command line option "-o raw".
> 
> Critical question: Do I have to manually specify the option "-o raw" or does
> Samba insert it once I have the "cups options = raw" in smb.conf?! 
> 
>> In recent Samba versions you can set "cups options = raw" in 
>> smb.conf, which tells Samba to explicitely request raw 
>> printing from CUPS.
> 
> Oh, kinda answers my question above, doesn't it?! :-(

Yes, in a way, but not completely.... :-)

>> If CUPS auto-types a job as "application/octet-stream", it 
>> will not auto matically "pass the bucket", unless...
>>
>>  (a) either the "-o raw" commandline parameter is seen (for 
>> example be-
>>      cause of the "cups options = raw" in smb.conf), or
>>
>>  (b) application/octet-stream is generally enabled in the 
>> mime.types and
>>      mime.convs files of CUPS

I should *also* have hinted at the difference of the two things:

  (a) will cause CUPS raw printing for *all* Samba-supplied job
      files

  (b) will cause CUPS raw printing only if auto-typing determined
      'application/octet-stream' (and will apply the standard fil-
      tering chain construction for all other mime types).

> ... 've been here before. To be on the safe side I have both the raw Samba
> conf option and application/octet-stream in mime.*! :-z Neither helps... 

Hmm... maybe a bug in Samba, where it does not really pass the "-o raw"
parameter to CUPS?

(I *seem* to remember speculations about that some long time ago, for
some $version of Samba, but can't remember details...)

> Question remains: Why would CUPS be affected by something it is NOT supposed
> to look into?


One last idea you could try:

  (a) remove "printing = cups" and "printcap = cups" from smb.conf.
      This will cause Samba to now require and use the "* command = ..."
      set of options.

  (b) insert "printing = bsd", and also define all the commands to be
      used by Samba to pass the job to CUPS. For example:

         print command = "lp -d %p -t %J -o raw %f; \
                          rm %s; \
                          echo $(date): Printed and deleted jobfile %s submitted by %U from %m >> /tmp/smbprint.log"


      See 'man smb.conf' for details...

The trick here is to explicitely pass on "-o raw" in the print command
to see if this overrides or works around a potential bug in your Samba
version....

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany