bug#26959: Feature request: bold underlines

[Eli Zaretskii <eliz@gnu.org>]

> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Wed, 17 May 2017 00:16:47 -0400
> 
> Could underline thickness be made configurable? It would be nice to be able to pick between regular and thick/bold underlines (the later would be obtained by doubling the usual underline thickness, I imagine).

You need to be aware of some subtleties with underlines as currently
implemented, and we should consider all of that when we decide what
kind of configurability we want and what should it do.  See below.

> > FWIW, on Windows I see neither straight nor wavy underline thicken.
> > They both continue to have the same line width (thickness) when
> > text-scaled.
> > 
> > Should they not stay the same?  Should they thicken?  Why?
> 
> Thanks for the reply! They do scale in GNU/Linux; the code in xftfont says:
> 
>       font->underline_position = -ft_face->underline_position * size / upEM;
>       font->underline_thickness = ft_face->underline_thickness * size / upEM;
> 
> The corresponding code in w32font says:
> 
>       font->underline_thickness = metrics->otmsUnderscoreSize;
>       font->underline_position = -metrics->otmsUnderscorePosition;
> 
> which might be missing the scaling?

Not all font back-ends support this scaling, and not with every font.
E.g., xfont.c doesn't support this at all, AFAICS.  And while we could
probably add this feature to MS-Windows, it will only be available
with OTF and TTF fonts (I believe it's the same on Unix and GNU
systems).

Moreover, if you mix fonts of different sizes on the same line in the
same run of consecutive underlined characters, you will see that Emacs
defines the thickness and the position of the underline at the first
character, and then reuses those values for the entire run, even if
the size of the font changes -- it doesn't recompute the values when
the font changes.  We do this because anything else will look uglier
than what we have now.

What all this means is that currently the exact visual effect of the
underline attribute is deliberately not well-defined: about the only
thing you can rely on is that you will get a horizontal line somewhere
in the lower portion of the characters.

Implementing your suggestion would require that we define the behavior
much better, which is not easy given the different font drivers and
fonts, on which the user has almost no control.  E.g., we will need to
decide whether thickness customization overrides the font-dependent
scaling, and if not, how these two play together.  And if we want to
allow customization of the underline position (why not?), we will have
to decide what to do with it when the font size changes.  And then we
will need to decide what to do if the font doesn't support scaling.

Bottom line: I think the hard part here is to describe the new
behavior, and do that in way that makes sense.  Implementing that
(assuming the fonts and font backends support the requirements) should
be relatively easy, once all of these hidden issues are figured out.