Keith Moore wrote:
Somebody else wrote (Dave Crocker? guess from the original "To:"):
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
As far as I can tell, PostScript (tm) interpreters don't care which newline
convention you use. Both CR and LF (and by extension, CRLF) are treated as
white space characters, except in comments and strings. This is part of
the PostScript language definition.
There is a "small" discrepancy on CR/LF/CRLF processing which
manifests itself on some earlier DVIPS macroes for TeX..
When your printer is NOT an Apple LaserWriter with 68xxx processor
it skips over a bunch of hex data, however it was done carelessly
and CR (or LF) alteration to CRLF will effectively ruin whole
processing. (UNIX lpr -> VMS Multinet -> Digital PrintServer LPS-20)
The latest dvips (well, I have 5.519) seem to have a more sensible
macropacks for "AppleDict" use. (But documents with old macropacks
and systems using old versions are still abundant..)
In my opinnion the PostScript document should ALWAYS be considered
as binary, else all kinds of surprises may appear.
(This should be understood also by our printing facilities, but
it isn't a problem which MIME-transport should worry about...)
...
Keith
/Matti Aarnio <mea(_at_)nic(_dot_)funet(_dot_)fi>