[plug] using CUPS & netatalk to do mac printer spooling

[James Devenish]

In message <3F962B65.80700 at postnewspapers.com.au>
on Wed, Oct 22, 2003 at 03:01:57PM +0800, Craig Ringer wrote:
> Anyway, the files. They're all on 
> http://www.postnewspapers.com.au/~craig/psjobs/
> and are:

Thanks heaps.  Right, here goes...

As you would know, PostScript files can be saved as "ASCII" or "binary".
These files can then be sent to printers over 7-bit or 8-bit
communications channels. In the case of LaserWriters, LocalTalk and
AppleTalk provide "pure/transparent binary channels", such that both
ASCII and binary files can be sent verbatim. (This is to say, LocalTalk
provides an 8-bit/octet channel for which no characters are used as
control sequences -- unlike telnet or a plain serial line, for
instance.) Therefore, LaserWriters accept PostScript according to the
Binary protocol (capital 'B').

The ASCII format is probably what is now (since 1992) known as
Clean7Bit, though binary format is still binary format. However, there
is also a Clean8Bit format that is different from binary. I think that
we will find UNIX PostScript files are either Clean7Bit or Clean8Bit,
not binary. It is probably only Macs (maybe not even Windows) that
generate binary.

In 1992, Adobe defined the BCP and TBCP protocols, which allowed octet
data to be sent over "impure" binary channels (ones that used ASCII
control characters for their own purposes). In additional, TBCP was
Adobe's recommendation for devices that could switch between different
languages. HP printers are such devices, because they can switch between
PJL/PCL and PostScript. However, HP printers only provide PostScript
emulation -- an incomplete and unlicensed version of PostScript. Now,
also consider the assumption that no one sends PJL/PCL to an AppleTalk
printer. So...all the HP printers that I currently have access to behave
like this: if a job is received via AppleTalk, it is *assumed* to be a
PostScript binary-format file sent using the Binary protocol. BUT if a
job is received via TCP/IP then language-switching takes place (the job
could be coming from any arbitrary OS) and PostScript is expected to use
the TBCP protocol to distinguish itself from PJL/PCL and plain-text
jobs.

I would guess that your Xerox also expects TBCP to be used for TCP/IP
jobs. I would suspect that the Xerox could be instructed, via a
PostScript control job, to expect Binary instead of TBCP. However, the
HPs are probably stuck on TBCP (even if you tell them not to do language
switching). Furthermore, although I think you can insert an "I am a
binary file" message into the PostScript file, I don't think the HP
printers would deal with it. So, you will either need to send your Mac
binary files via AppleTalk, or encode them with TBCP (I will soon
explain how to do this with CUPS).

It might be interesting to send one of your Quark jobs to port 9100 on
our Apple LaserWriters (e.g. they might assume Binary rather than TBCP),
but I won't bother.

The reason that GhostScript doesn't have a problem with binary files is
that a disk-based PostScript file is plainly either Clean7Bit, Clean8Bit
or binary. TBCP is irrelevant because it is only used during
transmission (not disk storage).

If you use TBCP to encode a Clean7Bit or Clean8Bit PostScript file, the
files emerge unchanged (this is based on my limited reading of Adobe's
docs last night). It is probably only binary-format files that are
altered by transmission with the TBCP protocol. So, if you `nc` your
Clean7Bit or Clean8Bit files to an HP printer, they will work fine
because they are equivalent to TBCP files (although they will lack the
handshake sequences at the start and end of the job -- the HPs can cope
with that omission since the files have the standard DSC header). You
only have problems if you send binary-format files that contain
sequences that would differ after TBCP encoding. I think this is the
problem you have experienced, Craig. The reason you get gibberish is
because the printers reject the document as invalid TBCP and then detect
the remainder of the transmission as a plain-text job (since it's
neither PJL/PCL nor PostScript).

If you have netatalk installed on a Linux machines, you should be able
to print your Quark docs to the HP or Xerox printers via AppleTalk with
no hassles. Use the `pap` programme. This is what worked for me (it was
only when I tried `nc` that printing failed).

The good news is that CUPS 1.1.19 contains support for BCP and TBCP. This
means that, rather than sending your binary files to the printers
unchanged, CUPS can TBCP-encode them for you. So, you now longer have to
run a second spooler or patch CUPS. Furthermore, since Clean7Bit and
Clean8Bit files are unchanged by TBCP encoding, I think you can
indiscriminately apply TBCP to all jobs that go through CUPS (regardless
of Mac/Win/UNIX/Linux origin). This TBCP encoding will be performed by
CUPS' pstops filter.

To enable TBCP encoding with CUPS, you add one of the following lines to
the /etc/cups/ppd/* files (this info comes from the CUPS documentation):
    *cupsProtocol: TBCP
    *cupsProtocol: "TBCP"
I don't know if you need the quotes or not. Don't indent the lines.

However, I notice that the HP PPDs already have:
    *Protocols: PJL TBCP
I don't know if this means that CUPS ignores the Protocols line or
whether it means CUPS' TBCP encoding does not aid your situation.
Hopefully it's merely the former!!!!

Let me know how it goes!

In message <3F976902.1030601 at postnewspapers.com.au>
on Thu, Oct 23, 2003 at 01:37:06PM +0800, Craig Ringer wrote:
> Unfortunately, adding that line (immediately under the *Protocols: line) 
> resulted in jobs not printing at all. The printer warms up, indicates an 
> incoming connection, then just stops as if there was no job ever sent. I 

Bummer. I have attached a careless C filter that can be used like this:
% gcc -o bin2tbcp bin2tbcp.c
% < quark_ad_rawqueue.ps ./bin2tbcp | nc -q 0 printername 9100
"Works for me (TM)", although the printer sends back the start-of-TBCP
and end-of-TBCP sequences and they are displayed on the terminal.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin2tbcp.c
Type: text/x-csrc
Size: 615 bytes
Desc: not available
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20031023/a9603ab6/attachment.c>