bug#26959: Feature request: bold underlines

[Clément Pit--Claudel]

On 2017-05-17 11:39, Eli Zaretskii wrote:
>> 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).

Makes sense. And, of course, the scaling is outside of Emacs' control on TTYs.

> 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.

I saw this, indeed.

> 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.

That makes sense, but I'm not sure all of this is needed. I agree that it would 
be nice, but is it really necessary? 
In terms of code, my suggestion would translate into multiplying the 
`thickness' variable in xftfont by 2 when :bold t is specified in the 
underline's property list.

> 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.

Thanks for the explanation.
Clément.

signature.asc
Description: OpenPGP digital signature