jsweet@slsaux.arc.nasa.gov (John Sweet) (03/02/90)
I'm finishing up a project which involved:
- Adobe's 300 dpi RIP in Mac-MPW library format
- Adobe Type Manager fonts
- Run-length compression
I'd like to share some of the things I learned, so
here goes..
GOAL: Allow "small-dollar" DTP users (primarily Mac users)
to export their work to the "big-dollar" Pre-press world.
So I need pixels from PostScript.
So I call Adobe, and after some negotiations, and
signing some reasonable papers, I get an Adobe RIP
(Raster Image Processor) in the form of an Mac MPW library.
It works like this:
1) fire up your favorite Mac application
2) use Command-K to make a PostScript0 file
3) exit your favorite Mac application
4) fire up you application which has been linked
to the Adobe RIP library.
5) pass your filename to the interpreter
6) pass a pointer to your "band function" to the
interpreter.
7) while you wait for the interprter to render the
page, your band function is called.
8) this band function can write the pixels to disk,
or compress the pixels and write them to disk.
9) your 300 dpi 8.5x11" page generates 2550x3300 pixels
i.e. 8 MegaBytes.
(NOTE: this is for 8-bit grey scale)
You can also generate CMYK and a bunch of other
LUT-based pixel data. you pass some parameters like the
number of color basis 1,3,4; the number of red, green,
blue, greys that you want in your LUT.
Step 3 is required because the library doesn't work
with Multifinder. You also need, 10-20MB of disk space,
and a (fuzzy) 2+ megs of memory.
If you want fonts (imagine that), you should buy the
$100 Adobe Type Manager font package which gives you
a shit-lode of fonts a 300 dpi for very little cash.
I was supprised that Adobe's technical support was
prompt, informed, cooperative and friendly. (Call me
a cynic, but it must be that good ol' free market
pressure.)
Results:
My band function used a simple run-length encoding
scheme on 64x64 pixel patches. "THE LOBSTER" which used
to take 8-Mb, now takes 400 kBytes. 20:1 compression.
This seems to be the average full-page of busy
graphics, fonts, etc. type of page. Yea, Yea I know
that a 8x10" black-white pattern fill will screw this
simple minded scheme, but 8-Mb some of the time is
better than 8-Mb all of the time.
Since I also wrote a Mac-based 300-dpi page preview,
run length encoding has another advantage: the screen
update time moves from being I/O bound to CPU bound.
In the uncompressed world, I needed to read 1 MB of
image data, but since the screen is only 1024 pixels
wide, I either need to read 2550 x 1024 pixels or
access the data at random with fseek(). Assuming the
SCSI drive is actually 500 kB/sec in non-random read,
and I must read 2.5 MB of data to update my 1 MB
screen, it takes me 5 seconds to read my data.
CopyBits will add another 1 second, to this time.
Well by 20:1 compression, I reduce my 5 seconds to
.25 seconds. I still have CopyBits, plus my decompress
time, which if it's optimized could (best case) take
as long as CopyBits. Thus my screen update time is
theoretically 2.25 seconds. In practice, on a Mac-2
the time is 4 seconds. Even in assembly with dbr.w
the decompression takes longer than CopyBits.
NOTE: On faster machines, we get faster times.
/* A PLEA for HELP follows: */
Now that I can get pixels and view them, I'd like
some HELP with some PostScript language tricks:
I'd like arbitrarily rotate and/or scale the page using
Postscript. Remember, I don't write the Postscript
source code. I am not a PostScript language guru - the
stuff barely makes sense when I stand on my head and
read it "C-style". I follow the matrix transformation
"trust-your-environment-to-be-compatible-and-pure" rhetoric
in the Adobe language manuals, but what kindof things are
lurking out there in the real world? Can I just make
the first line of postscript code, ??? rotate or ??? scale.
I'd like to RIP the files at 3000 dpi, but the
library is limited to 300 dpi. What kind of PostScript code
can I insert into these PostScript0 files, to magnify
and clip the "one-page" into many pages of "effectively
high resolution" pixel data. The designers I've talked
to sometimes need better than 300 dpi headlines, linework,
et al.
Thanks in advance,
John Sweet.
If you thought this was long-winded, you should see
how much code I had to write. Mac programming is mind-
knubbing --- Please Santa can I have a Sun.