Path: utzoo!attcan!uunet!jarthur!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!haven!umd5!zben
From: zben@umd5.umd.edu (Ben Cranston)
Newsgroups: comp.lang.postscript
Subject: Re: postscript from PS/2 to unix
Summary: All newlines are not the same
Message-ID: <6260@umd5.umd.edu>
Date: 15 Mar 90 18:13:52 GMT
References: <7986@sdcsvax.UCSD.Edu> <1990Mar14.230311.26881@me.toronto.edu>
Reply-To: zben@umd5.umd.edu (Ben Cranston)
Distribution: na
Organization: University of Maryland, College Park
Lines: 64
Expires:
Sender:
Followup-To:
Keywords:

In article <7986@sdcsvax.UCSD.Edu> mikulska@odin.ucsd.edu
(Margaret Mikulska) writes:

> ... using word processor "Nota Bene" from Dragonfly on PS/2 under MS-DOS.
> word processor creates PostScript file which can be saved with the
> "print-to-disk" command. [user] transfers file to a BSD-ish UNIX system
> to print it out on an Apple LaserWriter.
> file ... in some format that no printer (attached to a unix system) would
> print as is. ...didn't start with "%!"; the whole file 30,000 characters,
> was one single line (actually, 'wc' reported 0 lines)...

In article <1990Mar14.230311.26881@me.toronto.edu> sun@me.utoronto.ca
(Andy Sun Anu-guest) writes:

> ... symptoms that you mentioned (0 line) rings a bell. I had trouble
> printing a MacDraft PostScript output file to a laser printer hooked
> up to Unix before. I got the same 0 line business. It turned out that
> the software didn't generate a new line character at the end of a line.
> So when sent to Unix, no ^M at the end to wrap to a new line. Because of
> this, you end up having an ultra-long line (imagine ONE line with 30,000
> characters in it that even vi or wc fail to recognise it properly.

Newline on the Macintosh is ^M (CR) while newline on Unix is ^J (LF).
File transfer programs like Kermit or FTP change one to the other in order
to preserve the user-visible characteristics of the text.  If, however,
the file gets transfered in BINARY (IMAGE) mode this mapping does not get
done, and you see your data as one very long line.  The definition for a
"text file" on Berzerkeley is "LF delimited lines".  The vi and wc man pages
specifically say they work on "text files".  Your file, without any LFs
in it, is not a "text file", so action of vi/wc is undefined.

> What I did to overcome the problem was to write a tiny filter in C that
> adds a "\n" whenever it sees a "\0". This should bring the file back
> to normal. Last but not least, the word processor itself probably got
> it's own laser printer initialization code separately stored on a file
> (like PC MS Word that has a file called LASER.INIT that contains all
> the PostScript definitions in it). Look and see if you can find such a
> file in that Nota Bene thing. If yes, upload it and prepend it to your
> PostScript code and shoot it to the laser printer. Otherwise, simply try
> adding %!PS to the beginning of your existing PostScript file and see
> if anything comes out at all.

Postscript printers themselves do not need the %!, but some spooling systems
use this as a flag to distinguish postscript from running ASCII text.  This
makes it singularly difficult to get a listing of your Postscript program.
If you get a huge text listing full of things like

12 4.5 freeble
(Something you recognize) show
showpage

this is your problem, put the %! in.  Lack of the LASER.INIT-type prolog
file usually shows up as an undefined command, like this:

%%[ Error: undefined; OffendingCommand: foo ]%%
%%[ Flushing: rest of job (to end-of-file) will be ignored ]%%

I just sent a file containing only the word "foo" to a Laserwriter...

-- 

"It's all about Power, it's all about Control
 All the rest is lies for the credulous"
-- Man-in-the-street interview in Romania one week after Ceaucescu execution.