Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC830919); site mcvax.UUCP
Path: utzoo!linus!philabs!mcvax!jaap
From: jaap@mcvax.UUCP (Jaap Akkerhuis)
Newsgroups: net.text,net.bugs.4bsd,net.bugs.usg
Subject: Re: Problem with NROFF '.cu' command
Message-ID: <5523@mcvax.UUCP>
Date: Wed, 23-Nov-83 20:09:14 EST
Article-I.D.: mcvax.5523
Posted: Wed Nov 23 20:09:14 1983
Date-Received: Fri, 25-Nov-83 03:32:49 EST
References: <1639@ihuxf.UUCP> <5518@mcvax.UUCP>
Organization: Math.Centre, Amsterdam
Lines: 23

Sorry about it, but I have made a mistake.

If the .cu command is effective, the spaces on the input will be changed
to an "_". So the complete input line will be considered as a single
word by nroff. (Note: this only happens in nroff).
It is done in the routine gettch(), in n7.c.

It is probably possible to delay the underlining after the line filling has
taken place.

You probably want to remove the spaces to "_" translation in gettch.
Then you want to do something in n10.c. There are two possible points:
1)	In move() you can generated the desired numbers of underlines, when
	it is processing the "esc", but it will likely have a bad effect if
	.ce as well as .cu is effective, also the local motions (\h'x')
	will get problems.
2)	In ptout1() is a test or the character is a space.
	The "esc" will then enlarged with the t.Char.
	Of course this will be a nice point to change it in an "_", but
	the underlining will be not continuous, if you allow the spaces to
	be plotted for nicer adjusting on f.i. a Diablo printer.

		jaap akkerhuis, ...mcvax!jaap