Subject: Re: [netatalk-admins] Netatalk and OPI

From: [email-masked]
Date: Tue, 19 Jan 1999 23:35:09 +1300

On Wed, Jan 13, 1999 at 07:36:45PM -0500, Lee Blevins wrote:

> Is there any interest in seeing netatalk perfom OPI? 

[snip!]

> Perhaps there should be another application that performs this. 
> Is it possible to make netatalk just recieve the postscript file from a
> workstation and deposit it in a directory? 

The answer to your questions, IMO, are no, yes, yes.

Before I go too much further, let me say I've looked at OPI functionality to
the extent of implementing basic, semi-functional systems for OPI 2.0 and
PCI[1] that worked with netatalk.  I never got these to a releasable state
due to a lack of CFT, but keep meaning to (encouragement welcome 8).

Having netatalk perform OPI functions really makes no sense (to me, anyway). 
OPI servers perform essantially two functions: ripping image files apart;
and manipulating PostScript streams.

The first function is really the job of a daemon scanning directories for
files, dissassembling them, and spitting out an appropriately-formatted
low-res image somewhere.  I personally have a Perl/ImageMagik combo that can
do this for a limited subset of cases; the only way in which netatalk need
to be involved is making sure the resource forks are copied and manipulated
correctly, which is more an issue of the application being netatalk aware
than anything else.

The second is simply a case of reaming through PostScript on its way to the
printer, checking for desired hooks (OPI and DCS comments, for example), and
acting appropriately on them.  Again, I've got a Perl script lying around
tyat can do this for a limited set of cases.  Integrating this
functionality into papd would IMO be a mistake, adding needless bloat and
complexity to it; it would also mean that the development cycle of papd
would either constrain or be constrained by the development cycle of the
OPI.  And, for me, there's the fact that this scheme would be useless for
anything but devices printing via AppleTalk.  I'd like something that works
with AppleTalk, standard *ix lpd, SMB, and whatnot.

And finally, yes you can indeed use a filter for capturing papd data: one of
my papd shared printers here at work picks up PostScript data, writes it to
a temporary file, and then uses GhostScript to rip it to a PDF.  By having
the line

	:if=/var/spool/lpd/acrobat/filter:

in the /etc/printcap entry, the STDIN of the lpd is directed through the
filter script, which automagically handles the capture and runs ps2pdf.

Of course, as with most things, the devil is in the details.  To actually
hack up something I'd feel comfortable releasing, I'd have to spend some
time hammering on actual, rather than contrived test, cases, to pick up the
real work inanities of semi-conformant image handling and PostScript
generation.

[1] An simple OPI format dreamed up by ATEX and Autologic.

-- 
Rodger Donaldson			[email-masked]
Systems Support				Direct line	: 04 474 0560
Wellington Newspapers Limited		Fax		: 04 474 0309
You are in a maze of twisty little companies, all working against each other.

---

From: [email-masked] (Hans-Guenter Weigand)
Date: Tue, 19 Jan 1999 23:44:23 +0100

> > Is there any interest in seeing netatalk perfom OPI? 

(Sorry for jumping in at this moment, I subscribed to the list
yesterday.)

Yes, I'd love to see a fully functional free OPI based on netatalk. We
(at work) resell Helios EtherShare/OPI and maintain the installations.
After dealing with this software for nearly two years now I came to the
conclusion that Helios really sucks. It is unstable and unreliable,
dumps core every few moments, and is limited to 250 users at the moment.

> the extent of implementing basic, semi-functional systems for OPI 2.0 and

Do you refer to an OPI specification 2.0 or the Helios OPI 2.0 product?

> The first function is really the job of a daemon scanning directories for

Actually this is the main problem IMHO. There has to be a way to inform
the OPI process that a user has put a file into the server volume. The
downsampled layout-file has to be available within a few seconds. Users
sit at their Macs, finish an image in Photoshop, copy it to the server
volume, switch to Quark XPress, and want to use the layout-file
immediately. If it is not there, they keep my phone ringing...

