GNU bug report logs -
#26959
Feature request: bold underlines
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On 2017-05-17 11:39, Eli Zaretskii wrote:
>> From: Clément Pit--Claudel <clement.pitclaudel <at> 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 (application/pgp-signature, attachment)]
This bug report was last modified 8 years and 29 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.