Subject: Re: [netatalk-admins] Netatalk and OPI
From: Kadinger Andras (bandit@freeside.elte.hu)
Date: Sat Jan 23 1999 - 11:23:24 EST
On Sat, 23 Jan 1999, Lee Blevins wrote:
> 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.
Hmm, but what about spot colors then? This is the only thing keeping me
from going composite...
> 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.
Yep, this was my intention as well.
> 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.
In fact, I have one working somewhat well right now.
> The bulk of the programming work would be to re-write tiffs as binary
> postscript. EPS files could be inserted as is.
libtiff (a TIFF handling library) has small utilities doing similar work,
although for me it seems not quite perfectly from a prepress perspective;
but that can be helped easily.
> 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.
I decided to take the 'easier' way out and err out on the fly if an image
is missing; this one-pass behaviour was much simpler to implement as a
testbed.
> Anybody game on this "Simple OPI" code?
Hmm, it seems I will have to put out what I have. I'll do so in a couple
of days.
Andras Kadinger
bandit@freeside.elte.hu
PS: Anybody having experience with Majordomo? I'd gladly start up an OPI
list if people want it and if someone volunteered to configure Majordomo
here.
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:14 EST