So scanning a volume doesn't work here. This would take tens of minutes
until a new file is discovered, since OPI server volumes nowadays range
from 60 to 200 GB and more.

> functionality into papd would IMO be a mistake, adding needless bloat and
[snip]

Yes, I agree. /etc/printcap is the right place to engage filters for
processing print jobs containig OPI stuff. And nowadays Macs can print
using IP/lpr, so you may not need papd at all. An OPI version of papd is
the wrong way.

-hgw

---

From: [email-masked]
Date: Wed, 20 Jan 1999 20:15:27 +1300

> Do you refer to an OPI specification 2.0 or the Helios OPI 2.0 product?

OPI spec 2.0.  

> the OPI process that a user has put a file into the server volume. 
[...]
> from 60 to 200 GB and more.

Actually, it isn't that hard.  And, moreover, tying the scanner to netatalk
hurts portability (you'd have to have a whole 'nother bunch of integration
for Samba, NFS, CODA access, for example), which in turn imapcts on
utility[1].

The main loop of the daemon should use a stat() on eached configured input
directory, on only check the contents of the directory once the stat(). 
That makes checking nice and lightweight.  Stealing from the Colour Central
model, a directory structure that looks like:

sharepoint------> Inbound Files
             |
             |--> High-Res Files
             |
             |--> Low-Res Files

...allows me to keep the inbound queues low by moving hi-res files into
another directory.  Since I only have to traverse small directories, and
only do it when a lightweight stat() tells me something has actually
changed, it means the turnaround should be limited mainly by processing the
low-res.

> The downsampled layout-file has to be available within a few seconds.

Which requires some serious grunt 8).  

There are some intresting potential tradeoffs here; for example, one could
have a single checking daemon which does a stat() every second, and if a
change is recording, then determines what new files are present and then
conditionally exec() a handler for it.  The admin could then configure how
many queues are available and how deep those queues are (do you allow one,
two, three, or more items to be processed in a given queue).

Anyways, all this talk inspired me to dig up the old code this morning.  I
took one look at it, threw most of it away, and am now happily banging away
at FreePO[2] again.

[1] For me, anyway; YMMV.
[2] Free Perl OPI.  Doubtless all the quick bits will be rewritten in C one
    day.

---

From: [email-masked] (Hans-Guenter Weigand)
Date: Thu, 21 Jan 1999 21:24:11 +0100

> > Do you refer to an OPI specification 2.0 or the Helios OPI 2.0 product?

URL available?

[Scanning the volume]
> for Samba, NFS, CODA access, for example), which in turn imapcts on

Uh, yes, I forgot about NFS and the PC world. Helios Ethershare seems to
work like this: A file copied to the volume from a Mac instantly is
checked for type, and a layout file is generated if appropriate. If you
copy it there using NFS, you do not get a layout file. Their afp-daemon
notifies the opi-daemon, which forks and downsamples the image file. If
you bypass the afpd somehow, you have to touch the file from a Mac to
trigger the opid. This model offers prompt service to Mac users, but
obviously has some disadvantage.

> changed, it means the turnaround should be limited mainly by processing the

Prepress people here are used to a different model (which I would
prefer), which places the layout files into the same directory as the
hires files. "mypic.tiff" gets a little brother named "mypic.tiff.lay".
This makes it easier to handle both image and XPress (or PageMaker)
files in the same dir. If you separate the image files into different
dirs you make it more difficult to archive finished and printed jobs. An
average path looks like this in the ufs:
"<sharepoint>/<customer>/1998/<jobnumber>/". All files go into the
<jobnumber> folder, possibly with some subfolders. Once the job is done
its folder is put on CD and/or other media and deleted from the server
volume. There's never enough disk space  ;)

> conditionally exec() a handler for it.  The admin could then configure how

