From: cctr132@csc.canterbury.ac.nz (Nick FitzGerald, CSC, Uni. of Canterbury, NZ)
Newsgroups: bit.listserv.wpcorp-l
Subject: Re: VAX WordPerfect and HP LaserJet PostScript (longish)
Date: 8 Apr 92 09:48:40 +1200
Organization: University of Canterbury, Christchurch, New Zealand

Sorry, the original attributions here are getting cloudy, so I've
dropped all mention of who said what.  I also missed the beginning of
this thread, so please excuse if this completely misses the boat!

>>> I suspect this is related to a problem discused a few weeks back about
>>> uploading postscript files to print.  I solved this problem by setting
>>> both the local kermit and the server to transfer BINARY files.  It had
>>> to do with how carriage retruns were processed.
>>Thanx.  But I think we're doing two different things here.  You 
>>are using both MSKERMIT and VMS KERMIT to *transfer* a PostScript file before 
>>printing it.  I never actually create the PostScript file (or at least, not 
>>permanently) in the 1st place.  The VAX WordPerfect PRINT command is all I am
>>using.  It immediately sends a stream of PostScript to the printer via the 
>>screen.  I never go through a server-type transfer.  I know that some of the
>>information coming to the terminal is binary, for example the Control-D (ASCII
>>decimal 4) shows up at the end of most PostScript files.  I was assuming
>>that playing around with SET TERM/PASTHRU or the DECserver SET SESSION PASSALL
>>would solve the problem, but so far, I've had no luck with either of those. 
> 
> We are clearly talking about two different things on a program level, yet
> the essence in both cases is that somehow postscript commands are being
> transmitted to a remote printer.  And the SYMPTOMS are identical.  I don't
> know enough about your setup to know for sure, but it sure sounds similar.

This sounds like what I thought was a reasonably well known problem with
PS printing on VAX PS printers with print files created on the PC
(particularly, print files created with "early" versions of the WP PS
printer drivers).

VAX/VMS has a complex file system.  Unlike DOS (and I think, Unix) where
a file (-any- file) is essentially just a stream of characters, VMS does
"clever" things with files, depending upon what type of file structure
they have.  Uploading a file to a VAX to print on its PS printer is a
good case of where VMS's "cleverness" can be a bloody nuisance.

If you do the upload in ASCII mode (Kermit and ftp default to ASCII),
the VAX end will create a particular type of file (boring details
omitted).  VMS expects files of this type to have a "line terminator"
(CR for VMS) at least once every X characters (I think X=32K, but the
details are irrelevant).  If it doesn't see one, it effectively corrupts
the file (again, I'm not sure precisely what it does, but you won't be
able to successfully print the file).  You won't get an error message or
warning or anything, and the resulting file size will be plausible. 

With PS files this can be a major problem becuase there is no official
concept of maximum line length for a PS file.  Indeed, the CR char is
simply a valid separator in PS - in theory, you could replace every
space char in a PS file with a CR and it should print the same.  WP's
early PS drivers were very good at producing PS output with
exceptionally long "lines", thus when uploaded to a VAX in ASCII mode
they often caused problems.

If you upload the file to the VAX in binary mode, it will use a file
structure which doesn't care about CR's at all, and all should be well. 
(In some cases you may have to use the "/passall" qualifier to get a
file to print properly - I always use it, just to save possible
hassles.)  The mention of Ctrl-D (PS end-of-job) above, as requiring
binary mode is misleading.  Ctrl-D is ASCII 04 - clearly a seven-bit
character, and hence not requiring binary (a.k.a. 8-bit) upload modes.

Thus far, it should be clear why the first person, quoted above solved
her/his problem by changing to binary upload mode.

I'm not quite sure that we have the answer to the original (?) query
though.  The poster with problems with WP for VMS says:

>>...The VAX WordPerfect PRINT command is all I am
>>using.  It immediately sends a stream of PostScript to the printer via the 
>>screen. 

My hunch is that -if- WP for VMS spools the output to a file before
sending to the printer, it would cause the same problem as the ASCII
upload -if the file structure chosen by the WP programmers is one of
those sensitive the palcement to CR chars-.  Why would WP do that?  Well
on PC's WP spools print jobs so it can do "pseudo background" printing.
If this is the case for the VMS version then the only solution
(probably) lies within WP Corp - they have to recode that bit of the app
and recompile or ensure their PS printer drivers and/or printing
routines -NEVER- produce overly long "lines" (the problem may be caused
by VMS printer queue spooling as well - if so WP Corp have to follow the
latter path).

Maybe this helps (?),

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z. 
 Internet: n.fitzgerald@csc.canterbury.ac.nz        Phone: (64)(3) 642-337