groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Groff] Underlining, again


From: Ted Harding
Subject: RE: [Groff] Underlining, again
Date: Fri, 10 Sep 2010 21:35:54 +0100 (BST)

On 10-Sep-10 18:51:22, Peter Schaffter wrote:
> Can someone quickly remind me why .cu for the PostScript device
> can't be made to behave like .cu when it's called for a TTY?  In
> other words, it underline glyphs and spaces rather than converting
> text to italics?
> 
> Werner's ul.tmac is really clever, but I can't see how to get it to
> work in all the circumstances where I need it in conjunction with
> the mom macros.  The difficulty is that .Underline requires an
> argument, and there are places where isn't feasible to pass it one.
> 
> Mom is set up such that in normal typeset copy (.PRINTSTYLE TYPESET),
> 
>   Some text \*[IT]more text\*[PREV] other text.
> 
> renders <more text> in italic, but if one switches to
> typewriter-style output (.PRINTSTYLE TYPEWRITE), <more text> is
> underlined.
> 
> The underlining is a gross hack that places an underscore beneath
> each letter, with the result that spaces aren't underlined.  In many
> cases, this is acceptable, but when it comes to underlining book
> titles in bibliographies generated with refer, it isn't.
> 
> Mom's refer formatting is based on the ms refer module and uses
> 
>   .ref*field
> 
> to set up parameters for each field of a bibliographic entry
> (author, title, publisher, etc). ref*field takes five args:
> 
>   1) the field name (a single letter)
>   2) the punctuation character that separated the field from the
>      preceding one
>   3) a string with which to prefix the field
>   4) a string with which to postfix the field
>   5) a string to add after the punctuation character supplied by
>      the next field
> 
> Thus, for a book title,
> 
>   .ref*field T . " \E*[IT]" "" "\E*[PREV]"
> 
> .Underline can't be used in a scenario like this.
> 
> What's needed is a macro that can be called inline in arg 3 to start
> underlining, and another macro in arg 4 to stop underlining.
> Even if ul.tmac could be coerced into behaving this way (I've
> tussled with it, without success), it seems to me that the macros in
> ul.tmac are an awful lot of hoops to jump through for something as
> basic as underlining.
> 
> Hence wondering about .cu
> -- 
> Peter Schaffter

I made a serious attempt myself some years ago to try to crack the
underlining problem. The basic issue, of course, is that .cu, or .ul,
as you say, simply switches to "underlined font" (which in general
is italic).

I had hoped that a macro which exploited something like '\k[pos]'
might be made to work, but this only store the position from the
start of the *input* line, not the output line, so there's no way
to tell groff to "underline from this point on the output line to
the end of the output line" nor "from the start of the output line
to this point on the output line", which is what you would need
for the underlining of partial lines when you have continuous
underlining that extends over more than one output line.

The only way you could get at this would be to store the formatted
output in a diversion, which is the basis of Werner's excellent
(but complex) ul.tmac.

I also tried to think up a way of creating a macro which would
be called whenever a completed output line was about to be output.
Then you might be able to get at the position therein where the
underlining should start or stop (e.g. by planting an "invisible"
character therein which could be located when needed). However,
this also proved elusive! Except by the use of diversions, there
seems to be no way to access a formatted line before it is output.

I think the fundamental problem arises from groff's (i.e. troff's)
method of working, in which markup is interpreted as is it read in,
and it reads in only what is needed to get to the end of the current
output line. Hence it already knows how far down the page it is on
the basis of previously output lines (which is why .mk and .tr work
relative to the top of the page), but it does not know how far along
the current output line it is until this has been finally formatted
(because of potential stretching in fill mode).

One has the feeling that one could reach out and graso it, but it
always seems to be just a few inches further w=away than the length
of one's arm ...

Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 10-Sep-10                                       Time: 21:35:34
------------------------------ XFMail ------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]