Can you give some impression of the time needed to find the new image
file in a, say, 100 GB ufs volume (with reduced number of inodes)? I'm
quite new to Unix programming and now little about wheels and gears
inside yet.

> two, three, or more items to be processed in a given queue).

Isn't it sufficient to start a downsampling process with nice +10 for
every detected new file? The kernel would have to handle "queuing" then.

> took one look at it, threw most of it away, and am now happily banging away

Fine! Let me know if and how I may help. I run OpenBSD-current and
Solaris (2.)7 here, and MacOS of course.

> [2] Free Perl OPI.  Doubtless all the quick bits will be rewritten in C one

Isn't there some p2c utility, which does the dirty work?

-hgw

---

From: "Volker Birk" <[email-masked]>
Date: Thu, 21 Jan 1999 21:57:59 +0100

> URL available?

http://partners.adobe.com/supportservice/devrelations/technotes.html
http://partners.adobe.com/supportservice/devrelations/PDFS/TN/OPI_2.pdf
http://www.inforamp.net/~poynton/ICC_3.0a/icc-0.html

VB.
--
*** ebis Informationssysteme, Germany       ***  BUGS:
*** Gut-Betha-Platz 1, 88339 Bad Waldsee    ***    This manpage is confusing
*** Phone +49-7524-93421 Fax +49-7524-93423 ***
*** mailto:[email-masked]    http://www.ebis.de ***

---

From: [email-masked]
Date: Fri, 22 Jan 1999 18:54:04 +1300

> > > Do you refer to an OPI specification 2.0 or the Helios OPI 2.0 product?

It isn't available from their web site, but you should be able to find it at
ftp://www.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/opi_2.pdf

> Uh, yes, I forgot about NFS and the PC world.

Something many people would like tro be able to do 8).

> Helios Ethershare seems to work like this: A file copied to the volume
> from a Mac instantly is checked for type, and a layout file is generated
> if appropriate. If you copy it there using NFS, you do not get a layout
> file. Their afp-daemon notifies the opi-daemon, which forks and
> downsamples the image file. If you bypass the afpd somehow, you have to
> touch the file from a Mac to trigger the opid. This model offers prompt
> service to Mac users, but obviously has some disadvantage.

Quite.  As I indicate, I think we can offer prompt service on a cross
platform basis to everyone, which would be the ideal.  Reading your
description did get me thinking about optimal ways of downsampling though;
previously, I'd just worked from the notion that one does a downsample from
a big file.  Thinking about how Helios could be hooking into their afpd
analogue for more speed got me onto a slightly better (and should have been
more obvious): checking the resource fork and the PostScript for embedded
previews.  That way, one could deliver low-res samples with pretty
impressive speed; we'd only bog down on files that don't have a preview
already.

> prefer), 

Configurability is everything 8).

> which places the layout files into the same directory as the

That's straightforward enough, however...

> An average path looks like this in the ufs:
> <jobnumber> folder, possibly with some subfolders. 

Does this mean that you have the Helios OPI watching every job folder?  In
that case, I can can see the value in hacking the afpd analogue to talk to
the sampler, because that would get a little more awkward without
co-operating with it.  Not impossible, but it would be harder to implement
elegantly.

> Once the job is done its folder is put on CD and/or other media and
> deleted from the server volume. There's never enough disk space ;)

Amen to that.

> quite new to Unix programming and now little about wheels and gears

Depends on whether you search the whole hierarchy or not; I also don't have
a UFS volume handy.  I'll get some times across some 10-24 GB ext2 fses over
the weekend, and take it from there.

> every detected new file? The kernel would have to handle "queuing" then.

That's one way; OTOH, one may want to specify some queues as more equal than
others - you might have a queue set up for people who are scanning work a
few days in advance (something we do here, begin a newspaper), where the
ability to get everything sampled all at once, as quickly as possible, is
lower priority.

> Solaris (2.)7 here, and MacOS of course.

