[405] in Public-Access_Computer_Systems_Forum
Postscript Files
daemon@ATHENA.MIT.EDU (Public-Access Computer Systems For)
Tue Jun 2 12:23:03 1992
Date: Tue, 2 Jun 1992 10:52:55 CDT
Reply-To: Public-Access Computer Systems Forum <PACS-L%UHUPVM1.BITNET@RICEVM1.RICE.EDU>
From: Public-Access Computer Systems Forum <LIBPACS%UHUPVM1.BITNET@RICEVM1.RICE.EDU>
To: Multiple recipients of list PACS-L <PACS-L%UHUPVM1.BITNET@RICEVM1.RICE.EDU>
3 Messages, 156 Lines
*-----
From: "Peter Graham, Rutgers U., (908) 932-2741" <GRAHAM@ZODIAC.BITNET>
Subject: Re: Postscript Files Again!
I can't answer all Iain Noble's questions and would welcome a brief and
thorough discussion. However I can speak for printing from a Macintosh
once you have the file:
1) System 6 and previous: use the program SendPS to print a postscript file;
it has a menu option to send a postscript file to the printer (you need to
determine if your printer is postscript-capable; it varies with model and
feature).
2) System 7: use the Apple-supplied LaserWriter Utility (on the Tidbits
[sic] disk supplied with the system) which functionally does the same as
the above. SendPS does not work with System 7.
Ask your local gurus how to get SendPS; that's what I did.
--Peter Graham, Rutgers University.
*-----
From: William Jordan <bjordan@u.washington.edu>
Subject: Re: Postscript Files Again!
On Mon, 1 Jun 1992, LBA002@PRIME-A.TEES-POLY.AC.UK wrote:
> Do you have to ftp the files as BINARY files?
No. Postscript files are ASCII files.
> Which printers will function as postscript printers? Apple
> LaserWriter, HP LaserJets?
Many laser printers permit Postscript emulation with the appropriate font
cartridge and enough memory. I use a LaserJet IIP with the Pacific Page
cartridge. I can't speak to the requirements for the Apple LaserWriter -- we
are IBM all the way here.
> How do you get the printer to process a postscript file? Just
> type COPY <filename> LPT1 for IBM PC's? Or is there more
> software involved?
Once you have a Postscript file on disk, no additional software is
required for DOS machines. If your Postscript printer is on LPT1, just
enter:
copy FILENAME.EXT lpt1
or
type FILENAME.EXT>prn
(the ">" character redirects output from stdout, the screen, to the named
device).
--Bill Jordan (bjordan@u.washington.edu)
--Reference and Research Services Division
--Suzzallo Library
--University of Washington
*-----
From: cjg@stubbs.ucop.edu (Czeslaw Jan Grycz, UC Office of the President)
Subject: RE: ascii as a means of exchange
Stephen Pednergast brings up a question which is crucial with respect to
electronic information dissemination when he asks about the appropriateness
of ASCII vs. PostScript as a standard for document interchange. The two
approaches are - at present - mutually exclusive solutions, each of which
provides considerably different advantages and limitations.
SGML
Standard Generic Markup Language is a means of tagging document elements.
(People can quibble about the appropriate noun to use in describing what
SGML _is_, but it is irrelevant to this discussion.) Standardized tagging
conventions permit logical retrieval and representation of text.
Furthermore, SGML permits the integration of non-text objects into a
document, paving the way for compound documents. Tags merely defines the
existence of various structural elements, not the formatting instructions.
Format information is contained in description files. Users are free,
however, to redefine the format definitions of tags. Text is encoded in
ASCII, the least common denominator of textual representation.
Advocates of SGML point to these advantages:
Platform Independence
Durability (software may change, but if tags are truly standardized,
ASCII text will be readable by any future software display or retrieval
capability)
Government Support (through its CALS initiative and MILSPEC standards,
both applications of SGML)
Efficiency (very low overhead is associated with normal SGML files,
though, of course the more complex a document is, the more complex will be
the descriptive tags.)
Broadbased support by database and CD-ROM publishers.
Its detractors complain about:
Complexity (many "normal" non-specialists don't understand document
structural organization.)
Lack of intuitive interfaces (SoftQuad's "Author-Editor", and Exoterica
are still, I believe, the only available SGML authoring tools for the
average user.)
Additional labor to tag word-processed files.
PostScript
On the other hand, many authors feel they have been "empowered" by access
to the means of distribution. (This is what is at the bottom of the
enthusiasm for networks among scholars, and the resulting tensions with
traditional publishers.) Some individuals further believe that the
representation of text on a page is a crucial communications tool: on a
second level, to be sure, to the logic of argument and evidence, but a
right many authors wish to preserve. PostScript preserves both content and
format, and has become a de facto standard in its own right. As a
standard, PostScript is increasingly supported by various platforms and
software display and print solutions. But it is, withal, a proprietary
solution, and one which has powerful detractors and competitors.
The advantages of Postscript:
Device Independence
Formats preserved and difficult to tamper with
High quality output on certain devices; acceptable lower quality on less
expensive devices
Several important technical solutions dealing with "on demand" document
delivery
Many PostScript intelligent software applications
Complexity of program hidden to the average user
Permits integration of other than text materials
The disadvantages:
Not yet a recognized international standard
High overhead of coding instructions
Versions incompatible with one another in upward migration
Page orientation (a throwback to the print technology and the first
purpose of Interpress)
No searchability for tags, elements, or structures
I am personally persuaded that PostScript is the most socially acceptable,
and the most technically malleable of these two extremes. I am bothered by
the apparent mutual exclusivity of these standards. What is needed is an
easier-to-use SGML, or a PostScript SGML interpreter/parser. Neither of
these is apparently close to the horizon. Both are apt to co-exist, and
may find separate niches.
For librarians, however, it seems to me an uncomfortable dichotomy. Choose
one, and you may have an archival quality file that can be read years from
now. Choose the other, and you may have a much more acceptable form of
presentation which can be delivered in a vareity of ways, but which may
impose limits on full-text searching, and may be supplanted by competing
PostScript variants.
Chet Grycz
University of California
