Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!ihnp4.ucsd.edu!library.ucla.edu!psgrain!news.tek.com!news!phils From: phils@satori.tv.tek.com (Phil Staub) Newsgroups: comp.os.386bsd.questions Subject: Re: printcap filters Date: 06 Dec 1994 18:14:50 GMT Organization: Tektronix TV Products Lines: 95 Message-ID: <PHILS.94Dec6101450@satori.tv.tek.com> References: <RICK.94Nov24045024@vox.trystero.com> <D0DG9L.F35@latcs1.lat.oz.au> NNTP-Posting-Host: satori.tv.tek.com In-reply-to: wongm@latcs1.lat.oz.au's message of Tue, 6 Dec 1994 04:24:56 GMT In article <D0DG9L.F35@latcs1.lat.oz.au> wongm@latcs1.lat.oz.au (M.C. Wong) writes: > In article <RICK.94Nov24045024@vox.trystero.com> rick@vox.trystero.com (Richard E. Nickle) writes: > > > >Hi, > > > >Well, this might be an FAQ, or at least a previously asked > >question. > > > >I tried to install a fake printer that filters postscript > >through the ghostscript program before putting it out to > >the device (in this case, a remote printer running on a > >non-Unix system). This sounds a lot like apsfilter. > > > >What I tried is various iterations of setting the 'if' > >(and later 'of') variable in /etc/printcap. > > > >When the printjob is spooled, however, it is never passed > >to the filter program. I even went so far as to have the This is my experience as well, at least as far as I have been able to detect. I think the filter program (apsfilter) is actually getting the file, but it never makes it through the filter. My estimate of the problem follows. > >filter program emit some text to a seperate logfile to at > >least verify if it was ever called. [...] > >Richard Nickle http://www.trystero.com/rick.html > > While I haven't got the soluation s to your problem, I did have the similar > unsuccessful experience of using filter for printing non-ASCII file. BTW, > I am using apsfilter-1.11 as the input filter. Hen I said : FYI, apsfilter version 4.81 is much more current. > > lpr -v file.ps I haven't tried this, but I HAVE done many other things. > > the spawned lpd coredumped, and lpq will say no daemon present! lpd.core can be > found in the spool directory for the printer used (default lp). However, I guess [...] > > I guess, I can do : > > lpr file.ps This I have tried, and it doesn't work. > > and let apsfilter figures out it is a PS or DVI or etc file, as apsfilter does > detect file type. I haven't got the chance to test it yet, but I will test > it today, and if that works, I am diving into lpd codes. > > -- > - wongm@latcs1.lat.oz.au (M.C Wong) [...] After much time (and head scratching) I think I've narrowed down the problem to the 'rewindstdin' program. apsfilter seems to need to rewind the input stream a couple of times in the process of figuring out what to do. Upon looking at the log file, I see several occurrences of 'file -'. This is followed by 'set -- standard input: ascii text' the first time, then 'set -- standard input: empty' after that. These sequences are interspersed with 'rewindstdin'. Upon further investigation, I find that rewindstdin is a simple program which does an lseek(0,0L,0) to back up the input stream. This apparently doesn't work on 2.0. Sorry if you've been reading this expecting a solution: I haven't got one yet. I just sent e-mail to the bug reporting address specified in the apsfilter docs. If Andreas is reading this thread, perhaps he can jump in with the solution, but for now I'm planning to delve into lpr and friends to see if I can determine where apsfilter gets its standard input from, and why it can't be rewound. My guess is that it ultimately boils down to a pipe (thus a socket), and that you can't rewind a socket. I haven't done enough programming with either the lpr daemon or sockets to know either of these things as fact, but the lseek(2) man page specifically warns about some types of file which cannot be rewound. If these assertions are true, we could be looking for another way to rewind the input stream. -- ------------------------------------------------------------------------------ Phil Staub, phils@tv.tv.tek.com Tektronix Television Division (503) 627-6910 -- ------------------------------------------------------------------------------ Phil Staub, phils@tv.tv.tek.com Tektronix Television Division (503) 627-6910