Re: [netatalk-admins] Netatalk and OPI


Subject: Re: [netatalk-admins] Netatalk and OPI
From: Hans-Guenter Weigand (hgweigand@wiesbaden.netsurf.de)
Date: Mon Jan 25 1999 - 17:30:41 EST


bandit@freeside.elte.hu (Kadinger Andras) wrote:

> On Sun, 24 Jan 1999, Hans-Guenter Weigand 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 corrected your tag line here, Lee Blevins didn't say such things :) ]

> 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

So you only use the OPI print spooler?

> 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.

This works fine in a Mac-only environment. But since intel started
shipping chipsets capable of addressing more than 64 MB RAM, we see more
and more guys working on PCs. Are there previews embedded in the (EPS)
image files?

Additionally I more than once thought about replacing XPress because of
its lack of stability, high price, almost non-existant support, etc. TeX
is what comes to my mind first. Does anybody here know how TeX would
handle OPI if one tried to run OPI without low-res image files? With
low-res EPS files containing the OPI comments every program, even if
completely unaware of OPI, becomes usable in prepress.

> 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.

You lucky one! Most of the customers I attend on are specialists, some
do layout only, some run plate recorders only, etc. Only one does
everything from editorship to print in-house.

> 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.

Same problems here. But in many cases data are shipped back and forth
until they reach their final state of manipulation. Maybe PDF is a
solution for some needs here.

> 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
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm not aware of such OPI software; that got me started ;)

> is an imperfect world so sooner or later things will break somewhere.
>
...
>
> 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

Ah, Harlequin. I've heard great things about it, but as an contracted
Linotype reseller we are not able to sell anything else than Linotype.
And because of their prices many old machines are still in operation,
like the PS-level-1 series of hardware RIPs up to model RIP40, running
on 16 MHz Motorola 88000 processors or something worse.

> 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?

Sorry, dunno...

-hgw



This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:15 EST