Newsgroups: comp.lang.postscript
Path: utzoo!utgpu!cunews!micor!latour!ecicrl!clewis
From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Subject: Re: How can I tell if a file is "postscript"
Message-ID: <1991Mar19.052103.9026@ferret.ocunix.on.ca>
Date: Tue, 19 Mar 91 05:21:03 GMT
References: <Qbr2bdK00VQs40k49S@andrew.cmu.edu> <1991Mar13.160331.25024@maths.nott.ac.uk> <13109@wraxall.inmos.co.uk>
Organization: Elegant Communications Inc

In article <13109@wraxall.inmos.co.uk> des@frogland.inmos.co.uk (David Shepherd) writes:
>In article <1991Mar13.160331.25024@maths.nott.ac.uk>, anw@maths.nott.ac.uk (Dr A. N. Walker) writes:
>> 	Just so.  Now think how many things break if "lpr B" lists B
>> if the printer is a simple lineprinter but produces a fancy graphic
>> if we upgrade it to a LaserWriter.

On the contrary, I'd suggest that it was no longer broken.

>> 	What's more, there is a similar potential problem with every
>> different printer language.  We could find ourselves with 10 different
>> printers on our network, each with a different [or, worse, the same]
>> magic marker, so that all sorts of files must be "enscripted" by one
>> of 10 different programs to print on some printers, and must not be
>> to print on all the others.

A truly smart spooler would figure out what printers are appropriate
for a given magic cookie, and route the results there.  Otherwise,
you're expecting everybody to remember which printers can handle a given
format and/or remember lots of obscure options to tell the printer to
go into the correct mode.

Users want to print in the inherent format of the print file.  They
don't want to have to remember what format the file is, or what magic
contortions they have to go to get it printed properly.  Postscript
is a special case, in that you *can* list the postscript on a plain
ascii printer.  But I would contend that someone generating postscript
usually doesn't want to see the postscript listing, they want to see
the "graphic" that the postscript listing represents.  In those rare
occasions where the user wants to see the internal language, it makes
more sense to expect the user to know how to "convert" it to a another
format suitable for viewing.  In the case of postscript, it's easy.
Run the bare postscript thru "pr" - not only do you get the output
nicely paginated with page numbers, the "%!" doesn't even get recognized
because it's no longer first in the file.

In the more general case, it's even more obvious that this is the
correct approach.  For example, "DVI" (TeX),  C/A/T phototypesetter,
ditroff output, GIF's, TIF's, HPPCL etc.  These formats are binary.  And
will blow the brains out of a printer in the "wrong mode".  Rather
than expecting the user to know *which* printer is the C/A/T, or
what magic "lpr" incantations are needed to invoke dvips, it makes
a LOT of sense to have the spooler recognize the magic cookies (all
of these formats can be easily disambiguated) and "do the right thing".
Which might be rejecting them.  Or, rerouting to something capable of
handling it.  Or, knowing what filters to invoke.  If the user *really*
wants to see these formats themselves, they have to run them through
conversion programs of one variety or another (perhaps just "od -c")
no matter what format they want out.

Fortunately, most of the binary formats will be easily detectable
as being non-ascii.

ASCII is a special case in that it's one of the few formats without
an easily detectable magic cookie, and that occasionally, someone
might accidentally trip over some other format's magic cookie.
But I suggest that this problem is far less than having to remember
all of the options neccessary to print the other multitude of formats
a given machine may be able to generate.

And finally, any format that has the same magic cookie as another
is broken.  Period.

The "file" program can usually be parameterized to detect what
format is being used.  (In fact, with later versions of file,
you could modify its database to contain the actual command lines
neccessary, such as being able to say:

	eval "`file $printfile` $printfile"

>If you object to files starting with %! being treated different from
>others that don't, what is your view on executable files that start
>with #! /bin/sh ?????

More to the point, what about when "file" says:

    executable (RISC System/6000 V3.1) or object module not stripped

Blindly routing it to a printer is stupid.
-- 
Chris Lewis,
clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis
Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada)
(If this message has a ".bitnet" return address, please send me a copy!)
