Subject: [netatalk-admins] Pre RIPing a document? (off topic)

From: Jonathan Benson <[email-masked]>
Date: Wed, 04 Nov 1998 14:16:02 +1100

First let me apologise for the off topic post but it struck me that some
of you may know the answer to the following.  If you don't know what RIP
is then you can stop reading here.

We have 2 main printers here (a Laserwriter II NTX and a Color
Laserwriter 12/660) that seem to be quite slow at doing what they do.

I know I can upgrade the onboard memory to improve the speed but I have
recently seen a Color photocopier/printer arrangement from Xerox (costs
far too much money) that has a server between the user and the printer.
The server pre RIPs the documents as well as caching them in a print
queue.

My question is, is there anything like this that would work with the
printers mentioned above?   Or am I doomed as they have to do the RIP on
the printer itself.

A Linux, Mac or Win 95/NT solution would all be welcome (in that order).

Thanks,
             Jonathan

--
Jonathan Benson B.Eng. (Soft Sys Hon) <[email-masked]>
Systems Administrator, Phoenix Magazines, Phone: +61 3 9696 7200
http://www.phoenixmags.com.au

---

From: "Douglas M. MacFarlane" <[email-masked]>
Date: Thu, 5 Nov 1998 14:36:29 -0600 (CST)

> My question is, is there anything like this that would work with the

I don't believe so, but I've been wrong before.

In the case of those printers, I don't think there is any way to
bypass the PS processing, and the size of the raster image would be
HUGE!! so that the time it took to send it ould be longer than the
onboard ripping.

Doug

Principal, Vauban Industries
[email-masked]

---

From: PayPC System Mail Subscriber <[email-masked]>
Date: Fri, 6 Nov 1998 20:50:28 +1000

Douglas M. MacFarlane said in Re: [netatalk-admins] Pre RIPing a document? 
(off topic) at 06/Nov/1998 (Fri) 06:36:29.

> > [...]
>[...]

Indeed, it would be enormous... unless you could exploit embedded PS raster 
compression, but I'd hate to even guess about if all of this hand-waving 
improve speed rather than diminish it.

Oddly enough, the "primitive" LaserWriter 300SC (SCSI, no Postscript) would 
be absolutely perfect for what you want to do (RIP on Linux, blast imaging 
data to printer).

I recall buying that printer almost exclusively for a job I was doing that 
made heavy use of 300dpi bitmaps.... (no need for PS at all, just Raster 
Blaster those bits' asses to the printer as fast as possible)... was an 
awesome setup.... max out the engine printing speeds on things that'd tie up 
the THEN top-of-the-line NTX for minutes.

Heheh.

Incidentally... I use a lot of HP Laserjet 4s here, which I've setup on 
TCP/IP just fine (MacOS 8.x can use 'em as LPR *OR* Appletalk devices... and 
here's an interesting thing I've exploited.  HP's speak PCL as well as PS, of 
course.  I use HylaFax as mainly an incoming fax pool/archiver/distributor... 
and when I print out the faxes...  rather than tiff2ps -2a'ing the fax 
images, I wrote a small tiff2pcl compressor (HP has something called "FASST" 
(sic) which is a bitmap compressor for PCL...  it sped up printing of "busy" 
faxes to like 1 second, rather than 70-100 seconds (per PAGE).  My code 
exploits the 600dpi of the printer, and the fact that fax dpi is "close 
enough" to an even division of that dpi to not worry about "proper" scaling.  
I cast the dpi to 200dpi (original's 204), and encode the bits without 
modification as 200dpi into FASST streams, and blast it forth to the HP via 
lpr (TCP/IP)... very high quality results [maybe 2% of the faxes which are 
"full" to every edge get a little cropped, but I don't mind re-printing those 
the "slow" way].

The encoding process on a 200Mhz K6 is less than a second for 5 page faxes... 
and I do it in two stages.... tiff2bin (bin is the raw packed bit format HP's 
FASST encoder expects), then bin2FASST it (which uses four different adaptive 
'nyms to efficiently pack rasters... it's quite good (has primitives for 
scanline replication, etc).

I know I know, this isn't a MacOS issue, but I'm pointing out that while PS 
is awesome for vector, typographic, etc.... it's like superslow and 
"unnecessary" for much of the bitmap imaging I encounter in the "real world".

=Rob=