ho@sask.UUCP (Wing Ho) (05/02/88)
Does postscript have the ability to read input from files? I am trying to write a program so that it could plot some nice graphs. Or is there such a program around already? Thanks in advance. Wing Ho uucp: ihnp4!sask!ho
edwards@bgsuvax.UUCP (Bruce Edwards) (05/04/88)
In article <1089@sask.UUCP>, ho@sask.UUCP (Wing Ho) writes: > > > Does postscript have the ability to read input from files? > I am trying to write a program so that it could plot > some nice graphs. > > Or is there such a program around already? > > Thanks in advance. > > Wing Ho > > uucp: ihnp4!sask!ho Yes, PostScript does have the ability to input from files. It is a fully functional language. Should you use the PS functions to get your data? In my opinion no. You could attach your data to the end of a PS file and have the script read from the end of itself (if that makes sense ;-) but even that is going to greatly reduce the speed at which your final product is generated. The best way to go about it, I think, is the 'brute force' approach. Shove your data directly into the PS file as the arguments to specific operators. This has the effect of producing 'ugly' redundant code but only your output device (like Clarol's hairdresser) will know. The advantage is that the output device will eat your PS lickity split and give you your graphs. I presume its graphic output and not elegantly refined code you're after. ;-) Disclaimer: I am participating as a guest of Bruce Edwards. My name is Ken Jenkins. Bruce is generally amused with my ramblings but does not necessarily agree with them. 'These are only the shadowlands.' C.S. Lewis ----------------------------------------------------------------- Ken Jenkins as guest of edwards@bgsu CSNET: edwards@bgsu ARPANET: edwards%bgsu@csnet-relay UUCP: cbosgd!osu-cis!bgsuvax!edwards or U.S. Snail: Ken Jenkins c/o Century Marketing Corp. 12836 S. Dixie Hwy. Bowling Green, OH 43402 -----------------------------------------------------------------
ken@cs.rochester.edu (Ken Yap) (05/04/88)
|Yes, PostScript does have the ability to input from files. It is a |fully functional language. Should you use the PS functions to get |your data? In my opinion no. You could attach your data to the |end of a PS file and have the script read from the end of itself |(if that makes sense ;-) but even that is going to greatly reduce |the speed at which your final product is generated. The best way |to go about it, I think, is the 'brute force' approach. Shove your |data directly into the PS file as the arguments to specific operators. I disagree. Do you propose I shove this bitmap screen dump of mine into the code instead of using readhexstring? Have a look at any recent raster to PS converter. It would probably slow the thing down by tripling the code size. There are reasons why bitmap dumps are slow but inlining the data doesn't help. And yes, it makes sense for the data to go at the end of a PS file. Bit reminiscent of card jobs, no? :-) Ken
greid@ondine.COM (Glenn Reid) (05/05/88)
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 Systemsmark@hpcvlx.HP.COM (Mark Rowe) (05/05/88)
Responses to PostScript's ability to read input files has been yes it can, but do it this way instead. I am more interested in the answer to the original question. Can PostScript read input files. True, PostScript is a fully functional language with operators "file", "closefile", "read", "write", "flush" and so on to work on general files; however, it appears to me that all implementations of the PostScript language are severely limited in their ability to use these capabilities which seem to restricted to applying these operations to a single input stream and a single output stream. Admittingly, my experience is limited to desktop 300 dpi laser printers. There may be some high-end printers with built-in mass storage that allow some useful application of these operators. I would like to know if there is any way to use them on a standard (low-end) serial desktop PostScript printer (i.e. LaserWriter) Mark Rowe mark@hp-pcd
edwards@bgsuvax.UUCP (Bruce Edwards) (05/10/88)
In article <9340@sol.ARPA>, ken@cs.rochester.edu (Ken Yap) writes: [Ken Jenkins] [ on shoving data into the code as arguments for operators I write ,"yeah let's do it!" ] [Ken Yap] > > I disagree. Do you propose I shove this bitmap screen dump of mine > into the code instead of using readhexstring? Have a look at any recent > raster to PS converter. It would probably slow the thing down by > tripling the code size. There are reasons why bitmap dumps are slow but > inlining the data doesn't help. I quite agree on your bitmap data. But I believe the original poster was talking about data points to be used in the building of a graph of some sort. For data of this type I still maintain embedding it as arguments to operators is the quickest way to go. > And yes, it makes sense for the data to go at the end of a PS file. > Bit reminiscent of card jobs, no? :-) Ah yes, the good ol' days. > Ken Disclaimer: I am participating as a guest of Bruce Edwards. My name is Ken Jenkins. Bruce is generally amused with my ramblings but does not necessarily agree with them. 'These are only the shadowlands.' C.S. Lewis ----------------------------------------------------------------- Ken Jenkins as guest of edwards@bgsu CSNET: edwards@bgsu ARPANET: edwards%bgsu@csnet-relay UUCP: cbosgd!osu-cis!bgsuvax!edwards -----------------------------------------------------------------