jsim@ur-tut.UUCP (03/12/87)
==============
I'm not sure if comp.sys.ibm.pc is the correct newsgroup for this
posting - but please bear with me, and if it *really* annoys you,
mail flames to me - I'd like to know where to post such an inquiry.
==============
We are using Word Perfect 4.1 as our departmental word processing
software on DEC Rainbows (mostly) and IBM PC/XT/AT and clone
machines. It fulfills our needs, does a good job, and is
relatively easy to use. Unfortunately (sigh....) there is one
not-so-small problem.
We share two DEC LN03 laser printers among many users (both
within the department, and from remote sites - such as homes) by
having the LN03's attached to a Pyramid (90?) running UNIX
4.2bsd. When we need to laser print, we simply use Word
Perfect's print-to-disk facility, formatting for the LN03, and
then send the resulting print file to the UNIX box via kermit,
and then use lpr to spool the file to the correct laser printer.
Not the nicest setup, but it gets the job done, and lets users
laser print from home.
However, the print files created by Word Perfect contain "errors"
- certain lines appear pulled completely to the left edge of the
paper. Examining the print file with SYMDEB (on msdos) or VIS (on
UNIX) shows those lines do not have the leading blank margin, but
do have several (3-4) backspace (^H) characters preceding the
line. The problem shows up in the print file on the
microcomputer - it is not created due to some kermiting
problem. When we attach the laser printer directly to the
printer port (serial) on a Rainbow or PC, the same printer
definition works perfectly, with the same document that is
screwed up in a disk print. The errors are consistent within a
document - if they show up on one printing, they will continue to
show up on subsequent printings. Possibly related to this is
another error - centered lines are sometimes not centered, but
offset to the left - although no ^H's are embedded. Again, this
only happens if we print to disk. I'm at a loss to explain why
these errors occur; perhaps it's got something to do with
flow-control and/or disk drive speed, although the problem occurs
when writing to floppies, hard disks, or ram disks.
I would appreciate any advice; networking the rainbows is out of
the question - and the secretarial staff will not suffer gladly any
more changes in the 'standard' word processing software - so we
have to fix what we have. We can fix the transferred documents
using emacs or vi, but the secretarial staff does not want to
learn vi/emacs - if they did, we would have used vi/emacs and
nroff in the first place. (We have a third LN03 on a VAX 750
running UNIX 4.2bsd, and used via vi/nroff.)
Word Perfect has been (rather tried) to be helpful, but we've
gotten nowhere so far - all fixes have resulted in massively
bizarre output, and now Word Perfect's fix is for us to buy
different laser printers. They do say they offer only limited
support for the LN03. They also said that DEC uses xon/xoff to
write to disk, while IBM uses flow-control to write to disk....
Please e-mail responses rather than posting to the net. I'm at:
UUCP: !rochester!ur-tut!jsim
UUCP: !rochester!ur-cvsvax!gort
BITNET: JSIM@UORVM or JSIM@UORDBV
U.S. MAIL (no, I won't insult the Postal Service...)
John Simonson
Department of Psychology
Meliora Hall
University of Rochester
Rochester, NY 14627
< I claim nothing; therefore, I disclaim everything?>