[Samba] samba2.2.7 with cups 1.1.14

[Kurt Pfeifle]

  Patrick Kwan wrote on Samba-digest:

> Message: 24
> Date: Wed, 11 Dec 2002 20:54:10 +0800 (HKT)
> From: "Patrick Kwan" <pat at pat.dyndns.info>
> To: <samba at lists.samba.org>
> Subject: [Samba] samba2.2.7 with cups 1.1.14
> 
> Dearl all,
> 
> I have setup samba2.2.7 with cups1.1.14.

As you seemed to be diligent enough to be current with your Samba
installation, you should maybe also upgrade to CUPS 1.1.17
(released a week ago, as compared to 1.1.14 which is from February
2002).

> In win2k client, the browse the printer share and install the
>  windows 2000 printer successfuly.
> 
> When I try to print some to it, nothing will be printed out.

If you apply the concept of using client-side printerdrivers (the
vendor-provided drivers for non-PostScript printers) on the Win
machines, the CUPS queue should be set up as a "raw" queue.

> I check the cups's error_log found the following message:
> "E [11/Dec/2002:20:35:43 +0800] print_job: Unsupported format
> 'application/octet-stream'!"

CUPS uses "MIME types" to categorize the autodetected file formats
of arriving print jobs. MIME type "application/octet-stream" essentially
is a unknown file format, like is generated by client-side running
vendor drivers.

However, by default, CUPS doesn't send unknown file formats to the
printer, not even on a "raw" print queue.

To enable this nevertheless, you need to remove the comment sign from
the beginning of the last lines of the two files "mime.types" and
"mime.convs" in "/etc/cups/".


Here is how it should read in "/etc/cups/mime.types":

---------------------> snip <--------------------------------------
# Uncomment the following type and the application/octet-stream
# filter line in mime.convs to allow raw file printing without the
# -oraw option.
#
application/octet-stream
---------------------> snap <--------------------------------------


Here is how it should read in "/etc/cups/mime.convs":

---------------------> snip <--------------------------------------
# Uncomment the following filter and the application/octet-stream type
# in mime.types to allow printing of arbitrary files without the -oraw
# option.
#
application/octet-stream    application/vnd.cups-raw      0     -
---------------------> snap <--------------------------------------

This says to CUPS it should treat "application/octet-stream" as a
printable format. The "-" means it should apply its "null-filter"
to it ("do nothing", no conversion at all), and the outcome of the
operation should be seen as "application/vnd.cups-raw" MIME type
(i.e. "ready to be sent to printer")

If you apply the concept of "client-side PostScript generation +
server-side PostScript interpretation", you should use the "CUPS
PostScript Driver for WindowsNT/2K/XP". It is available as
"cups-samba-1.1.17.tar.gz" at the http://www.cups.org/ download
area. Read "man cupsaddsmb" about details how to set it up. Basically,
"cupsaddsmb" will prepare the files for Samba (put it into the
[print§]-share, which is accessed by clients for driver download,
and initialize it), so that the clients can have a "point and print"
installation of the drivers. (For Win9x/ME clients you'll have to use
the Adobe PostScript drivers files). The printers don't need to be
PostScript (while the clients always use a PostScript driver for all
printer types), they just need to be supported by CUPS (see f.e.
http://www.linuxprinting.org/printer_list.cgi for all ~1000 supported
models....)

The big advantage is easy administration, print job accounting,
full job control for the clients, print quotas available and a few
more -- the drawback is a certain CPU power and RAM and storage
required on the CUPS/Samba server (for the processing/conversion
of the print files).

> Also, I check samba.log and the found the following message:
> "[2002/12/11 20:36:37, 0] printing/print_cups.c:cups_job_submit(654)
>   Unable to print file to cs100 - client-error-document-format-not-supported
> 
> What I need to check to solve this problem?

It's all in the docu. But I readily admit, when I initially
encountered the problem, I spent a few hours first trying all other
things, before I started to Read The Fine Manual...  ;-)

> Many thanks!
> 
> Patrick

Cheers,
Kurt