Excellent.  I have access to Linux, MacOS, Windows and AIX, although the
bulk of the initial work will be on Linux.

> Isn't there some p2c utility, which does the dirty work?

That's a pascal to C translator.  There's not actually that collosal a
difference between Perl and C for a lot of work; moreover, for a lot of the
work being done here - mucking about with PostScript streams - perl most
likely handles the text involved better than any C I can write ever will. 
The filesystem stuff may be a different matter.

I'll spend some time hacking over the weekend and make the results
available early next week.  We should probably take the discussion away from
netatalk-admins, unless we start trying to integrate stuff into netatalk,
although I don't have a listserv of my own.

---

From: Sak Wathanasin <[email-masked]>
Date: Fri, 22 Jan 1999 00:39:14 +0000

In reply to Hans-Guenter Weigand's message of the 21/01/99 at 21:24 +0100,

> average path looks like this in the ufs:

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

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [email-masked]
Phone: (+44) 1203 419996                    Fax: (+44) 1203 690690

---

From: Thomas Liesner <[email-masked]>
Date: Fri, 22 Jan 1999 09:45:01 +0200

Hi, i'm following this diskussion for a while now.
Unfortunatly i'm not into programming.
Therefor only that much:

The link is actually
ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/opi_2.pdf
(not www.adobe.com)

I'm using Helios Ethershare 2.5 and Helios OPI 2.0 with PDF Handshake
and Print Preview on a Sun Ultra Enterprise 450.
I'm not much of a unix-wizard, but if i could be of any help, just let
me know. I'd really like to see an OPI-Server running on a linux-box.

regards

Thomas

---

From: [email-masked] (Hans-Guenter Weigand)
Date: Sat, 23 Jan 1999 01:48:02 +0100

> Something many people would like tro be able to do 8).

As you see, I sometimes really do. It's easy, just try! Start by sitting
down in front of a Macintosh. :)

> impressive speed; we'd only bog down on files that don't have a preview

But only if the preview matches the settings for the layout file. If you
just downsample a tiff file from 300 to 72 dpi you get a really small
file, but you lose quality. It is better to use jpeg with some low
quality, because it gives you the same file size, but a much better
quality for the low-res file, or a smaller file with the same quality as
the 72 dpi tiff.

BTW, Helios has a nice feature to adjust the resolution of the low-res
files. If a folder's name ends with '%36', all files generated in this
folder and every folder below have 36 dpi, '%0' suppresses the
generation completely. If someone works with poster size pictures, 18
dpi is really enough.

> Does this mean that you have the Helios OPI watching every job folder?  In

No, it watches the whole volume(s) automatically. There is no way to
configure anything.

> co-operating with it.  Not impossible, but it would be harder to implement

It would make more sense to hack the kernel's fs code. This makes it
compatible with NFS, samba and friends. But I think it is not worth
trying, it is completely unportable.

> Depends on whether you search the whole hierarchy or not; I also don't have

Whole volume, i.e. shared folder respectively...

> the weekend, and take it from there.

ext2fs should be OK, since it is mostly a reimplementation of the
Berkeley ffs used by all *BSD variants. ffs is called ufs in Solaris.
The main difference between ffs and ext2fs IMHO is the asynchronous
writing of meta information. This can be turned on in ffs, but is
discouraged. I never lost files on a ffs even when the machine crashed
every five minutes. But ext2fs under Linux once lost many files after a
single crash and forced me to reinstall. So ext2fs is somewhat faster,
but a bit unsafe. I would never use it in a production environment. This
is not a prejudice, just experience.

> That's one way; OTOH, one may want to specify some queues as more equal
> than others - you might have a queue set up for people who are scanning
> work a few days in advance (something we do here, begin a newspaper),
> where the ability to get everything sampled all at once, as quickly as
> possible, is lower priority.

Queueing meens to make it more complicated for the users. Keep it as
simple as possible. Actually, an OPI-server needs to have enough CPU
power. That's the way we make our living by selling big machines. :)

