Subject: procsets and papd

From: [email-masked] (Simon Gill)
Date: Thu, 15 Sep 1994 13:49:10 +0000

Dear Netatalk experts,

I would be very grateful if someone could shed some light on the use of
procsets in papd (part of the netatalk package).
I am using system 7.1 with laserwriter 8.1.1, printing to three printers
that use papd and lpd. The mechanism works well except a laserwriter II
NTX. The other printers are a HP4 with the correct ppd file, and a
Tektronix colour which uses an Indigo as the RIP, and I customized a ppd
file to work with this.

The laserwriter (II NTX) is connected to a UNIX box which is running nwi
filter for accounting. When a mac postcript job is created (print to file)
and printed from a shell with lpr or InterPrint the job will print, however
if the same file is printed via papd (ie direct) the job queues then is
flushed by the filter. I assumed the filter was to blame, but I think that
the procset we have 'AppleDict 71 0' could well be the culprit, as this was
created with Pagemaker (a bad printing program), and the procset is rather
large approx. 110K which does seems excessive.

What is the recommended procset for papd and laserwriter 8, and are there
any big problems with using laserwriter 8?

I have tried Laserwriter 7 too, but the same thing happens.

Many thanks
Simon Gill

____________________________________________________________________

Simon Gill
Department of Design   	       	       	       	       	       	
Brunel University
Egham
Surrey TW20 OJZ
United Kingdom
____________________________________________________________________

Tel:	+44 784 431341        	       	   email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Thu, 15 Sep 1994 21:20:42 -0400

>From:     [email-masked] (Simon Gill)
>  To:     [email-masked]
> 

I don't think that procsets have much to do with your problem, since
they are basically not used by the LW 8.x driver (it always sends the
entire job, which papd should pass along to the Unix printing system).
Several people have reported problems with some printing filter
software, etc.  that expects to see Unix newline-style end of lines.
papd does not convert the linefeed (Mac-style) end of lines that are
sent to it, and this apparently causes some printing software to choke.
[email-masked] proposed this solution: in your papd.conf file,
use a pipeline to do the conversion.  e.g.,

    printer:|tr '\015' '\012'|lpr -Pname

It is possible that your problem is due to other limitations in the
current papd implementation; it has never been revised to completely
handle the PostScript structuring conventions used by the 8.x driver.
We are working on a re-write that will.

-Mark