From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Newsgroups: gmane.emacs.bugs Subject: bug#26959: Feature request: bold underlines Date: Wed, 17 May 2017 14:59:56 -0400 Message-ID: <6ad09d0f-d9e5-d544-f2e1-a7bf561556f6@live.com> References: <83h90j5w72.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RtCjLcV5kNopUIbAcGg7S4D2xo7kJ13UT" X-Trace: blaine.gmane.org 1495047677 8692 195.159.176.226 (17 May 2017 19:01:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 May 2017 19:01:17 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 Cc: 26959@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 17 21:01:10 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 1dB4C6-00026G-0X for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 May 2017 21:01:10 +0200 Original-Received: from localhost ([::1]:50414 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB4CB-0007cG-Dg for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 May 2017 15:01:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB4C2-0007aj-IN for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 15:01:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dB4By-0004fP-LD for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 15:01:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48612) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dB4By-0004fG-Et for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 15:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dB4By-0004lt-3d for bug-gnu-emacs@gnu.org; Wed, 17 May 2017 15:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 May 2017 19:01:02 +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.149504761418277 (code B ref 26959); Wed, 17 May 2017 19:01:02 +0000 Original-Received: (at 26959) by debbugs.gnu.org; 17 May 2017 19:00:14 +0000 Original-Received: from localhost ([127.0.0.1]:51289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB4BB-0004kj-Jx for submit@debbugs.gnu.org; Wed, 17 May 2017 15:00:13 -0400 Original-Received: from mout.kundenserver.de ([217.72.192.74]:53541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB4B9-0004jm-K2 for 26959@debbugs.gnu.org; Wed, 17 May 2017 15:00:12 -0400 Original-Received: from [18.189.18.195] ([18.189.18.195]) by mrelayeu.kundenserver.de (mreue104 [212.227.15.184]) with ESMTPSA (Nemesis) id 0MDPnp-1dCRbt22cH-00GpPM; Wed, 17 May 2017 21:00:04 +0200 In-Reply-To: <83h90j5w72.fsf@gnu.org> X-Provags-ID: V03:K0:aoEvGYEioSsaHIFfMU+T6vDjQz6425R3AvnLF0sNgRcDLsgZHQ3 XTqHDBGIDxSqp31lFd+m2X3B5ZF4KRy4pqmiIE7spt4SBDs5FbCGa9U8IonVwijkP3M2xbK Tl3O/hjAOHjn8C3A89iIeOpfbmXL/pchC/A0h95EWe22LrUQDy9j2aCmdLwsShzNUqgCiP8 ragL8450IF7vhP+/tNhyg== X-UI-Out-Filterresults: notjunk:1;V01:K0:HkAL7x7NuLw=:opbNOR3is4dpl2CG3AE4kt 75vBUp3H11O64oYOXL/mP4KI6/1al/F+ixD3NCBmWVw06TknM7LSthQIRr5B2eBjqCsgSsJUp WqVwJSrYv5/2uD+BrZZy2Z6CV/E0sjCR7r77dOT8gvfrpMbpMVEpzC5peSbZACNIDii3wwZdk JV7Zw3tpJsmKCBVpJhM+lUueQ0PxOtid7Wqy8ZBdQ2P3+WZ7J97aCdPEnPeF3/psrvLIQqu4s wTZIWwhVCoW7C1PyZ5iyk7xcEeQ0RXEpIbmE701PLBHwXcAmYTgmqWkvAnJFuS50h5DJ0WEBW WAxlC5OYMQwUSgGXuGTmbcN4zcCDw4wBt9E32RaDRw33/inFjGXWWxQUSpBn8IMSX0AOo02n1 3z6p01VECurV1BRq4MY89XxrIXTKodn8fZzEy5whb3XRc/RbDsWk3TEOLzIAzcnPLGW6v1c1V fREH+imMA8Lm+yxstCv3Pj+jTcmm3jmI3YyzamRVYuaiiECVWk6GkzJ0eapFV0JfwxysBKKUi bGhgdMau/FH6dz8EEndSqf/stuP7Yb2otDt+FXqkfCcBFb+DtfTzTG6LvHnzv4hqa8sIPiUbI MZJzhUvJcz/nEuERlLdFE7+BUi5NEgKlIntuZMIK6o0coKXr7+p2i6UObmZtix79ZmZdaVm3G JtJh2S1DDpi0axz5SrQehgfXdx8qnn7Ae/YsgJV5wgeydvsNMiP0lJXYMKWU7Tzd6+To= 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:132575 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RtCjLcV5kNopUIbAcGg7S4D2xo7kJ13UT Content-Type: multipart/mixed; boundary="n3k6fUCeJupFhCMlPD40VIbb6elj1PCUS"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= To: Eli Zaretskii Cc: 26959@debbugs.gnu.org Message-ID: <6ad09d0f-d9e5-d544-f2e1-a7bf561556f6@live.com> Subject: Re: bug#26959: Feature request: bold underlines References: <83h90j5w72.fsf@gnu.org> In-Reply-To: <83h90j5w72.fsf@gnu.org> --n3k6fUCeJupFhCMlPD40VIbb6elj1PCUS Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 2017-05-17 11:39, Eli Zaretskii wrote: >> From: Cl=C3=A9ment 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). >=20 > 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. >=20 >>> 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 =3D -ft_face->underline_position * size= / upEM; >> font->underline_thickness =3D ft_face->underline_thickness * siz= e / upEM; >> >> The corresponding code in w32font says: >> >> font->underline_thickness =3D metrics->otmsUnderscoreSize; >> font->underline_position =3D -metrics->otmsUnderscorePosition; >> >> which might be missing the scaling? >=20 > 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. >=20 > 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?=20 In terms of code, my suggestion would translate into multiplying the `thi= ckness' variable in xftfont by 2 when :bold t is specified in the underli= ne'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=C3=A9ment. --n3k6fUCeJupFhCMlPD40VIbb6elj1PCUS-- --RtCjLcV5kNopUIbAcGg7S4D2xo7kJ13UT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZHJ2sAAoJEPqg+cTm90wjsUcP/22h3tblOUEy9R0QtaXlgjIv BWa37FpJ4EJDj1NRPjXwI5/0m+cIHFN6ucukBE3YZsFhZcHKGjUmsPOv9M/Jxepg XxtHUifgvwYeaJxj9FjZr8cCoPeOc3DowPRpSj0ksItmOL2J3z4bzIDUPQsQgW3M k55a+MfEqSN/neG1YXfhbW4kWlm3uLgG3Bjy4oRdXhgZ9yNzrNJSDI/voBpyvPG0 anaolfj2iIhkgNcj9DTEVJH9quBtF+aJMoXqzxlDkOUk0FriAyfGRF8n4/n/iHxx fLG7CnqKxttft8IG8LuIngKi8qMso8tU1kn9BbiFANlpzShRpsfDqEf/mk4YOPTD eUf63Lm0NZSEqOr/k2DcDO7sCOPSUlCfNA5JlOp6G16g9UhBr6waVyzoXkd+BZJW dTraeavWZJegj78yHsGBI+kb4aG590KBeG2Ed0pdvEu9zeKnuUMOJBRKsMDm35dv YHZCV5VYYW4mT1//HIwOrWCGLqt49aEEa2nQOG3+hCk/HIOoJVTFxE1V9bWWNXZM VDnPGBYrAW6oQNdzBcl2r+f9uCPEwcV/z7ktqBDlpFmn68cQXup7yTmYURzBFght 21a6BXapCDM63Hp1Bp/cqnzL+b99C1ISsGJvtvhj8z6puDq+VyvWk5724EVNRoHi Jj1aEZhcXiEfvOAsJvJq =mua1 -----END PGP SIGNATURE----- --RtCjLcV5kNopUIbAcGg7S4D2xo7kJ13UT--