[net.text] Problem with NROFF '.cu' command

donn@sdchema.UUCP (Donn Seeley) (11/08/83)

Some poor user came to me with a sad NROFF story (yes, I know there
are lots of sad NROFF stories).  She has to enter some papers for
a supervisor and this other person insists that titles in their
bibliography have continuous underlining -- underlining individual
words is completely unsatisfactory.  She thought she could use the
NROFF '.cu' command to do the underlining, but it didn't turn out
right and she came to me to see if I could fix it.

Much as I abhor gazing upon our 4.1 BSD NROFF's innards, I did spend
some time looking at the source to learn NROFF's procedure for handling
the '.cu' command.  Essentially NROFF turns on normal underlining and
at the same time translates input spaces to underscores.  Unfortunately
underscores do not break a word, so every word on a line of input text
is glued together into a single massive word and spaces appear where
there were input line breaks.  The result is completely ridiculous in
a bibliography, or indeed anywhere that there is text filling.  As
far as I am concerned, '.cu' is worse than worthless -- why do it at
all if it can't be done correctly?

Has anyone out there fixed this problem before? By a fix, I mean that
it should be possible to have continuously underlined words filled
properly...  If you use ITROFF or System V NROFF (we are licensed for
both), could you check to see if this problem still exists?

Thanks in advance,

Donn Seeley  UCSD Chemistry Dept. RRCF  ucbvax!sdcsvax!sdchema!donn

parnass@ihuxf.UUCP (Robert S. Parnass, AJ9S) (11/18/83)

x
       I've used nroff in both 4.0 and 5.0 versions of UNIX1.	For
       continuous  underlining	in  nroff, I believe you must place
       all words to be underlined on a separate	line, following	the
       ".cu" command.  For example:

		  This line won't be underlined.
		  .cu
		  This line will be underlined.
		  This line won't be underlined.

       __________

	1. UNIX	is a trademark of AT&T Bell Laboratories.


-- 
============================================================================
Robert S. Parnass, AT&T Bell Laboratories, ihnp4!ihuxf!parnass (312)979-5760 

jaap@mcvax.UUCP (Jaap Akkerhuis) (11/21/83)

   .... '.cu' command.  Essentially NROFF turns on normal underlining and
   at the same time translates input spaces to underscores.  Unfortunately
   underscores do not break a word, so every word on a line of input text
   is glued together into a single massive word and spaces appear where
   there were input line breaks.  The result ....

No, your are wrong with this. The underlining will be done after all
processing, like adjusting etc. has be done.
Look in n10.c for the details.

The .cu request has always worked in 4.?BSD n/troff, is is nearly the same
as the V7 version.

Since you don't tell what is going wrong, I'm afraid nobody can help you.

Jaap Akkerhuis ...!mcvax!jaap.

jaap@mcvax.UUCP (Jaap Akkerhuis) (11/21/83)

As is says in the manual, .cu N will do the same as .ul N, but will underline
any character in NROFF. The .UL N will underline N input lines.

Jaap Akkerhuis, ...!mcvax!jaap

colonel@sunybcs.UUCP (George Sicherman) (11/21/83)

The basic problem is with the humanware.  Since it's her
supervisor who wants this ugly feature, it's his responsibility
to implement it.

jaap@mcvax.UUCP (Jaap Akkerhuis) (11/24/83)

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