Application/postscript is, by definition, not text. On the other hand, it
clearly IS pretty much text encoded on most systems. This lead to a minor
question about newlines. Different platforms use different conventions for
newline, so how is the lowly app/post-generating UA to know what to do?
Must they be a full-fledged ps parser? Do we require conversion to a
canonical newline?
I believe this directly affects interoperability of app/ps
Since the same holds true for application/rtf, it prompts me to bring back
the issue about its registration. (Sorry.)
Since Microsoft RTF basically is a "decorated text" format just like
text/enriched, wouldn't it make more sense to have it (re)registered as
text/rtf -- just like it originally was intended?
That would certainly solve its newline problem.
As for the format being intrinsically unreadable without special tools, I
tend to disagree. Here's an actual sample generated by our standard editor:
{\rtf0\ansi{\fonttbl\f0\fswiss Helvetica;}
\paperw10080\paperh11200\margl120\margr120
\pard\tx520\tx1060\tx1600\tx2120\tx2660\tx3200\tx3720\tx4260\tx4800\tx5320
\f0\b0\i0\ulnone\fs24\fc0\cf0
Since the same holds true for \b application/rtf\b0 , it prompts me to bring
back the issue about its registration. (Sorry.)\
\
Since Microsoft RTF basically is a \i decorated text\i0 format just like
\b text/enriched\b0 , wouldn't it make more sense to have it (re)registered
as \b text/rtf\b0 - just like it originally was intended?\
}
Your mileage may vary with the tools that you're using, but I'd say that this
is just about as readable as your average enriched text. In fact, it seems
to me that readability will be directly dependent on the editor you're using
independently of it using rtf or enriched text. For example, it's easy to
make this sample more compact by eliminating the paper size hints and the tab
stops settings.
This leads to the larger issue of what formats are reasonable to use for the
"main body" of the message. Currently, we have text/plain and text/enriched.
The latter basically gives support for some font attributes and paragraph
justification, but is too limited for those used to today's standard of word
processing. Since RTF already is widely used and quite capable of
encapsulating most any modern word processing feature, it's tempting to use
that instead -- just like we currently do with NeXTmail. Still, it leaves me
concerned with the issue of interoperability since it makes little sense to
produce these "extra rich" body parts if noone else will be able to display
them. Yet, it makes me sad -- and our customers quite likely annoyed -- when
adopting to a standard means lowering the quality of the output.
Just a voice from the trenches.
Lennart Lovstrand
NeXT Software Engineering