But I do not completely understand how you want do manage queuing. How
does it look to the user?
 
> That's a pascal to C translator.  There's not actually that collosal a

I meant a Perl-to-C translator. Forgot about Pascal, sorry! ;)

> The filesystem stuff may be a different matter.

Can't Perl call compiled modules written in C? I think I read about this
somewhere.

> although I don't have a listserv of my own.

OK. Reply-to set.

-hgw

---

From: [email-masked] (Hans-Guenter Weigand)
Date: Sat, 23 Jan 1999 01:48:00 +0100

> Why are you even bothering to archive the low-res? It's a) embedded in the

They are not archived, but they have to be present during the whole
production process. A subfolder named 'layout' is also common practice.

Quite often Xpress files and the low-res files are given to external
people for layout purposes. When these files return, their OPI paths
still must match.

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

Mmh, good point. But few people use (too) long names. They seem to
prefer deeply nested folders, which makes the pathnames long, not the
filenames.

And I doubt that there is a Kanji-savvy commercial OPI software running
on Unix...

-hgw

---

From: [email-masked] (Lee Blevins)
Date: Sat, 23 Jan 1999 09:43:31 -0500

snip
> run into the Mac's 31-char limit very quickly (and if it's on a Kanji

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?

---

From: Kadinger Andras <[email-masked]>
Date: Sat, 23 Jan 1999 17:23:24 +0100 (CET)

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

> process with work that's not needed.

Yep, this was my intention as well.

> it were first limited to composite ps and application generated opi

In fact, I have one working somewhat well right now.

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

> 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
[email-masked]

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.

---

From: Magnus Stenman <[email-masked]>
Date: Fri, 22 Jan 1999 12:26:07 +0100

How about patching afpd and samba to notify (pass the inode or whatever)
a OPI daemon via a local only socket everytime a
directory has been modified?

If this is configurable per share/directory,
and doesn´t slow down normal operation, perhaps
it might even be a standard part of afpd/samba.

Possibly, there would have to be an intermediate
daemon to queue those notifications to avoid
afpd/samba slowing down too much (or multithread the OPI daemon).

/magnus

---

From: Sak Wathanasin <[email-masked]>
Date: Sun, 24 Jan 1999 01:21:06 +0000

In reply to Hans-Guenter Weigand's message of the 23/01/99 at 01:48 +0100,

> people for layout purposes. When these files return, their OPI paths

The hi-res path must be the same*; the low-res file is not used at all during
printing: it must be embedded in the PS stream, otherwise the OPI server never
sees it.

> prefer deeply nested folders, which makes the pathnames long, not the

There's a 255-byte limit on Mac pathnames as well.

> And I doubt that there is a Kanji-savvy commercial OPI software running

Maybe not on Unix, but I worked on one for the Mac...

* Most commercial OPI servers will also allow you to specify a number of
default folders to look in if it can't find the original path; the one I worked
on certainly did.

>From your other message:

> file, but you lose quality.

Only if you're talking about print quality; there is no loss in screen-display
quality. That is because the Mac only displays at 72 dpi. Photoshop/QXpress etc
effectively all "downsample" (or rather QuickDraw does) as they draw to the
screen. It has to do it every time it redraws, and of course, all operations
apply to every pixel in the original hi-res, even though you only see the
effects at 72 dpi, which is why uisng the low-res is such a big win.

> No, it watches the whole volume(s) automatically. There is no way to

Yuck; no wonder you guys complain.

Sak Wathanasin
Network Analysis Limited

Internet: [email-masked]

---

From: [email-masked] (Hans-Guenter Weigand)
Date: Sun, 24 Jan 1999 23:54:49 +0100

> The hi-res path must be the same*; the low-res file is not used at all
> during printing: it must be embedded in the PS stream, otherwise the OPI
> server never sees it.

Right.

> There's a 255-byte limit on Mac pathnames as well.

