dplatt@coherent.com (Dave Platt) (02/20/88)
David Kovar at BBN has reported having difficulties with the
modifications to papif that I posted recently; He's losing the first
11 bytes of each plain-text (non-PostScript) file.
I believe that the problem occurs in the pstext() function. pstext()
reads the first 11 bytes of its standard input, repositions the
standard input via rewind() and lseek() calls, and then checks the data
to see if the file should be filtered through the TranScript filters
"pstext" and/or "psrev".
It appears that some systems may not permit programs to read data
through a pipe and then reposition the pipe with rewind() or lseek()
calls. The net result is that the first 11 bytes of the file are never
fed to the conversion filters (if needed) or written to the printer.
I seem to recall reading reports from some people whose systems were
dropping the first 2 bytes of each text file, under the Columbia
prerelease distribution of papif (without my mods). This is probably
due to the same problem.
I'm working on some modifications to papif that will eliminate the need
to reposition the pipe, on those systems that don't support this
operation. There will be some overhead involved... one additional
process will be needed to buffer the input.
I'll post a complete set of mods once I've checked out the new code.
--
Dave Platt
UUCP: ...!{ames,sun,uunet}!coherent!dplatt Domain: dplatt@coherent.com
Internet: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net