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

[Ciprian Marius Vizitiu]

Oh Kurt, thanks a *LOT* for weighting in, I've been struggling with this
problem for... quite some time 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. 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...
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! 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... 

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, other jobs will start piling up... Sometimes the printer
will emit one page with: 

ERROR: undefined
OFFENDING COMMAND: @JPL

STACK:

.... 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 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.

> (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... Oh, a PDF
printed via PS can "override" the page size but it won't do it via PCL... 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... Right. If it's broken why
does it work via PCL? And why did it print very well via PS on CUPS
v1.1.17?! :-|

> 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?! :-(

> 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

.... '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... 

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