From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#26959: Feature request: bold underlines Date: Wed, 17 May 2017 18:39:45 +0300 Message-ID: <83h90j5w72.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1495036018 3505 195.159.176.226 (17 May 2017 15:46:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 May 2017 15:46:58 +0000 (UTC) Cc: 26959@debbugs.gnu.org To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 17 17:46:51 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB1A2-0000kE-1y for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 May 2017 17:46:50 +0200 Original-Received: from localhost ([::1]:49594 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB1A7-0007t9-ID for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 May 2017 11:46:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB14V-0002w5-EU for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 11:41:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dB14Q-0005z5-Dl for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 11:41:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48394) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dB14Q-0005yr-8y for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 11:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dB14P-0008V4-V3 for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 11:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 May 2017 15:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26959 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26959-submit@debbugs.gnu.org id=B26959.149503561332609 (code B ref 26959); Wed, 17 May 2017 15:41:01 +0000 Original-Received: (at 26959) by debbugs.gnu.org; 17 May 2017 15:40:13 +0000 Original-Received: from localhost ([127.0.0.1]:51071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB13b-0008Tr-F4 for submit@debbugs.gnu.org; Wed, 17 May 2017 11:40:13 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB13a-0008Tg-G8 for 26959@debbugs.gnu.org; Wed, 17 May 2017 11:40:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dB13L-0005Sj-F7 for 26959@debbugs.gnu.org; Wed, 17 May 2017 11:40:05 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB13L-0005SM-9c; Wed, 17 May 2017 11:39:55 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3869 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dB13K-00080P-Ln; Wed, 17 May 2017 11:39:55 -0400 In-reply-to: (message from =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel on Wed, 17 May 2017 00:16:47 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:132569 Archived-At: > From: Clément Pit--Claudel > 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.