Subject: Re: FW: [netatalk-admins] Large print jobs with papd...
From: Andras Kadinger (bandit@freeside.elte.hu)
Date: Sun Aug 09 1998 - 08:09:20 EDT
wesley.craig@umich.edu wrote:
>
> > From: "Les Klein" <les@psgroup.cix.co.uk>
> > To: netatalk <netatalk-admins@umich.edu>
>
> > I have tried to persuade them to use lower resolutions but they are not
> > happy about this. Anyway at 600 dpi an 8x10 still requires 200+MB of data
> > which just gets through using papd. Anything bigger than 8x10 and I hit the
> > 256MB limit again.
>
> The latest theory (from A.DEURING@BIONIC.zerberus.de) is that this is a
> binary postscript problem. The 256M limit on your machine is your
> virtual memory. He has eliminated the problem with a heuristic that
> causes partial lines to be written, in the event of lines over some
> maximum with good results. I think a general solution would include
> implementing binary transmission in papd.
Since this would be essential for a reliable OPI implementation (my
users for example learned regarding PhotoShop images that they should
avoid anything ASCII and use binary instead, so they click on 'binary
postscript' in the laserwriter as well resulting in binary font
definitions and other binary data in the PostScript stream regardless of
papd telling the Mac not to send binary), I am rather willing to look
into this. I am looking at the source of papd and pap and am just about
to understand the C interface to ATP and PAP. However, I would
definitely benefit from someone explaining briefly, what's the idea and
reasoning behind papd's current comment handling.
An idea I came up with was to split papd into a purely communication
part (doing much the same as a PAP protocol stack would), and parts
doing the actual conversation with clients, responding to queries,
accepting and processing incoming data. This later part could then be an
OPI/Document Manager engine, an interface to the lpr or LPRng
subsystems, a simple responder piping the data to a file, or even pap
(e.g. to provide a transparent channel between client and printer for
real interactive queries), etc. Three pipes could be used: data to
printer, data to client, and status to client (striking resemblance to
stdin, stdout, stderr); this would retain full PAP communication channel
semantics, and make it relatively simple to write 'responders' (no need
to care about PAP and network details).
Has anybody done work in this area?
Sincerely,
Andras Kadinger
bandit@freeside.elte.hu
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:03 EST