Subject: Re: [netatalk-admins] Netatalk and OPI
From: Lee Blevins (dgraph@tiac.net)
Date: Sat Jan 23 1999 - 09:43:31 EST
snip
>
> Why are you even bothering to archive the low-res? It's a) embedded in the
> document (QXpress or Photoshop or whatever) b) can be regenerated from tyhe
> hi-res by the sampler in a few secs anyway. Separate low-res/hi-res folders
> make more sense to me. Besides, tagging on suffices is all very well, but you
> run into the Mac's 31-char limit very quickly (and if it's on a Kanji
> system...)
You need to understand pre-press workflow a little better. We have an
obligqtion to the originator of the document to reproduce it exactly.
If ever there was an error and it was discovered that we re-made the low
res files, it would point the blame at us. It is very important that we
archive the job EXACTLY as it was printed. Same files, same fonts, same
documents.
However logical or illogical that blame pointing is, we have to deal
with the opinions and superstitions of our customers. So the golden rule
is don't change it unless there's an absolute need to do so.
In my environment, we don't use low res images most of the time. Most
documents come to us with high res in place. Quark allows the insertion
of OPI comments by selecting "omit tiff and eps" at print time.
To anyone considering programming an opi server I'd suggest a couple of
things:
1) Don't bother dealing with separations. The trend is to go to in-rip
seps and most high end equipment requires composite postscript.
2) Don't bother with low res generation. Many proxy files are very
specific to their opi server. There is a product call "Sampler" that is
freely distributed by Imation that creates a low res file that uses
standard OPI comments. Since a low res file is not required for OPI
(most apps support opi comments at print time) it could bog down the
process with work that's not needed.
I would think that a Netatalk OPI server could be developed quickly if
it were first limited to composite ps and application generated opi
comments.
The bulk of the programming work would be to re-write tiffs as binary
postscript. EPS files could be inserted as is.
Here's my (non-programmer thoughts)
1. Scan the file for OPI (%ADL....) comments and create an image list.
2. Search the paths to see if the images are there.
(Error on missing images.)
3. Re-write the postscript file with the high res inserted.
4. Spool file to rip or a monitored directory.
Advanced options could be an alternate image directory to look in if the
file is not found at the opi path of a method of entering the actual
path. I'd be leary of searching and entire network or server for missing
images since that could create some cpu overhead.
Anybody game on this "Simple OPI" code?
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:14 EST