Re: [Groff] underlining in nroff

[Mark Nudelman]

Although I think I'm missing some of the context of this discussion, I'll
comment on the final three paragraphs.

An underlined space is indeed displayed as a space in underlined mode.  This
is intentional behavior, not a bug or "laziness".  Any underlined character
(by definition, overstruck with an underscore) is displayed in underlined
mode.  Although the argument that an underlined space looks exactly like an
underscore on a tty has some merit, I think the current behavior is better
for several reasons: (1) It more correctly represents the contents of the
file.  I try to avoid cases where two different input files have identical
visual representations.  (2) It is more consistent, and doesn't treat the
space character as a special case.  If it did, you'd have to decide what to
do about other "space like" characters in non-ASCII charsets.

An underlined underscore would be treated the same way, except that it just
so happens that the bold attribute (overstriking a character with itself)
takes precedence, so an underscore overstruck with an underscore is
displayed as an underscore in bold, not underlined.  Clearly there's no way
to tell the intent in this case, so I don't think there's a strong argument
to do it one way or the other, although I'm open to arguments that
underlining would be more appropriate than bold in this case.  (Looking at
the context of the surrounding characters is a possible, although rather
ugly, solution.)  Back to (what I think was) the original issue, the
problems you're seeing are probably a result of different fonts displaying a
bold underscore differently.
--Mark


----- Original Message -----
From: "Werner LEMBERG" <address@hidden>
To: <address@hidden>
Cc: <address@hidden>; <address@hidden>
Sent: Saturday, March 31, 2001 8:07 AM
Subject: Re: [Groff] underlining in nroff


>
> May I ask the less maintainers to comment this?  Using various fonts
> with xterm, I get various results.  Sometimes, it appears as if an
> underlined underscore is shown, sometimes not.  What exactly is the
> expected behaviour?  It seems to me that many X fonts are broken (at
> least those which come with XFree86 3.3.6) or don't behave
> consistently w.r.t. this problem.
>
> BTW, `xterm -version' gives
>
>    XFree86 4.0(129)
>
>
>      Werner
>
> ======================================================================
>
> From: address@hidden (Larry Jones)
> Subject: Re: [Groff] underlining in nroff
> Date: Sat, 31 Mar 2001 02:10:55 -0500 (EST)
>
> > Werner LEMBERG writes [quoting me]:
> > > >
> > > > So it does.  I'd call that a bug in less -- printing a space on
> > > > top of an underscore shouldn't change the visual appearance of
> > > > the underscore.
> > >
> > > Is it really a bug?  I don't think so.  I think the current
> > > solution in less (i.e. to make a visual difference between an
> > > underlined space and an underscore character) is good.  The only
> > > `limitation' is that an underscore character can't be underlined.
> >
> > Why not?  If you're going to interpret "_^H " as an underlined
> > space, then it would only make sense to interpret "_^H_" as an
> > underlined underscore.  I stand by my original statement -- it's a
> > bug in less, probably caused by laziness, carelessness, and/or a
> > display device where the underline and the underscore line up.
> > Certainly "_" and "_^H " are indistinguishable when printed on a
> > traditional TTY, and that's what less is supposed to be emulating!
> >
> > -Larry Jones