Re: [SLE] cups/ printing problem

• Previous message: Jack Malone: "Re: [SLE] konica 7812 printer"
• In reply to: Jack Malone: "[SLE] cups/ printing problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Tue, 9 Nov 2004 15:41:04 +0100 (CET)
To: suse-linux-e@suse.com

Hello,

On Nov 5 09:43 Jack Malone wrote (shortened):
> I'm using suse 9.1 here on our production server with samba running. Its seems
> several times a month printing will stop to one or all of the printers I have
> attached via network to this server. To solve the problem I kill all cupsd,
> then go into the queue an delete all old an current print jobs in the queue,
> then restart cupsd. Then I go an send a test print job from server to one or
> two of the printer an everything works again til the next time it happens. It
> was only happening once a month but now it seems to happen more often.

I.e. you print from Windows client machines via Samba
to a Linux CUPS server and some strange print jobs which are
sent from a Windows client machine can cause the whole CUPS
system to hang up somehow.

I guess that it is the CUPS filtering system which gets somehow
confused because for the filtering system the content of a print
job does matter.
In contrast the CUPS spooling system only receives and forwards
data and for the spooling the content of a print job should not
matter.

The crucial point is how you do the filtering.
Normally the filtering takes place on the Windows client machines
and you must make sure that there is no additional filtering
on the CUPS server.

When you print for example a PDF on a Windows client machine
and you have the printer specific driver installed on the Windows
client machine then it is no longer PDF which arrives at the
Linux CUPS server but it is arbitrary printer specific data.

Here a quote from two longer explanations which I sent to
someone else:

======================================================================

The problem is that the admin has several choices what to set up.
To choose the correct stuff depends on the actual situation
and the wishes of the admin. Therefore there is no one best way.
Therefore the admin needs understanding of the possibilities.

The real reason of all this problems is that the design how printing
works under Unix/Linux is different from how it works under Windows.

The admin must learn to keep spooling (the plain data buffering
and the plain data transfer) and filtering strictly seperated
in her mind.

Network protocols are only related to spooling.
Printer drivers are only related to filtering.

Of course spooling and filtering must cooperate to get a printout
but they are two different things.
Mixing up spooling and filtering causes so many confusion
and so many misconfigurations (and complaints about "bugs" which
are in fact only misconfigurations) result from this confusion.

The crucial design difference is:

Under Unix/Linux:
The client systems send the original data (e.g. plain text,
PostScript, JPEG) to the print server (to a print queue via LPD
or IPP protocol) and the print server converts it into the printer
specific format (the so called "filtering") and sends the
printer specific data to the printer.
I.e. the print server does spooling and filtering.

Under Windows:
The client systems convert the original data (e.g. plain text,
MS-Office documents, whatever-proprietary-formats) into the printer
specific format and then send the printer specific data to the
print server (to a printer share via SMB protocol) and the print
server sends the printer specific data to the printer.
I.e. the print server does only spooling.
The filtering is done on the client systems.

Consequences:

Under Unix/Linux:
The client systems don't need to care about the actual printer model.
It is only the print server which is responsible to do the model
specific stuff.
This is THE advantage of the design under Unix/Linux.
If an end-user has a laptop and connect it to a new network
where a CUPS server is running and if the end-user runs her
own cupsd on her own laptop, then she can immediately print.
See "Intrinsic Design of CUPS for Printing in the Network" under
http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html

Under Windows:
The client systems must care about the actual printer model.
I.e. printer drivers must be installed on the client systems.
This is THE drawback of the design under Windows.
Consider the problems when printers are added or exchanged:
Special software stuff (provide drivers for download) and
special end-user actions (driver installation/replacement)
are needed to deal with this situation.
If an end-user has a laptop and connect it to a new network,
then she cannot print without doing driver installation before.
Perhaps she doesn't want to download drivers from an
unknown/untrusted network system - what should she do?

Assume there is a network with Windows client systems and
a Linux print server should replace a Windows print server
then the following must be done on the Linux print server:

I)
Regarding the plain data transfer from the Windows client systems
to the printers (the "spooling"):
Spooling works without software which is called a "printer driver".

A)
For each printer there must be a matching print queue on the
Linux print server.

B)
For each print queue on the Linux print server there must be
a matching printer share so that the Windows client systems
have the usual receiver to which they can send their printer data.
Those printer shares are provided by Samba.

Alternatively the Windows client systems may be changed
to send their printer data not to a printer share via SMB
but directly to a print queue via LPD or IPP protocol.
If all Windows client systems are changed this way
then there is no need for Samba on the Linux print server.
It is no problem to let some Windows client systems send
their data via SMB/Samba to the print queue and let other
Windows client systems send their data directly to the queue
via LPD or IPP protocol.

II)
Regarding the conversion from the original data into
printer specific format (the "filtering"):
Here software which is called a "printer driver" is needed.

Either)
The filtering is still done on the Windows client systems:

Then the Windows client systems produce printer specific data.
Printer specific data is often random binary data.
A normal print queue on the Linux print server does not
accept random binary data because the Linux filtering system
would not know how to convert this into printer specific data
(remember the design difference above).
As printer specific data can be of random format (from random
binary data up to PostScript or PDF) it is not possible to have
a general autodetection mechanism for printer specific data.
Therefore:
When the filtering is done on the Windows client systems,
then the Linux print server must be forced not to try to filter
it again but to send it directly to the printer.
This is called "raw" printing (i.e. "raw" means "without filtering").
The CUPS printing system can be forced to do "raw" printing
by using the "-o raw" switch in the printing command
(e.g.: lp -d queue -o raw file-in-printer-specific-format).

If the Windows client systems send their data via SMB/Samba
then there is an option (as far as I know this is set by default)
in /etc/samba/smb.conf to enforce raw printing:
  cups options = raw
This way Samba which got the printer specific data via SMB
would forward it in raw printing mode to the print queue
and therefore the CUPS printing system will send it
directly (i.e. without additional filtering) to the printer.

If the Windows client systems send their data via LPD to
a CUPS print server then the raw option can be set in
the configuration for the cups-lpd (this is the daemon
which accepts data via LPD for CUPS) - see "man cups-lpd"
  -o document-format=application/vnd.cups-raw
All data which has the MIME type "application/vnd.cups-raw"
is not filtered but sent directly to the printer.

If the Windows client systems send their data via IPP to
a CUPS print server then it depends whether or not a raw
option can be set in the Windows IPP software.
If it cannot be set on the Windows client system then
the only reliable way to enforce raw printing on the
CUPS server is to create for each printer an additional
"raw" queue on the CUPS server (there is a manufacturer
"Raw" selectalbe when adding a printer via CUPS web-frontend
or in YaST you can set up a queue without filtering)
and let the Windows client systems send their data to
this "raw" queues. If there are only Windows client systems
in the network then it is sufficient to have only "raw" queues.

Or)
The filtering should be done on the Linux print server:

Normally the filtering system on a Linux print server cannot
convert MS-Office documents or whatever-proprietary-formats
into printer specific data because there is no approriate
filtering program available.
Normally the filtering system on a Linux print server accepts
plain text, PostScript, JPEG (and some other graphics formats).
Therefore the Windows client systems must produce one of
those accepted formats.
As PostScript is THE standard printing language under Unix/Linux
the usual solution is to install a special kind of filtering
(i.e. a special kind of printer driver) which produces PostScript
on the Windows client systems.
In most cases one of the following two PostScript printer drivers
are used on the Windows client systems:
The "CUPS Driver for Windows" - see
http://www.cups.org/windows.php
or
the "Adobe PostScript printer drivers" - see
http://www.adobe.com/products/printerdrivers/main.html

Result:
When the filtering should be done on the Linux print server
then there must be also a pre-filtering-into-PostScript done
on the Windows client systems.

----------------------------------------------------------------------

Please note that I described only the usual case!

The following is background information.
You may ignore it because it may become too complicated.
But please have in mind that there are some other possibilities
and refer to the Samba-HOWTO for more information.

Of course it is possible to convert the original data into the printer
specific format on a Linux client system and let the Linux print
server do only the spooling.
This must be done when a Windows SMB print server is used, see
http://portal.suse.com/sdb/en/2003/11/jsmeix_print-smb-90.html

When CUPS is used both is possible (filtering on the client or
on the server) but usually the filtering is done on the server.

And it is possible to a certain extend to do the conversion
into the printer specific format on a Windows NT print server:
Not from the original data into printer specific data but
from EMF format into printer specific data.
The drawback is that the EMF format is to a certain degree
printer dependent: Note the "driver info" in the pictures below.

See

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/CUPS-pr
inting.html#id2561305

or for bigger pictures see

http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO
WTO-Collection-3.0-PrintingChapter-11th-draft.html#14_8_1

PostScript is the standard printer language under Unix/linux.
To a certain degree EMF is the analogon under Windows.
See

http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO
WTO-Collection-3.0-PrintingChapter-11th-draft.html#14_6_1

The case "Driver Execution on the Server" under Windows

http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO
WTO-Collection-3.0-PrintingChapter-11th-draft.html#21_3

is the analogon to what I described later under
"The filtering should be done on the Linux print server:"

The Windows NT possibility "Driver Execution on the Server"
can be transformed into what I described under
"The filtering should be done on the Linux print server:"
and the matching picture is here

http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO
WTO-Collection-3.0-PrintingChapter-11th-draft.html#14_8_2

In contrast the usual Windows case "Driver Execution on the Client"

http://www.linuxprinting.org/kpfeifle/SambaPrintHOWTO/Samba-HO
WTO-Collection-3.0-PrintingChapter-11th-draft.html#21_2

can be transformed into what I described under
"The filtering is still done on the Windows client systems:"

======================================================================

Regards
Johannes Meixner

-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix@suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/
-- 
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@suse.com
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@suse.com

• Previous message: Jack Malone: "Re: [SLE] konica 7812 printer"
• In reply to: Jack Malone: "[SLE] cups/ printing problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]