Subject: Re: [netatalk-admins] papd problem - binary postscript

From: Les Klein <[email-masked]>
Date: Tue, 26 May 1998 09:11:56 +0100

> I saw someone has posted question about this, but no one replied.
> The problem is:
> When printing Postscipt file from Mac, something weird happens - papd
> consumes 90% of CPU while processing something unknown. Only beginning of
> the file is transmitted to the spool directory of lpr and nothing happens.
> I was waiting about 20 minutes and had to cancel print job from the Mac. I
> think something is wrong with the papd.
> The file was a binary postscipt - for ascii postscript everything seems to
> be ok.
> The transmitted fragment of postscript ends just before the beginning of
> binary data.
> The same thing happens when I try to print this file not from Mac, but
> using pap client.
> 
I have the same problem. Also, papd never closes PAP properly if the very
last character in a PostScript file is Ctrl-D ('\004'). Looking at the
source code for 1.4b2 it looks like netatalk/papd can not work with binary
files. It does however look quite easy to correct. Can anyone confirm/deny
this or say if they have already modified the code before I have a go?
Thanks

Les Klein.

---

From: "Robert O'Kane" <[email-masked]>
Date: Wed, 27 May 1998 20:57:24 +0200

Greetings,

   I think this question has been asked atleast 3 different times in
the last 2 months. (And has been answered atleast so many times).
Take a look into the archives for this problem.

(Yes there is an answer to this problem)

Bob.

---

From: "Robert O'Kane" <[email-masked]>
Date: Wed, 27 May 1998 21:01:38 +0200

Greetings again,

Sorry, I didn't read too carefully ...

> ..... Also, papd never closes PAP properly if the very

With the source code for netatalk 1.4b2 comes the man pages for papd.
It describes the problem you mention and how to call/start pap so
it can work arround these problems.

Robert O'Kane

---

From: Jeff Wiegley <[email-masked]>
Date: Wed, 27 May 1998 22:15:37 +0000

I don't know if its a problem with papd or the apple
printer port.

reports indicate that some (model not specified) apple printers
only communicate with binary data properly on the appletalk ports.

But if, as you indicate Les, its a problem with papd not handling
binary data correctly then I would love to see papd fixed. I don't
see a reason why a unix/netatalk tool should be so non-robust as to
be limited to handling only ASCII data.

If papd is really only ASCII enabled and there's a reason for it I
would love to hear about it.

- Jeff

---

From: Sak Wathanasin <[email-masked]>
Date: Fri, 29 May 1998 23:02:03 +0100

In reply to Jeff Wiegley's message of the 27/05/98 at 22:15 +0000,

> only communicate with binary data properly on the appletalk ports.

I don't know about the parallel port PS printers, but certainly with the serial
ports you can't send full binary because:

1) the PS interpreter uses XON/XOFF for flow-control (although you can switch
to h/w flow-control)

2) interprets control-T as a request for printer status

3) control-C is abort

4) control-D is EOF

or at least the Adobe PS does. If papd were to accept full binary in the
in-coming stream, it has to escape the above bytes before sending them out
through the serial port.

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [email-masked]
Phone: (+44) 1203 419996                    Fax: (+44) 1203 690690

---

From: Andras Kadinger <[email-masked]>
Date: Sat, 30 May 1998 12:53:15 +0200

> in-coming stream, it has to escape the above bytes before sending them out

Adobe has created an escaping mechanism exactly for these purposes, and
named it TBCP, or Taggged Binary Control Protocol. Someone has forwarded
a tiny TBCP C source to the list about a month ago which reportedly
solved people's problems in this area.

However, Your argument is perfectly valid to the point, that there
should be a tool in the netatalk package being able to do this
conversion; although that functionality should not be in papd (which
only processes input from the Macs to the spool), but in a separate
filter which people can use in their printcap entry: someone could have
both AppleTalk and serial port printers, in which case he would only
need to convert PostScript streams going to the serial one.

Hmm, I think I will wrap that thing up with some documentation and
(after checking copyleft policy) submit it to Adrian and/or Wesley for
inclusion.

Sincerely,
Andras Kadinger
[email-masked]