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

Kurt Pfeifle k1pfeifle at gmx.net
Mon Aug 20 14:59:13 PDT 2007


Ciprian Marius Vizitiu wrote:

> Can someone please give me a short explanation for what is "RAW" supposed to
> mean when selecting a "Model/Driver" for a given queue? As opposed to say...
> "Postscript" or "HP"?

The contect of your question is not entirely clear. Are you asking from
the point of view of Windows client printing? Or from the point of view
of installing a printer into CUPS?

It is very similar for both, but there are slight differences.

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

However, Windows clients never have a queue without a driver, and cannot send
a job without some sort of driver interaction.

The Windows client queue (& driver) may be locally installed to the client,
or the queue may have been drawn via "point and print" from a Windows print
server (which may be a workstation sharing its printers -- or which even may
be a Samba/Unix/CUPS print server).

In the latter case (print server, but based on Windows), the driver is also
installed an the client -- but not fully executed. Basically it only serves
to show the printer driver GUI to the user to make his job selections. When
the user has done this, the job by default is sent off to the print server in
EMF (Enhanced MetaFile, the internal format of the Windows GDI subsystem); the
print server receives EMF and uses his driver to convert the job into the
final format (PostScript, PCL or what the case might be).

However, there is an option in the print dialog on the client to tell the
driver to send the file "RAW"; which tells the driver to execute locally
(on the client), and convert the EMF locally to the final print data format.

[In the case of Samba, this is the *only* option, and is automatically set up
internally -- because Samba-based print servers typically can not process and
convert EMF should they receive it].


> I mean let's assume that I have CUPS running on a Linux box with some
> Windows clients and that I chose RAW as the "Model/Driver"; and I do so
> because I have the Windows driver do all the heavy lifting. Given that for
> unknown reasons the Windows driver sends some sort of PostScript to the
> printer 

The only reason why "the Windows driver sends some sort of PostScript" is
when you install a PostScript driver. (Did you follow the Samba Howto
Collection procedures to install the driver on the Windows Clients? If so,

 (a) did you use the "cupsaddsmb" method or

 (b) did you install the native drivers into Samba using the "Add Printer
     Wizard" on Windows, or

 (c) did you install printqueue/driver locally on the Windows boxen? ["use
     client driver = yes" ?]

> (I would have expected it to be a binary blob), is CUPS supposed to
> look into or care about what's been sent to the printer (since the queue is
> set to be RAW)? Or should it just "pass the bucket"? 

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 commandline option "-o raw".

You can see what file format CUPS auto-typed by looking at the error_log
messages (you may see it saying "application/octet-stream", which means
'this is an unknown binary format, and there is no CUPS filter for this,
and I'll only send that to the printer if you explicitely tell me so').

In recent Samba versions you can set "cups options = raw" in smb.conf,
which tells Samba to explicitely request raw printing from CUPS.

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


Sorry if this sounds confusing -- but printing *is* a complicated thing,
especially if Windows clients are involved.

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




More information about the cups mailing list