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