Subject: Re: [netatalk-admins] Netatalk and OPI
From: Hans-Guenter Weigand (hgweigand@wiesbaden.netsurf.de)
Date: Tue Jan 19 1999 - 17:44:23 EST
Rodger.Donaldson@wnl.co.nz wrote:
> On Wed, Jan 13, 1999 at 07:36:45PM -0500, Lee Blevins wrote:
>
> > 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.
> > 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
Do you refer to an OPI specification 2.0 or the Helios OPI 2.0 product?
> 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
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.
> 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
[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
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:12 EST