Subject: FW: [netatalk-admins] Large print jobs with papd...

From: "Les Klein" <[email-masked]>
Date: Wed, 05 Aug 1998 11:49:10 +0100

Hi everyone

I have not had much luck with this problem and my users are unhappy. They
are trying to print 1200 dpi bit maps in 4 colours so we are talking about
1200x1200x4 BYTES per square inch. (This is becuase there are 8 bits per
colour in these bitmaps).
I.e. 5.76MB per square inch. Since the data needs to be sent in Hexadecimal
(ASCII) and not binary this means 11.5MB per square inch. An 8x10 print is
80 square inches so we're talking almost 900MB of data! 
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.
I don't mind spending time looking into the problem if some kind soul will
tell me where to look or what to do. As I said before I can give the
ethernet packet traces if anyone wants them.

I think that netatalk is a superb suite of code and I really want to be able
to succeed with it.

Regards

Les Klein :-(
----------
From: "Les Klein" <[email-masked]>
To: netatalk <[email-masked]>
Subject: [netatalk-admins] Large print jobs with papd...
Date: Thu, Jul 16, 1998, 4:55 pm

I have been unable to print files greater than 256MB via PAP from Macintosh
computers running OS8 and OS8.1 to my Linux box running netatalk 1.4.2b. 
If the file is bigger than 256MB only 268,414,976 bytes get rec'd by the
Linux box and then the PAP protocol seems to breakdown in some way since no
more data gets transferred. 
Printing the same files from these Mac's to an HP 2500 CP with PAP running
on the JetDirect card in the HP works fine so I am fairly sure the problem
is not at the Mac end of things.
Does anyone know anything about this?

Regards

Les.
PS: I can provide an EtherPeek packet trace if anyone needs one.

---

From: Peter Gutowski <[email-masked]>
Date: Wed, 5 Aug 1998 07:27:06 -0400 (EDT)

Les,

IMHO your users are dead wrong. They do not understand the technology.
Just because a device is capable of 1200 dpi doesn't mean that you should
provide continuous tone data at the resolution!!
I supervise a graphics production department with 4 imagesetters, digital
proofers, poster printers, etc. If anybody wanted to create a 900mb print
job my first reaction is that they're doing something wrong! 

Typically, a 1200dpi device will half-tone (or dither, or some other
similar process) the imcoming data. The general standard for source data
is a rsolution that is 2-3 times the linescreen. If your linescreen is 150
lpi then you probably need a scan in the 300-400 dpi range. Subject matter
does make a difference too: pictures of clouds require less resolution
than maps (or some other high-detail subject)

It's important to realize that just because a device can put a dot of ink
on the page at 1200 dpi, this doesn't mean that it can vary that dot size
in four process colors to make 1200 of continuous tone image. The relative
lightness or darkness of any color is accomplished by spreading dots over
an area or clumping them into a larger halftone dot. I would be surprized
if you could discern any *significant* differnce over 400 dpi of imcoming
data. Try it with some small test images and see!

---

From: [email-masked]
Date: Wed, 05 Aug 1998 09:01:21 -0400

> which just gets through using papd. Anything bigger than 8x10 and I hit the

The latest theory (from [email-masked]) 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.

:wes

---

From: Andras Kadinger <[email-masked]>
Date: Sun, 09 Aug 1998 14:09:20 +0200

> 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
[email-masked]