Subject: Re: [netatalk-admins] Netatalk and OPI
From: Kadinger Andras (bandit@freeside.elte.hu)
Date: Sun Jan 24 1999 - 20:43:13 EST
Hello Hans, others,
On Sun, 24 Jan 1999, Hans-Guenter Weigand wrote:
> Lee Blevins <dgraph@tiac.net> wrote:
> IMHO the downsampling of image files is a key feature of OPI. Only the
> scanner operator and the Photoshop wizards deal with big files, but the
> majority of people does text and layout, and therefore work with the
> low-res files only. This is the only way to deal with these masses of
> data we have in prepress environments in an ethernet network.
I can't take it any longer! :)
When we bought our OPI system, I called our tech support, can't we please
turn off lo-res generation and actually substitute on OPI comments instead
of on the comments encapsulated in the lo-res EPS-es. They didn't
understand me, just as perhaps some of you wouldn't either at first, and
said this is crucial to OPI and can't be turned off.
But we use almost exclusively (more than 98%) Photoshop EPS and
Illustrator EPS files, where a lo-res file is unnecessary, since there
already is a 72dpi lo-res (Photoshop can even save it in JPEG as we all
know, I don't know about Illustrator since I haven't used it for a while)
in these files, so the files don't travel on the network in their full
size when imported into e.g. Quark - only the PICT preview is read and
embedded in the Quark document.
Of course, we do all our OPI-ed work in-house and don't need to be able to
give out lo-res files to clients to be able to do layout.
I think that lo-res files are 'evil' in this environment as it indeed was
proven in the last years for me: they get lost, they get corrupted or get
misplaced from the original, or the original gets misplaced but the in
this way invalidated lo-res (since the file itself is not changed) is not
marked as having any problems in Quark so people go and send them down,
just to find out their job doesn't print for some mysterious reason, or
worse yet, the job prints, but without images.
Of course the problem can be attenuated by educating users, keeping
strict order in files and buying a bug-free OPI software, but AFAIK this
is an imperfect world so sooner or later things will break somewhere.
[ The most ingenious solution for this problem I've seen was that of
Xinet's, where their server does server up the same data downsampled when
accessed through a different folder (I'm sure they cache this data as
well, they'd be crazy not to). Once I thought about incorporating
functionality into afpd, which would make certain tagged 'image' folders
show the lo-res or hi-res files based on which workstation and/or user was
trying to access them. So the same file would be 40MB on the
scanner/retouch workstation, and e.g. 1MB on the layout workstation.
But don't tell Adrian - he'd certainly kill me for this idea... :) ]
As for in-RIP separations (and also to induce some discussion on RIP
capabilities) our Harlequin RIPs do support in-RIP separation, verifiedly
with CMYK, but according to the docs also spot colors, since about three
years. But let me ask once again to check (I never tried really hard this
myself): does Quark support spot colors in it's composite output?
Regards,
Andras Kadinger
bandit@freeside.elte.hu
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:15 EST