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#73752: 29.4; Ligatures are randomly rendered with extra spaces Date: Thu, 31 Oct 2024 02:39:09 +0100 Message-ID: <68b51105125b6c7a34ec8c2032588ce72d8557bc.camel@timruffing.de> References: <91cb4d5a6c979bf096ca9fa26711395ab29b941b.camel@timruffing.de> <86wmhp4obi.fsf@gnu.org> <86msil4mpn.fsf@gnu.org> <8f02b0490d2abb0889b760fb80c3ec492c63c784.camel@timruffing.de> <86ed3x4h7m.fsf@gnu.org> <86cyjh4dx5.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="11287"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73752@debbugs.gnu.org, xuan@xlk.me, visuweshm@gmail.com To: Eli Zaretskii , Tim Ruffing Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 31 02:40:24 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 1t6KAh-0002jd-II for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 31 Oct 2024 02:40:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t6KAP-0003QB-Ac; Wed, 30 Oct 2024 21:40:05 -0400 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 1t6KAN-0003Q0-H6 for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 21:40:03 -0400 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 1t6KAN-0007SC-7s for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 21:40:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:Date:From:To:Subject; bh=fQlcJ+xKbyCXYL8lqVMLG+q6I+HMIbnMkr1fgJDeYp4=; b=g9M9er+BBNj06pr5p5NuRfbqHexm9k5sNXMh6nkwbh1D2G4PWZoWWcGo78nMYRbE/YlqZbzmE1I1ReAhACqh9pmSWyYUGTHyDk0Q/SxcewQidvwRx9zT9j9Zz0iRtAWT9yx+s+IGdVxmn65++/t8ZPJr3ovkBNNJQsHeqvSWlRvRIorU1wlXQ219NcXdSMYVh7nv8G0EwNVMs1D3SvAoLx9DPiXlk+flunNwD+VfOpfcveSOMeoAwdXc+DOvCk8733+QyCn7g/umUQM1QFLCqcxxht8HFTI66xyFry9LOJ6Px4gljgV96IwkqVyZ9uC70obxb3j3TbHbyt/ZZihtLw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t6KAM-0001TN-28 for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 21:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tim Ruffing Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Oct 2024 01:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73752 X-GNU-PR-Package: emacs Original-Received: via spool by 73752-submit@debbugs.gnu.org id=B73752.17303387635636 (code B ref 73752); Thu, 31 Oct 2024 01:40:02 +0000 Original-Received: (at 73752) by debbugs.gnu.org; 31 Oct 2024 01:39:23 +0000 Original-Received: from localhost ([127.0.0.1]:38809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6K9j-0001Sq-CZ for submit@debbugs.gnu.org; Wed, 30 Oct 2024 21:39:23 -0400 Original-Received: from mout-p-102.mailbox.org ([80.241.56.152]:37272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6K9h-0001Sk-5U for 73752@debbugs.gnu.org; Wed, 30 Oct 2024 21:39:22 -0400 Original-Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (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-102.mailbox.org (Postfix) with ESMTPS id 4Xf69C5Dx2z9t5C; Thu, 31 Oct 2024 02:39:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=real-or-random.org; s=MBO0001; t=1730338751; 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; bh=fQlcJ+xKbyCXYL8lqVMLG+q6I+HMIbnMkr1fgJDeYp4=; b=aCgv36A4NguRG9P3Q+Txy4/OgnNmEFNLAFC+I8Luy73LM6MmlAfvzKRgf9Ui9nLhWMwRur eCH+R3yJBlbbUZyFQybS3FMWuI0td40D7KX4NuxpDT45cX71zI38hNY2yQC4lcedMoWXaq f7+gtAisy22TDybYcjDn2NssJGcgY2KEGTboICO7GpJB2ICMOCdR1R294wfE6/16IQbYad crwpycVPwdC58nla99NCaI6DoGAVwwi2dymv0G406B5XALVmZnQIMM3JhDfEf1nk3NoKT4 AlHMRerfInWJuO9IEsv2YffFPYXZND5sBf9iqm/CNdHDnB1YAnmRoNlw3aPs2A== In-Reply-To: <86cyjh4dx5.fsf@gnu.org> X-Rspamd-Queue-Id: 4Xf69C5Dx2z9t5C 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:294588 Archived-At: On Wed, 2024-10-30 at 20:57 +0200, Eli Zaretskii wrote: >=20 >=20 > Then what exactly is the difference between the session with "good" > display and the one with the "bad" display?=C2=A0 How come they show the > same ligature differently?=C2=A0 What did you do to make them have > different looks? Nothing (that I'm aware of.) This appears to be non-deterministic. Sometimes it works, sometimes it doesn't. And Yixuan seems to say the same when he says that this looks like race condition. It will still be useful to figure out what sets the [X-OFF Y-OFF WADJUST] vectors instead of nil. After digging into the code a bit, I strongly suspect it's composition_gstring_adjust_zero_width. I'm not sure if I have the time to verify this in the coming days, I'd appreciate if some of the other affected users could give it a try.=C2=A0 I'm not claiming that composition_gstring_adjust_zero_width is wrong, but if my theory is right that it sets the vector if and only if the rendering is bad, then we'll be a step further. This function was introduced in cd88f6de4be1f8eba1db038b371d769f584be53b because of bug#50951. AFAIU it is supposed to correct a grapheme width of 0 pixels to 1 pixel, so that won't explain why large spaces are added. But I skimmed bug#50951 and there are some mentions that composition_gstring_adjust_zero_width is supposed to suppress adding the "space width of the font", which is what some people see here, so all of this sounds a bit related. Next question would be why emacs thinks that the grapheme width was zero in the first place. Tim =20