From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Ruffing Newsgroups: gmane.emacs.bugs Subject: bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk Date: Mon, 15 Jan 2024 14:11:23 +0100 Message-ID: References: <0719018bb386e840efaa655b7c0b765ece9cd9ff.camel@timruffing.de> <83le9ys2d3.fsf@gnu.org> <3ebaf489f6dad748258c7fb01d3200b674ebb1f1.camel@timruffing.de> <83h6kmrzkz.fsf@gnu.org> <7ea3f7db448191f2b9886604084abe84d0caaf61.camel@timruffing.de> <83y1dxqm46.fsf@gnu.org> <83le9xqewb.fsf@gnu.org> <87h6klja8c.fsf@yahoo.com> <723b91276f83652bc6867f95630e1057c05ffb26.camel@timruffing.de> <87ttnj2uj6.fsf@yahoo.com> <83frz3j6bq.fsf@gnu.org> <87a5pa3m9q.fsf@yahoo.com> <83bk9qkc53.fsf@gnu.org> <875xzy3frj.fsf@yahoo.com> <831qamka3m.fsf@gnu.org> <871qam3dbr.fsf@yahoo.com> <83sf32iqs5.fsf@gnu.org> <87sf3212mz.fsf@yahoo.com> <83sf31hg72.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3539"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 67810@debbugs.gnu.org, stefankangas@gmail.com To: Eli Zaretskii , Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 15 14:12:11 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rPMl8-0000gn-HU for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Jan 2024 14:12:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPMl2-0005gO-IQ; Mon, 15 Jan 2024 08:12:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rPMl0-0005g0-9A for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 08:12:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rPMl0-0001xh-0p for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 08:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPMkz-0005Mk-P0 for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 08:12:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Tim Ruffing Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Jan 2024 13:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67810 X-GNU-PR-Package: emacs Original-Received: via spool by 67810-submit@debbugs.gnu.org id=B67810.170532431720616 (code B ref 67810); Mon, 15 Jan 2024 13:12:01 +0000 Original-Received: (at 67810) by debbugs.gnu.org; 15 Jan 2024 13:11:57 +0000 Original-Received: from localhost ([127.0.0.1]:44937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMku-0005MP-UQ for submit@debbugs.gnu.org; Mon, 15 Jan 2024 08:11:57 -0500 Original-Received: from mout-p-202.mailbox.org ([80.241.56.172]:40424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPMki-0005Lx-1i for 67810@debbugs.gnu.org; Mon, 15 Jan 2024 08:11:56 -0500 Original-Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4TDCFt0Gvcz9ssN; Mon, 15 Jan 2024 14:11:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timruffing.de; s=MBO0001; t=1705324296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=LMPjOfdf5sP03jN+e/B6bTvYj7dia0b0lk7+oOCap1s=; b=ngcRKRV/tiZ9ELy0j83tKRMFXAlJTuKFhCCVP5rKJYazArlbVciVS5k108zIQNHrrMMnOm jFSWjm8s8+6vy99dZfHyMfMl4FSSrkFVH51fpNtze8z9aCMNyOUAdWs9VZu94LU8+WdSVe ZWONzoOyJfJF/jasspoBd9BZtpR/rFGYUHxsXerqp6kXM8CWGnwk4zVUGR8AKKP/EHyQ+7 C5gDav2TB8A9iKKk7EjeHcRqrkURJLsH+YUKXzXmNc7/mmJ78tHxf7g2HuOSy0RQqFedwV y4Ze3AstdQxBT5UbLoURy6dD0IEsvSLUn/TCq/vcVtGKincLYhaditZBwM9ufA== In-Reply-To: <83sf31hg72.fsf@gnu.org> Autocrypt: addr=crypto@timruffing.de; prefer-encrypt=mutual; keydata=mQINBFz4LCMBEADLgtVg3uT+kybmXDPpXMvd8KBhTfAL5DP6umC9hkv/WHnfbCOUujhyvBljckcExAFr7tDYSgIjqa0L32SCT0NEaeY/s3WOYIacjBIEjTrgt01401lOWoX3XeYTWOlVUmUg+4iJPmBSPaj2bJR9Sq6NZhQjQ8K24VMtUNMiDeIIcstLkvQ4ZWkSuBUQJrJ0gUCZcUHNEyyGyZj1HOVGqGK7hTIiT1TfAgYKDDzk955LzgxbmATJWQLD7AGUIjKf/s418PTxI7Hh5ptH+Rq30+wkfvzJumYgkWUzeV6jzlOST5LkrFWQTfCXNvFNxSI9FVKjDIJZ7nQlgd+qNpGop90S3UqA8ofoG9liJm/jmbgIfJTgIiJpulycJD90PyJiWxtGshuZnHjCpkmU5vc1ZbuYyzH2wLoABSBsjy3Tb/25W2mnYnsOcVo1sWOGl+08Lb63ocVYGY27OrAIsv35pS/gMSGcJVg/EmPIM4+PmjeOxDlrJEW+8YzjKV9XtDv6VcBT1/OcA64knWC7JAGf0CGRodpolDjyfFRLOPV2/UbyOMJZjkxKTtV0je/RiMTupIHWcmimkvzpNo8D8U+Ac7KTPuPBrbj8EWeTbd/sK6bncjPL2DLomov0gCg/qlgObYmZ834+tQcThIBi3cj1cRj/0yKPy1uHgk2P2jO5i9AXGQARAQABtB9UaW0gUnVmZmluZyA8dGltQHRpbXJ1ZmZpbmcuZGU+iQJXBBMBCABBAhsBBQsJCAcCBhUKCQgLAgQWAgMBAh4 BAheAAhkBFiEECeA/hxCS5A4QbpArM7yGq4D/ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:278274 Archived-At: On Sat, 2024-01-13 at 08:59 +0200, Eli Zaretskii wrote: > > >=20 > > What if a user wants to disable the `bold' attribute for a font > > _with_ > > a bold variant? > >=20 > > That's not the feature I had in mind. I don't see why Emacs should > > allow users to disable font variants that do exist. AFAIU, the > > request was to prevent Emacs from creating a synthesized bold > > variant > > if the font doesn't have it, and that's all. =20 > >=20 Indeed. @Po: And I totally agree that emacs packages who use icons from symbol fonts should not set bold in the `face' property. However, as I said earlier in this thread, I claim that this solves 90% of the cases, but not all of them: Users may just want to insert icons in parts of their files with bold font-lock, e.g., headings in org files or markdown files (say you want to add a light-bulb icon in your notes for "ideas"). In this case, while org-mode or markdown-mode (or actually font-lock-mode) sets the bold face, these modes are not the ones that insert the icon, so they shouldn't be responsible for setting regular weight on icons.=C2=A0 I claim that's a valid use case. Of course, one can totally object that one should use SVGs, or that all of this is too niche so we shouldn't care about this, and that even a boolean option is not worth the complexity. And those are fine arguments, and after some more digging, I'm also not sure anymore... =20 Po wrote: > > > Would it make sense to introduce a variable that disables > > synthesizing > > > bold or oblique font variants? > >=20 > > I think it won't until someone informs us of how those features > > might > > be > > disabled in the font drivers that perform this. The Mac driver is > > definitely one of them, and possibly the Fontconfig driver as well. In fact, now I thought a bit more about this, I agree with your objections to having a simple knob that just disables overstriking in xfaces.c... Yes, this would help some users, and it's easy to maintain, but I suspect the behavior will be equally confusing to the current one. (Think about a candidate docstring: "Inhibits the creation of synthetic bold faces. This does not have an effect when the creation of synthetic bolds is done by emacs font drivers, e.g., this variable has no effect on Mac"... That is probably hard to understand for the average user, and also it's simply not a solution for Mac users.) I think you're right: If we want to add a boolean option, then it should probably should cover all instances where emacs creates synthetic bold fonts, i.e., not just the catch-all/fallback overstriking in xfaces.c but also the synthetic bolds in the various font drivers. (And the option should perhaps cover synthetic italics as well, not sure. Or there could be a second option...)=C2=A0 Yeah, then it's indeed more complex than a DEFSYM and two ifs. Though I believe the complexity will still be manageable and also I don't think we'll get bitten by this in the future: If this is an "inhibit"-style option, the only risk is that we'll ever have font driver in the future that creates synthetic bolds unconditionally. =20 I had a look at the mentioned drivers. For the MacOs driver, the property is set here in macfont.m, see uses of synthetic_bold_p for the actual drawing.=20 if (!(sym_traits & kCTFontTraitBold) && FONT_WEIGHT_NUMERIC (entity) =3D=3D FONT_WEIGHT_SYNTHETIC_BOLD) macfont_info->synthetic_bold_p =3D 1; For Fontconfig / FT, "git grep -i embolden src" will point you to some relevant code locations, but my digging shows that this driver will never create synthetic bolds on demand. [1]=C2=A0 So it's probably only overstriking and the font driver for MacOS that would be affected by an option.=C2=A0 Anyway, if people agree that an option should cover all drivers, the patch is >5 lines and someone will need to work on it. I may have a look in the future, but I currently don't have the time to work on it (and I don't have a Mac, so someone else would need to test it.) =20 Tim [1] Okay, and this is where it's a bit of mess.=C2=A0 While the code in the fontconfig driver doesn't have logic for creating an synthetic bold variant when we want to display bold text, it supports the "embolden" attribute that the user could set in their config, at least kind of: If I set this in my local.conf for fontconfig, then suddenly all fonts in all applications are synthetic bolds, and emacs respects this, too. true Of course, this is usually not meaningful. fontconfig ships with a config file that is actually meaningful and enables synthetic bold fonts when necessary, i.e., when no bold variant exists: medium bold true bold See the file 90-synthetic.conf, probably to be found in /etc/fonts/conf.d . But THAT setting one doesn't work in emacs.=20 The reason is that fontconfig works in two steps: 1. build a database of fonts 2. let applications query the database with pattern matching The second snippet above is supposed to have an effect in step 2. It basically says "if the application queries for bold, and we don't have native bold, set the embolden attribute in the query result". But here's the thing: emacs will simply never ask for bold. What emacs does is to ask fontconfig for the database resulting from step 1, and the database doesn't have the bold font because it doesn't exist. So emacs will learn that this is a font with weight "regular", and then emacs will forever believe that the font is regular, and just simply never query for a bold variant of it in step 2. This is just a consequence of trying to fit fontconfig into the font driver model of emacs. They use different concepts, and unless throw away all the emacs font code, it just won't be possible to make fontconfig as in other applications . (See my message #47 in this thread for a way to get around this in certain cases. One can set and this then will influence step 1 and thus the database itself. But this is rather crude and won't make the 90-synthetic.conf "on-demand" synthetic bold work: We really need to compare the query pattern with the actual font to determine whether embolden should be set. I said above that this is also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D25147 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17792 , but now I believe that this these were mostly fixed in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D35781 already...) The driver could, of course, set the embolden property automatically if there's no native bold variant, and this would probably give a nicer rendering than overstriking. Perhaps the driver should do this.