From: Eli Zaretskii <eliz@gnu.org>
To: "Clément Pit--Claudel" <clement.pitclaudel@live.com>
Cc: 26959@debbugs.gnu.org
Subject: bug#26959: Feature request: bold underlines
Date: Wed, 17 May 2017 18:39:45 +0300 [thread overview]
Message-ID: <83h90j5w72.fsf@gnu.org> (raw)
In-Reply-To: <b7f45023-40c2-61c3-e0ad-347b9a794631@live.com> (message from Clément Pit--Claudel on Wed, 17 May 2017 00:16:47 -0400)
> 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.
next prev parent reply other threads:[~2017-05-17 15:39 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 [this message]
2017-05-17 18:59 ` Clément Pit--Claudel
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=83h90j5w72.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=26959@debbugs.gnu.org \
--cc=clement.pitclaudel@live.com \
/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.