From: "Clément Pit--Claudel" <clement.pitclaudel@live.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 26959@debbugs.gnu.org
Subject: bug#26959: Feature request: bold underlines
Date: Wed, 17 May 2017 14:59:56 -0400 [thread overview]
Message-ID: <6ad09d0f-d9e5-d544-f2e1-a7bf561556f6@live.com> (raw)
In-Reply-To: <83h90j5w72.fsf@gnu.org>
[-- Attachment #1.1: Type: text/plain, Size: 3630 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2017-05-17 18:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-17 4:16 bug#26959: Feature request: bold underlines Clément Pit--Claudel
2017-05-17 4:21 ` Drew Adams
2017-05-17 4:39 ` Clément Pit--Claudel
2017-05-17 14:04 ` Drew Adams
2017-05-17 15:06 ` Clément Pit--Claudel
2017-05-17 16:06 ` Drew Adams
2017-05-17 18:48 ` Clément Pit--Claudel
2017-05-17 19:48 ` Drew Adams
2017-05-17 20:11 ` Clément Pit--Claudel
2017-05-17 21:09 ` Drew Adams
2017-05-17 21:22 ` Clément Pit--Claudel
2017-05-17 21:37 ` Drew Adams
2017-05-17 15:39 ` Eli Zaretskii
2017-05-17 18:59 ` Clément Pit--Claudel [this message]
2017-05-18 4:10 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6ad09d0f-d9e5-d544-f2e1-a7bf561556f6@live.com \
--to=clement.pitclaudel@live.com \
--cc=26959@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.