Subject: Re: FW: [netatalk-admins] Large print jobs with papd...
From: Peter Gutowski (peterg@powervue.com)
Date: Wed Aug 05 1998 - 07:27:06 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!
On Wed, 5 Aug 1998, Les Klein wrote:
> 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" <les@psgroup.cix.co.uk>
> To: netatalk <netatalk-admins@umich.edu>
> 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.
>
>
>
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:02 EST