Subject: Re: [netatalk-admins] Netatalk and OPI
From: rodgerd@wnl.co.nz
Date: Tue Jan 19 1999 - 05:35:09 EST
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 rodger.donaldson@wnl.co.nz 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.
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:12 EST