mike2@lcuxa.UUCP (06/18/87)
Several weeks ago, I posted a request for help on a weird problem
I was having with WordPerfect 4.2. Specifically, when sending
LaserJet-formatted printer output to files, and later spooling
them to one of the common printers on the UNIX system, some lines
would start at the wrong place in the printed document. This was
sporadic, and occurred on lines that were tabbed at the
beginning, centered, or indented. The problem had not arisen in
WP 4.1.
Thanks to WordPerfect Corporation, I now have the answer and
thought I would share it with the net(s). It is UNIX-related,
and WordPerfect's folks apparently were not UNIX-wise, which
explains why it took them a while to figure this crazy out.
The problem
WP 4.2 is "smarter" than (at least early versions of) WP 4.1.
When a previous line ends at a column position lower than the
next line is to begin, under the defaults of the normal WP
printer interface files the program sends an ASCII LF (10) to
move down to the next line, and HMI codes to move across from
there to where the next line is to begin. In the previous
version, it sent a CR/LF and used the HMI to move across from the
margin (set to 0 by the driver).
But, UNIX systems (uniquely?) use the LF as a combined CR/LF
character. For compatibility, the printer spoolers normally set
attached printers to treat the LF as the combined CR/LF
character.
Therefore, we had a mismatch. WP 4.2 thought the next line was
starting at the same position where the previous line ended, but
the printer thought it was starting from column zero.
The fixes
There are three possible fixes. I've used #1 below; other folks
may want to use one of the others.
1. Change the way WP generates the file:
Change the WP printer driver to treat the LF as a combined
CR/LF character. Then, the program will not use the new
"smart" positioning mode. To do so, use WP's "printer.exe"
program to edit the driver, go into screen #2 and answer yes
to the "automatic CR with LF" question; then go into screen
#3, and fill in the "perform line feed" line with <13><10>
(gotten by holding down the ALT key and typing 013 and 010
on the numeric pad on an IBM machine).
2. Change the way the LaserJet interprets the file:
Change the WP printer driver to send an initialization
sequence to the printer that includes ESC&k0G. This will
override the UNIX spooler's printer initialization, and
restore the printer to treating LF as LF and CR as CR, since
it will be received by the printer subsequent to the UNIX-
generated initialization. PROBLEM: my WP LaserJet-B
printer driver file was too full and didn't have enough room
to accept this change. That is why I used #1 (which it did
accept).
3. Change the way the UNIX spooler initializes the printer.
Our SYS V 'lp' uses an interface module which is accessed by
all users. Our system folks might have objected to
modifying the general-use one, and I didn't want to waste
the time to determine whether a private interface (in my own
directory) could be substituted for my invocations of 'lp.'
The reason WordPerfect could not replicate the problem when they
tried for several weeks is that they apparently had never before
seen a printer initialized to treat the LF as a combined CR/LF,
and were not aware that in the UNIX world there is a reason to do
so. They are now!
In sum, WordPerfect was very helpful and cooperative once I was
able to get past the folks who answer the "which button do I push
to turn on the computer" questions. They quite naturally try to
protect their hackers from being bothered by routine user
questions, and it took a while to get to someone who understood
the problem and was willing to try to think it through. To their
credit, once the problem was placed in the hands of the
appropriate organization, it was solved within days.
Now that it works, WP 4.2 is a real honey!!!
Mike Slomin
bellcore!lcuxa!mike2