Xref: utzoo unix-pc.general:2483 comp.sys.att:5869
Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!decwrl!decvax!ima!spdcc!gnosys!gst
From: gst@gnosys.UUCP (Gary S. Trujillo)
Newsgroups: unix-pc.general,comp.sys.att
Subject: UNIXpc nroff driver tables [REPOST]
Message-ID: <130@gnosys.UUCP>
Date: 18 Mar 89 18:11:12 GMT
Organization: gst's 3B1 - Somerville, Massachusetts
Lines: 67

(This article is a replacement for one mistakenly posted earlier to
unix-pc.sources.  It contains a couple of paragraphs not found in the
previous article, which has been cancelled.)

While I discovered the following problem on my own peculiar printer,
I think the problem to be of general concern, as it would seem to be
a common situation for a printer to need to be sent characters outside
the 7-bit ASCII range which represent the ordinary printable characters.

I have been trying to follow the instructions in NTERM(5) of the 3.51
Users' Manual (Volume 1) to construct a driver table to let me get at
special characters on my NEC P2200 printer.  The problem is that these
characters commonly require output of a character whose magnitude is
greater than those defined in the standard ASCII character set.  In
other words, the high (parity) bit is set.  For example, I would like
to be able to say something like:

	*a 1 \340

to print the Greek character "alpha" in response to the nroff escape
"\(*a".  It would appear the problem is that nroff rejects non-ASCII
characters.  I tried fiddling with the "bset" flag in the driver table,
thinking that perhaps the c_oflag field of the termio structure might
have something to do with the problem, but I don't see any obvious bits
to set to deal with the situation.

My test procedure has been to run the command:

	nroff testfile | od -c

where "testfile" contains things like:

	alpha \(*a
	beta  \(*b

etc. after I have created the definitions in my /usr/lib/nterm/tab.nec table:

	*a 1 \340
	*b 1 \341

What has been happening is that sequences with octal values representing
characters with their high bits set (e.g., "\340") have been replaced by
spaces in the nroff output.  If I replace these characters with characters
without their high bits set, the mapping is done properly.

The other NEC P2200-specific problem has to do with the fact that it
is necessary to send an 8-bit zero character in connection with the
setting of certain modes.  For example, to select the Courier font
after some other font has been selected, it is necessary to send the
sequence "\033k\0" (<ESC>k<true-binary-zero>).  Problem is, I know of
no way to represent a zero byte by means of an nroff driver table.
(The obvious "\0" does not work; neither does a true-binary-zero in
the driver table file (you can see I've gone to extreme lengths).)

I'd dearly love to have a chat with the person who laid out the tables
for the P2200 control functions.  Grrr.

Any ideas would be appreciated!

-- 
Gary S. Trujillo			      {linus,bbn,m2c}!spdcc!gnosys!gst
Somerville, Massachusetts		     {icus,ima,stech,wjh12}!gnosys!gst


-- 
Gary S. Trujillo			      {linus,bbn,m2c}!spdcc!gnosys!gst
Somerville, Massachusetts		     {icus,ima,stech,wjh12}!gnosys!gst