I disagree allmost 100% with this. The color thing is not an issue at all.
Device independence is one of the best features (if not the best) of PS.
I have two machines and two displays in my office. One is black and white. The
other is color. The color display is lower resolution than the black and white
display.
I get PostScript that describes black and white documents that is unreadable on
the color display. I don't get nearly as much color PostScript, and what I do
get usually looks fine on the color display and is unintelligible on the black
and white.
For me at least, color usage makes a big difference. Of course, I can select
the proper display manually, and I do. But I usually look at the document
structure before I make a choice. I don't have a document manager for my
displays mostly because I'm lazy and have never set up the document manager I
have to make this sort of choice automatically.
I know of five other offices in the same building I'm in with similar display
setups. I don't think this is at all an uncommon thing to do. Heavy Macintosh
users (I'm not one of them) seem to be particularly into having two displays on
the same machine.
Now, you can argue that most people don't have two displays; they only have one
display and one interpreter for it available. Fine. But then why do we even
bother labelling anything? It will either work or it will not. Labelling is
only useful when a choice has to be made. (The label you propose is not one
that determines whether or not a document is actually interpretable. See
below.)
In my experience the choice is usually more one based on device output ability
than it is on interpreter facilities.
It will take some time before Level 2 interpreters are common. Therefore
any usage of the L2 features is what needs to be clearly flagged in the
Content-Type specifier. The rest will be prosessable by the current
interpreters. If the sender makes use of even one L2 feature the content
should be labelled to require a Level 2 viewer.
I have two PostScript interpreters available to me, not counting interpreters
imbedded in printers. Both interpreters I use support some Level 2 extensions.
Neither supports all Level 2 extensions. They never will support all of Level 2
since that would mean having all the new file operators, which no sane person
would ever run PostScript of unknown origin into because of the security
implications. Thus, labelling a document with Level 2 versus Level 1 is a
perfectly worthless thing to do, since it tells me nothing about whether or not
my viewer will work.
Even the PostScript Language Reference Manual recommends against this type of
labelling, preferring labelling of specific feature sets that comprise Level 2
rather than gross version number labelling. Quoting now from Appendix G.5, page
645:
To enable a document to be output to as many interpreters as possible,
a document composition application should determine the minimum set of
extensions needed for the document to print correctly. It is poor practice
to use the [language level] when the [extensions used] would have been
able to encompass all the operators used in the document.
The Level 2 label is in effect reserved for PostScript that takes advantage of
ALL the feature sets. I've never seen such PostScript, and I would never allow
the viewing of such a document I received through the mail in any case.
I am very reluctant to have the one and only parameter we suport for PostScript
be one that the PostScript Language Reference documents as being "poor
practice". If you want to discuss a parameter that documents extensions as
opposed to just the level I'd be somewhat more willing to consider it, but not
a lot -- we are simply trying to reinvent the wheel here, and I think we should
stay out of this area entirely since someone else, specifically Adobe, is doing
all the work for us.
Let's also consider the difficulty of actually producing this attribute that
describes PostScript level (or any other attribute, for that matter). I have a
number of applications that produce PostScript which I then send via mail. None
of these applications know to produce a Content-Type line for my mailer. I
don't expect them to be able to in the future.
So my mailer is now in the position of determining what to put on the
Content-Type line, based on an examination of the PostScript. (I suppose I
could code an application --> level table into my mailer configuration. I must
then keep this up to date as I add or change applications. This does not sound
like a win to me.) There are two ways to do this. One is to examine the
document structuring conventions. The other is to interpret the PostScript. The
latter is, of course, out of the question.
So now it seems that my mailer has to have a document structuring convention
interpreter in it anyway, in order to be able to generate the proper tag
information. This seems like a waste on the transmit side. Why not put it
on the receive side where it can do the most good, we don't have to play
catch-up with Adobe, and things work as they are already documented?
Ned