One of the serious interchange problems with postscript files as an
application type is that the reference given in the MIME document
[POSTSCRIPT] Adobe Systems, Inc., PostScript Language
Reference Manual, Addison-Wesley, 1985.
is not adequate to ensure interoperability of documents from one
systemto another.
Of course it is not enough to insure interoperability. This is NOT a
requirement for a type to be useful.
To take a small example, the above document places
no constraints upon fonts or font names. However, most people
actually desire to transmit documents in the postscript format which
they can actually print and view; if I send you a postscript file that
uses fonts and character sets which you do not have installed on your
printer or in your display-based postscript viewer, you will not be
able to read my document.
Again, this is axiomatic. It also applies to many useful content types besides
PostScript. Practically any format complex enough to be useful is going to have
interoperability problems. This applies to every markup language I've ever
heard of, every revisable document format I know of, and certainly to every
final form lanauge (like PostScript) in existence.
However, this does not mean you cannot engage in useful interchange of
PostScript documents. A vast majority of PostScript applications do work over a
wide variety of environments and situations. This is because they are designed
to work in this way. There are also good and valid uses for PostScript that
does not conform to any widely accepted standards for interchange.
Moreover, PostScript contains facilities for documenting, precisely and
exactly, what facilities and resources a given document uses. This information
can be used to determine whether or not a document has a chance of working in a
given environment. More to the point, it can be used to determine _why_ a
document fails to work. This is something that few, if any, current PostScript
viewer implementations take advantage of. (In my environment at least, most
PostScript I get, and I get a hell of a lot of it, works fine with my viewers,
so I don't have to address this problem very often.)
Frankly, I don't think this working group has the temperment to create
a truly interoperable definition of postscript outside of a particular
implementation.
Well, I guess this is a fair statement. I certainly don't have the temperment
to do it, and I use PostScript all the time.
My personal opinion is that an "interoperable" definition of PostScript is
probably impossible to attain and most likely will be useless once you attain
it. Adobe might be able to do this, but they would be about the only ones
who could. And I don't think they'd be interested...
How are you going to decide on this without treading on one vendor or another's
toes? And once you do achieve it, how are you going to mandate conformance to
it? It is undeniably true that vendors, when forced to with concrete examples
of interoperability failures, will clean up their act. A standard for
PostScript that does not gibe with Adobe's is going to be ignored.
You'd probably at least want to limit the fonts
assumed to exist on the printer, and also require that conformal
message bodies not execute system-dependent operations.
It would be fine to recommend such a thing, but mandating is a just plain
terrible idea, for all the reasons given above.
(The spec
includes as commentary some warning to implementors and some fairly
vague language about 'message senders should avoid the use of
potentially dangerous file operations', but shouldn't the avoidance of
these operators be REQUIRED of senders?)
My implementation of PostScript supports these operators but does them
safely. Why should I have to take them out of my implementation just because
your implementation elected to solve the problem by removing them completely?
Why should I deny users access to these facilities, which they do in fact
use and depend on currently?
Yes, such usage is not interoperable. File references in particular are
a sure source of site dependencies. But sometimes they are useful, even
essential, and I for one don't intend to remove tools that are an essential
part of getting work done.
Given how poorly constrained this is, I'd suggest seriously
considering removing the postscript type also from the base document
and creating another ad-hoc group to work out the interoperability
issues if it is desired.
I disagree in the strongest possible terms. Removal of the PostScript type
solves nothing. People are going to send PostScript whether you like it or
not, and they will do so whether we standardize it or not. Not providing a
label for it will only cause people to invent one of their own, or worse, not
use any label at all.
The removal of PostScript is a show stopper for me. I absolutely reject
any such proposal. I also fail to see any constructive points to your
arguments that would make me want to change any part of the PostScript
description as it presently is formulated.
Ned