Helios Ethershare has a limit of 100 characters for the absolute Unix
path. So why bother?  :)

> default folders to look in if it can't find the original path; the one I
> worked on certainly did.

Right. But most pictures are job-specific, so this fallback works in
almost no case.

> Only if you're talking about print quality; there is no loss in
> screen-display quality. That is because the Mac only displays at 72 dpi.
> Photoshop/QXpress etc effectively all "downsample" (or rather QuickDraw
> does) as they draw to the screen. It has to do it every time it redraws,
> and of course, all operations apply to every pixel in the original hi-res,
> even though you only see the effects at 72 dpi, which is why uisng the
> low-res is such a big win.

The aim of downsampling is to minimize the file sizes used for layout
purposes. My idea is to increase the quality of these pictures while
keeping their size, or keep the quality and decrease the file size even
further. 

> > > Does this mean that you have the Helios OPI watching every job folder?
> >

OK, I was a bit wrong here. You can turn off the creation of low-res
files for a volume or use a suffix for folder names. But this is not the
point of my complaints. Helios is very fast in the creation of new
low-res files. There is no need to configure it to make it faster there.
This software suck in other concerns.

-hgw

---

From: [email-masked] (Hans-Guenter Weigand)
Date: Sun, 24 Jan 1999 23:54:47 +0100

> seps and most high end equipment requires composite postscript.

Separation made by XPress and other programs is needed in most cases
today, since most RIPs I know of have in-RIP separation only as an
announced future feature. And many color prints are made using Pantone
colors.

> process with work that's not needed.

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.

-hgw

---

From: Kadinger Andras <[email-masked]>
Date: Mon, 25 Jan 1999 02:43:13 +0100 (CET)

Hello Hans, others,

> 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
[email-masked]

---

From: [email-masked] (Lee Blevins)
Date: Mon, 25 Jan 1999 07:01:10 -0500

> myself): does Quark support spot colors in it's composite output?

The two most common systems seen in high end commercial printing are
Rampage and Scitex. Both systems allow spot colors with composite eps
input.

---

From: [email-masked] (Hans-Guenter Weigand)
Date: Mon, 25 Jan 1999 23:30:41 +0100

> > data we have in prepress environments in an ethernet network.

[I corrected your tag line here, Lee Blevins didn't say such things :) ]

> of on the comments encapsulated in the lo-res EPS-es. They didn't

So you only use the OPI print spooler?

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

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

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

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

> myself): does Quark support spot colors in it's composite output?

Sorry, dunno...

-hgw

---

From: Andras Kadinger <[email-masked]>
Date: Wed, 27 Jan 1999 09:10:07 +0100

> [I corrected your tag line here, Lee Blevins didn't say such things :) ]

Oops, I apologize. I'm not yet very proficient at using pine...

> So you only use the OPI print spooler?

Since must use lo-res images we don't, but we'd be glad to.

> and more guys working on PCs. Are there previews embedded in the (EPS)

Hmm, good question. I think there are some provisions for that, but I
haven't looked at more closely. However, I think there should be, since
Quark certainly can't interpret Photoshop EPSes but still displays a
preview. Yes, now I remember; there is possibility for a TIFF preview to
be stored with the actual PostScript data.

> Does anybody here know how TeX would

I see, and I agree; still we (I mean at my workplace) don't need that,
and besides it might speed up things if a 'lores-less' version is
circulated since that's apparently closer to happen that if we had to
implement all the lo-res generating stuff from the beginning.

> > strict order in files and buying a bug-free OPI software, but AFAIK this

Yep, that was what I meant. Exactly. :)

> on 16 MHz Motorola 88000 processors or something worse.

Hmm, this could be a valid concern from the aspect of anticipating
compatibility issues indeed. I for one was for not bending over the back
to be Level 1-compatible, but try to be if it only involves little
effort. Yet I fear bugs in (old) RIPs more, than Level 1-ness.

Regards,
Andras Kadinger
[email-masked]