Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!decwrl!adobe!ondine!greid
From: greid@ondine.COM (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: input from files, PostScript
Message-ID: <3908@adobe.COM>
Date: 5 May 88 15:17:12 GMT
References: <1089@sask.UUCP> <2042@bgsuvax.UUCP> <9340@sol.ARPA>
Sender: news@adobe.COM
Reply-To: greid@adobe.UUCP (Glenn Reid)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 76
Keywords: input, PostScript

Reading data from the current file is fine, although it generally
should be done only when the amount of data is known ahead of time.
For example, here is a familiar call to the "image" operator
(with some <metasyntax> for arguments):

	<width> <height> <bits/pixel>
	{ currentfile picstr readhexstring pop }
	image
	69a872f34...<data>
	...
	showpage

The "image" operator requires exactly width*height*bits/pixel bits of
data, and will call the procedure as many times as necessary to get the
right number of bytes (notice that the calculation yields numbers of
bits, which need to be supplied as bytes in a string).  At the point
where "image" is satisfied that it has enough data, it quits calling
the data acquisition procedure, and control returns to the interpreter,
which will then continue to parse the input file.  As long as the data
supplied matches the needs of the "image" operator, all is well, and
the final "showpage" is interpreted normally.

In a case where an unspecified amount of data is to follow (for example,
reading strings of text from the input file and printing them like a
line printer), it is better to preprocess them and put them into string
bodies and make procedure calls, rather than to use "readstring" or one
of its kin:

    (line printer\), it is better to preprocess them ) 72 650 SH

Part of the reason for this is that if a program reads data directly
from the input file, it typically does not terminate until the end of
file is reached.  This prevents its ever being nested within another
program.

In any case, here are the operators in the PostScript language that may
be of use in file operations, although if the current input file is
used (the printer has no local file system), one should never open or
close files explicitly.  I have put a "*" next to operators that are of
general interest when reading from the standard input file:

	file				% open for read/write, return "fd"
	closefile
*	currentfile			% returns "fd" for current file
*	read				% all of these require "fd"
	write
*	readline			% read newline-terminated string
*	readstring			% read to fill buffer
	writestring
*	readhexstring			% read hex to fill buffer
	writehexstring
*	print				% print string to current output file
*	==
*	token				% parse for valid PS token
	bytesavailable			% remaining bytes (if known)
	resetfile
	status				% used only with file systems
	run				% execute filename directly
*	flush				% flush current output buffer
	flushfile

There are a few additional operators available in interpreters which
have access to a real local file system (printers with disks, for
example).  The existence of these should be checked with "known" or
"where" before you attempt to call them.  Except for "filenameforall",
only utility programs should need these:

	filenameforall
	renamefile
	deletefile
	diskstatus


I hope this helps.
       Glenn Reid
    Adobe Systems