From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 21 11:15:04 2025 Received: (at submit) by debbugs.gnu.org; 21 Aug 2025 15:15:04 +0000 Received: from localhost ([127.0.0.1]:60869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1up70I-00046Q-Ex for submit@debbugs.gnu.org; Thu, 21 Aug 2025 11:15:04 -0400 Received: from lists.gnu.org ([2001:470:142::17]:37826) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1up6I5-0001np-Ry for submit@debbugs.gnu.org; Thu, 21 Aug 2025 10:29:23 -0400 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 1up6Hy-0007W0-4R for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2025 10:29:14 -0400 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1up6Ht-0006kJ-Vd for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2025 10:29:13 -0400 Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-45b4d892175so3733935e9.2 for ; Thu, 21 Aug 2025 07:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755786546; x=1756391346; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=kankiADm+PUGu61tCCcdL2t7gArVBdtX9FZ/zP5co+o=; b=RYYIMZv2AVj3CeEZILs4luurga8VUBZrgn2rDcV5d7jA4xIS1KhIT+cFKkuo5a2XsJ tSwlUtSryu/4k3fvAQb1zhYfGkMa33LjFXCnq2Pd6q7eoWM65yQ/PWSKOYkWspCs0+ts fIkVhOvwd/Kk+ZT/7cDh8Sn7x4qPfSxGGjYqkn2hJonsl8FUaxp08kDTeM0mGuwiMWNh E+b/XsRi+jTNvOrhWFBMrfe5PfmgFTQ8uxpGeSy0pKsMZfcEFc3EurYlR0hys/MQFyOg Xv0HhZDBG68XJ7LKz+brLB2MyTtNigadiVqZ0sLGoxDX7Mq2eiqcBKRLi33EvJVy7VLS IDoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755786546; x=1756391346; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=kankiADm+PUGu61tCCcdL2t7gArVBdtX9FZ/zP5co+o=; b=vR8KKiLo19R7/4vWgHk3e/xlDlVL95nOgO6E3PLhWeNtEtK0cMp35/x4jQmFVg3pn7 a1CYNNPPTDzMYlVX3M6HUDW26t86ne1xSvkadhR3P9OdkuPBATwZiZx9bdctYciH+udi tm7JLZTjDkMFFtiQPxgzj7mTwQL0KliQqh5oUQEMcbJgptBSaz9J1Vq8YGVIL6lBl8rt edmgIgq1q1xhzDC7OBHlOVT8bSTbPRZbn9NJBnf8WOrId3aTbGd+micaX7MCog7dTite RU9gRlBPPDQPXJ/Pctwq6tF4h1sCD0WzQYQ7U3WyBrR85S38Uq1C3Dh99iZtadzNcimU z8BQ== X-Gm-Message-State: AOJu0YwfRpIo/iNORqMtPLbWSKjZtKtmu/lH5oIz1Ej5DetdpegfrrPw aC2F6l6+QkaOsI2MbYkmaA5mE1Nd8hBMPjqfy9Wb2J1eh6Uwzli3EL/TpJf2cTvceR8bYcVxG7a xCWLwLYoYRXo95bbE5ZDjeVkzl5QpcOkjTX3z X-Gm-Gg: ASbGncvgPolIK7gYjyJ0xb7IzCFUrg/nbiP1U/M2F3Ad3NVulThTZFC8iQ05SimZaX3 F81o9cqagYzoZ9DApx6On0CL4tODkRo4I63fPedWgdDLWihYx0YBWHNM9Q2lnk2F4thKvnVTmg7 vScHoAWTNgzz/gdJ6sRokXzvN4M+lcng8fK/ki3lS33EfA9cIRjpHYT5vy4uwhqI2xIKK/RYvKN JFjqE+XlocFYT1OgoF4lafulDnWNXaTIdF8 X-Google-Smtp-Source: AGHT+IGdC3WNc3OJA5p0GElkaxEMjKDQlyTY+6RJNH4Rsky2Y3pq7GsIV5s+JcW37PQHfojR2KP51Bak9Bt1qV4D9LA= X-Received: by 2002:a05:600c:1909:b0:43c:ea1a:720a with SMTP id 5b1f17b1804b1-45b4d7cef1amr18215455e9.1.1755786545540; Thu, 21 Aug 2025 07:29:05 -0700 (PDT) MIME-Version: 1.0 From: Binbin YE Date: Thu, 21 Aug 2025 23:28:53 +0900 X-Gm-Features: Ac12FXwFNk1DgIBKQhlYJ2WDMv8_imwD384xZEGNPE-8ZeAltpt3tmaxZanr2YM Message-ID: Subject: [Patch] support :font-features in face To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="000000000000594a7b063ce0e9d1" Received-SPF: pass client-ip=2a00:1450:4864:20::32b; envelope-from=phantom2501@gmail.com; helo=mail-wm1-x32b.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Greetings, It is my first time trying to contribute to Emacs source code. The change is adding support for enabling stylistic set (font features) when using harfbuzz font backend. It is a commonly supported feature in the editors. See following links Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (phantom2501[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (phantom2501[at]gmail.com) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 21 Aug 2025 11:15:00 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --000000000000594a7b063ce0e9d1 Content-Type: multipart/alternative; boundary="000000000000594a79063ce0e9cf" --000000000000594a79063ce0e9cf Content-Type: text/plain; charset="UTF-8" Greetings, It is my first time trying to contribute to Emacs source code. The change is adding support for enabling stylistic set (font features) when using harfbuzz font backend. It is a commonly supported feature in the editors. See following links https://code.visualstudio.com/docs/terminal/appearance#_font-feature-settings https://developer.mozilla.org/en-US/docs/Web/CSS/font-feature-settings The change adds :font-feature configuration like following (set-face-attribute 'default nil :font "JetBrains Mono" :height 80 :font-features '((zero . 1) (ss19 . 0) (calt . 1))) The render result can be confirmed by adding "0" to composition table (set-char-table-range composition-function-table ?0 '(["." 0 font-shape-gstring])) I have read the CONTRIBUTE file and tried to make the commit message as clear as possible. Please let me know the code review process to get the patch accepted. Best, Binbin --000000000000594a79063ce0e9cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

It is my first ti= me trying to contribute to Emacs source code.

The = change is adding support for enabling stylistic set (font features) when us= ing harfbuzz font backend. It is a commonly supported feature in the editor= s. See following links

=


The change adds :font-= feature configuration like following

(set-face-att= ribute 'default nil :font "JetBrains Mono" :height 80
=C2= =A0 :font-features '((zero . 1) (ss19 . 0) (calt . 1)))

<= /div>
The render result can be confirmed by adding "0" to com= position table=C2=A0

(set-char-table-range composi= tion-function-table
=C2=A0 ?0
=C2=A0 '(["." 0 font-shap= e-gstring]))

I have read the=C2=A0CONTRIBUTE file = and tried to make the commit message as clear as possible. Please let me kn= ow the code review process to get the patch accepted.

<= div>
Best,

= Binbin
--000000000000594a79063ce0e9cf-- --000000000000594a7b063ce0e9d1 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-support-configuring-font-features-in-face.patch" Content-Disposition: attachment; filename="0001-support-configuring-font-features-in-face.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_melhyht50 RnJvbSA2NTQyYTkyOGZiYjk2YjcxYWQzMzVlNWM4ZTlhZDc3OTUwOGExZjJjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCaW5iaW4gWWUgPHBoYW50b20yNTAxQGdtYWlsLmNvbT4KRGF0 ZTogU2F0LCAxNiBBdWcgMjAyNSAyMzoyNjozMyArMDkwMApTdWJqZWN0OiBbUEFUQ0hdIHN1cHBv cnQgY29uZmlndXJpbmcgZm9udCBmZWF0dXJlcyBpbiBmYWNlCgpzdXBwb3J0IGNvbmZpZ3VyaW5n IGZvbnQgZmVhdHVyZXMgaW4gZmFjZSB3aGVuIHVzaW5nIGhhcmZidXp6IGJhY2tlbmQKdXNpbmcg YDpmb250LWZlYXR1cmVzJwoKKiBzcmMvZGlzcGV4dGVybi5oIChsZmFjZV9hdHRyaWJ1dGVfaW5k ZXgpOiBBZGQKTEZBQ0VfRk9OVF9GRUFUVVJFU19JTkRFWAoqIHNyYy9mb250LmMgKGZvbnRfbG9h ZF9mb3JfbGZhY2UpOiBTdG9yZSBmb250IGZlYXR1cnMgaW4gZXh0cmEgaW5mbwoqIHNyYy9oYmZv bnQuYyAoaGJfZmVhdHVyZXNfZnJvbV9saXNwLCBoYmZvbnRfc2hhcGUpOiBDb252ZXJ0IGZhY2UK c2V0dGluZ3MgdG8gaGFyZmJ1enogZmVhdHVyZXMgYW5kIHBhc3MgdG8gaGJfc2hhcGVfZnVsbAoq IHNyYy94ZmFjZXMuYyAobGZhY2VfaGFzaCwgbGZhY2Vfc2FtZV9mb250X2F0dHJpYnV0ZXNfcCkK KEZpbnRlcm5hbF9zZXRfbGlzcF9mYWNlX2F0dHJpYnV0ZSwgRmludGVybmFsX3NldF9saXNwX2Zh Y2VfYXR0cmlidXRlKQooY2hlY2tfbGZhY2VfYXR0cnMsIG1lcmdlX2ZhY2VfcmVmKTogVXBkYXRl IGZhY2UgY29tcGFyaXNvbiwgZ2V0dGVyIGFuZApzZXR0ZXIgZnVuY3Rpb25zCi0tLQogc3JjL2Rp c3BleHRlcm4uaCB8ICAxICsKIHNyYy9mb250LmMgICAgICAgfCAgNSArKysrKwogc3JjL2hiZm9u dC5jICAgICB8IDUwICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrLQogc3JjL3hmYWNlcy5jICAgICB8IDQ4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrLS0KIDQgZmlsZXMgY2hhbmdlZCwgMTAxIGluc2VydGlvbnMoKyksIDMg ZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2Rpc3BleHRlcm4uaCBiL3NyYy9kaXNwZXh0 ZXJuLmgKaW5kZXggMTlhYjEwNGQyZTYuLjIwYTkwMWI5ZjQwIDEwMDY0NAotLS0gYS9zcmMvZGlz cGV4dGVybi5oCisrKyBiL3NyYy9kaXNwZXh0ZXJuLmgKQEAgLTE3MDUsNiArMTcwNSw3IEBAICNk ZWZpbmUgRk9OVF9UT09fSElHSChmdCkJCQkJCQlcCiAgIExGQUNFX0ZPTlRTRVRfSU5ERVgsCiAg IExGQUNFX0RJU1RBTlRfRk9SRUdST1VORF9JTkRFWCwKICAgTEZBQ0VfRVhURU5EX0lOREVYLAor ICBMRkFDRV9GT05UX0ZFQVRVUkVTX0lOREVYLAogICBMRkFDRV9WRUNUT1JfU0laRQogfTsKIApk aWZmIC0tZ2l0IGEvc3JjL2ZvbnQuYyBiL3NyYy9mb250LmMKaW5kZXggZGZlNDc5ZjkzNTUuLmQz MWQ3MGQ2MDUwIDEwMDY0NAotLS0gYS9zcmMvZm9udC5jCisrKyBiL3NyYy9mb250LmMKQEAgLTM0 ODIsNiArMzQ4MiwxMSBAQCBmb250X2xvYWRfZm9yX2xmYWNlIChzdHJ1Y3QgZnJhbWUgKmYsIExp c3BfT2JqZWN0ICphdHRycywgTGlzcF9PYmplY3Qgc3BlYykKICAgICB7CiAgICAgICBuYW1lID0g RmZvbnRfZ2V0IChzcGVjLCBRQ3VzZXJfc3BlYyk7CiAgICAgICBpZiAoU1RSSU5HUCAobmFtZSkp IGZvbnRfcHV0X2V4dHJhIChlbnRpdHksIFFDdXNlcl9zcGVjLCBuYW1lKTsKKworICAgICAgLyog U3RvcmUgZm9udCBmZWF0dXJlcyBmcm9tIGZhY2UgYXR0cmlidXRlcyBmb3IgdXNlIGR1cmluZyBz aGFwaW5nICovCisgICAgICBMaXNwX09iamVjdCBmb250X2ZlYXR1cmVzID0gYXR0cnNbTEZBQ0Vf Rk9OVF9GRUFUVVJFU19JTkRFWF07CisgICAgICBpZiAoQ09OU1AgKGZvbnRfZmVhdHVyZXMpKQor ICAgICAgICAgIGZvbnRfcHV0X2V4dHJhIChlbnRpdHksIFFDZm9udF9mZWF0dXJlcywgZm9udF9m ZWF0dXJlcyk7CiAgICAgfQogICByZXR1cm4gZW50aXR5OwogfQpkaWZmIC0tZ2l0IGEvc3JjL2hi Zm9udC5jIGIvc3JjL2hiZm9udC5jCmluZGV4IDNkOGRmYjRiMGU2Li45NGI2N2I1NDZlOCAxMDA2 NDQKLS0tIGEvc3JjL2hiZm9udC5jCisrKyBiL3NyYy9oYmZvbnQuYwpAQCAtMjM5LDYgKzIzOSw0 MSBAQCBoYmZvbnRfb3RmX2NhcGFiaWxpdHkgKHN0cnVjdCBmb250ICpmb250KQogCiAvKiBTdXBw b3J0IGZ1bmN0aW9ucyBmb3IgSGFyZkJ1enogc2hhcGVyLiAgKi8KIAorLyogQ29udmVydCBMaXNw IGZvbnQgZmVhdHVyZXMgdG8gSGFyZkJ1enogZmVhdHVyZXMuCisgICBGRUFUVVJFUyBpcyBhIGxp c3Qgb2YgKGZlYXR1cmUgLiB2YWx1ZSkgcGFpcnMuCisgICBSZXR1cm5zIHRoZSBudW1iZXIgb2Yg ZmVhdHVyZXMgY29udmVydGVkLCBmaWxscyBIQkZFQVRVUkVTIGFycmF5LgorICAgQ2FsbGVyIG11 c3QgZW5zdXJlIEhCRkVBVFVSRVMgaGFzIGVub3VnaCBzcGFjZS4gKi8KK3N0YXRpYyBpbnQKK2hi X2ZlYXR1cmVzX2Zyb21fbGlzcCAoTGlzcF9PYmplY3QgZmVhdHVyZXMsIGhiX2ZlYXR1cmVfdCAq aGJmZWF0dXJlcywgaW50IG1heF9mZWF0dXJlcykKK3sKKyAgaW50IGNvdW50ID0gMDsKKworICBm b3IgKExpc3BfT2JqZWN0IHRhaWwgPSBmZWF0dXJlczsgQ09OU1AgKHRhaWwpICYmIGNvdW50IDwg bWF4X2ZlYXR1cmVzOyB0YWlsID0gWENEUiAodGFpbCkpCisgICAgeworICAgICAgTGlzcF9PYmpl Y3QgZmVhdHVyZV9zcGVjID0gWENBUiAodGFpbCk7CisgICAgICBpZiAoQ09OU1AgKGZlYXR1cmVf c3BlYykpCisgICAgICAgIHsKKyAgICAgICAgICBMaXNwX09iamVjdCBmZWF0dXJlX3N5bSA9IFhD QVIgKGZlYXR1cmVfc3BlYyk7CisgICAgICAgICAgTGlzcF9PYmplY3QgZmVhdHVyZV92YWwgPSBY Q0RSIChmZWF0dXJlX3NwZWMpOworCisgICAgICAgICAgaWYgKFNZTUJPTFAgKGZlYXR1cmVfc3lt KSAmJiBGSVhOVU1QIChmZWF0dXJlX3ZhbCkpCisgICAgICAgICAgICB7CisgICAgICAgICAgICAg IC8qIENvbnZlcnQgc3ltYm9sIHRvIEhhcmZCdXp6IHRhZyAqLworICAgICAgICAgICAgICBjb25z dCBjaGFyICpmZWF0dXJlX25hbWUgPSBTU0RBVEEgKFNZTUJPTF9OQU1FIChmZWF0dXJlX3N5bSkp OworICAgICAgICAgICAgICBoYl90YWdfdCB0YWcgPSBoYl90YWdfZnJvbV9zdHJpbmcgKGZlYXR1 cmVfbmFtZSwgLTEpOworCisgICAgICAgICAgICAgIGhiZmVhdHVyZXNbY291bnRdLnRhZyA9IHRh ZzsKKyAgICAgICAgICAgICAgaGJmZWF0dXJlc1tjb3VudF0udmFsdWUgPSBYRklYTlVNIChmZWF0 dXJlX3ZhbCk7CisgICAgICAgICAgICAgIGhiZmVhdHVyZXNbY291bnRdLnN0YXJ0ID0gMDsKKyAg ICAgICAgICAgICAgaGJmZWF0dXJlc1tjb3VudF0uZW5kID0gKHVuc2lnbmVkIGludCkgLTE7Cisg ICAgICAgICAgICAgIGNvdW50Kys7CisgICAgICAgICAgICB9CisgICAgICAgIH0KKyAgICB9CisK KyAgcmV0dXJuIGNvdW50OworfQorCiBzdGF0aWMgYm9vbCBjb21iaW5pbmdfY2xhc3NfbG9hZGVk ID0gZmFsc2U7CiBzdGF0aWMgTGlzcF9PYmplY3QgY2Fub25pY2FsX2NvbWJpbmluZ19jbGFzc190 YWJsZTsKIApAQCAtNDkxLDcgKzUyNiwyMCBAQCBoYmZvbnRfc2hhcGUgKExpc3BfT2JqZWN0IGxn c3RyaW5nLCBMaXNwX09iamVjdCBkaXJlY3Rpb24pCiAgIGlmICghaGJfZm9udCkKICAgICByZXR1 cm4gbWFrZV9maXhudW0gKDApOwogCi0gIGhiX2Jvb2xfdCBzdWNjZXNzID0gaGJfc2hhcGVfZnVs bCAoaGJfZm9udCwgaGJfYnVmZmVyLCBOVUxMLCAwLCBOVUxMKTsKKworICAvKiBHZXQgZm9udCBm ZWF0dXJlcyBmcm9tIHRoZSBmb250IG9iamVjdCAqLworICBMaXNwX09iamVjdCBmb250X2ZlYXR1 cmVzID0gRmZvbnRfZ2V0IChMR1NUUklOR19GT05UIChsZ3N0cmluZyksIFFDZm9udF9mZWF0dXJl cyk7CisgIHN0YXRpYyBoYl9mZWF0dXJlX3QgZmVhdHVyZXNbMzJdOyAgLyogQ2FjaGUgZmVhdHVy ZXMgYXJyYXksIHJlYXNvbmFibGUgbWF4IHNpemUgKi8KKyAgaW50IG51bV9mZWF0dXJlcyA9IDA7 CisKKyAgaWYgKCFOSUxQIChmb250X2ZlYXR1cmVzKSkKKyAgICB7CisgICAgICBudW1fZmVhdHVy ZXMgPSBoYl9mZWF0dXJlc19mcm9tX2xpc3AgKGZvbnRfZmVhdHVyZXMsIGZlYXR1cmVzLCAzMik7 CisgICAgfQorCisgIGhiX2Jvb2xfdCBzdWNjZXNzID0gaGJfc2hhcGVfZnVsbCAoaGJfZm9udCwg aGJfYnVmZmVyLCBmZWF0dXJlcywgbnVtX2ZlYXR1cmVzLCBOVUxMKTsKKworCiAgIGlmIChmb250 LT5kcml2ZXItPmVuZF9oYl9mb250KQogICAgIGZvbnQtPmRyaXZlci0+ZW5kX2hiX2ZvbnQgKGZv bnQsIGhiX2ZvbnQpOwogICBpZiAoIXN1Y2Nlc3MpCmRpZmYgLS1naXQgYS9zcmMveGZhY2VzLmMg Yi9zcmMveGZhY2VzLmMKaW5kZXggNzYyNmRmZWI3NWMuLjg3OTk2OGNkNzczIDEwMDY0NAotLS0g YS9zcmMveGZhY2VzLmMKKysrIGIvc3JjL3hmYWNlcy5jCkBAIC0xODA0LDYgKzE4MDQsNyBAQCAj ZGVmaW5lIExGQUNFX0ZPTlQoTEZBQ0UpCSAgICBBUkVGIChMRkFDRSwgTEZBQ0VfRk9OVF9JTkRF WCkKICNkZWZpbmUgTEZBQ0VfSU5IRVJJVChMRkFDRSkJICAgIEFSRUYgKExGQUNFLCBMRkFDRV9J TkhFUklUX0lOREVYKQogI2RlZmluZSBMRkFDRV9GT05UU0VUKExGQUNFKQkgICAgQVJFRiAoTEZB Q0UsIExGQUNFX0ZPTlRTRVRfSU5ERVgpCiAjZGVmaW5lIExGQUNFX0VYVEVORChMRkFDRSkJICAg IEFSRUYgKExGQUNFLCBMRkFDRV9FWFRFTkRfSU5ERVgpCisjZGVmaW5lIExGQUNFX0ZPTlRfRkVB VFVSRVMoTEZBQ0UpICBBUkVGIChMRkFDRSwgTEZBQ0VfRk9OVF9GRUFUVVJFU19JTkRFWCkKICNk ZWZpbmUgTEZBQ0VfRElTVEFOVF9GT1JFR1JPVU5EKExGQUNFKSBcCiAgIEFSRUYgKExGQUNFLCBM RkFDRV9ESVNUQU5UX0ZPUkVHUk9VTkRfSU5ERVgpCiAKQEAgLTE5MTQsNiArMTkxNSwxMSBAQCBj aGVja19sZmFjZV9hdHRycyAoTGlzcF9PYmplY3QgYXR0cnNbTEZBQ0VfVkVDVE9SX1NJWkVdKQog CSAgIHx8IFNUUklOR1AgKGF0dHJzW0xGQUNFX0ZPTlRTRVRfSU5ERVhdKQogCSAgIHx8IFJFU0VU X1AgKGF0dHJzW0xGQUNFX0ZPTlRTRVRfSU5ERVhdKQogCSAgIHx8IE5JTFAgKGF0dHJzW0xGQUNF X0ZPTlRTRVRfSU5ERVhdKSk7CisgIGVhc3NlcnQgKFVOU1BFQ0lGSUVEUCAoYXR0cnNbTEZBQ0Vf Rk9OVF9GRUFUVVJFU19JTkRFWF0pCisJICAgfHwgSUdOT1JFX0RFRkZBQ0VfUCAoYXR0cnNbTEZB Q0VfRk9OVF9GRUFUVVJFU19JTkRFWF0pCisJICAgfHwgUkVTRVRfUCAoYXR0cnNbTEZBQ0VfRk9O VF9GRUFUVVJFU19JTkRFWF0pCisJICAgfHwgTklMUCAoYXR0cnNbTEZBQ0VfRk9OVF9GRUFUVVJF U19JTkRFWF0pCisJICAgfHwgQ09OU1AgKGF0dHJzW0xGQUNFX0ZPTlRfRkVBVFVSRVNfSU5ERVhd KSk7CiAjZW5kaWYKIH0KIApAQCAtMjE2Miw3ICsyMTY4LDcgQEAgbGZhY2VfZnVsbHlfc3BlY2lm aWVkX3AgKExpc3BfT2JqZWN0IGF0dHJzW0xGQUNFX1ZFQ1RPUl9TSVpFXSkKIAogICBmb3IgKGkg PSAxOyBpIDwgTEZBQ0VfVkVDVE9SX1NJWkU7ICsraSkKICAgICBpZiAoaSAhPSBMRkFDRV9GT05U X0lOREVYICYmIGkgIT0gTEZBQ0VfSU5IRVJJVF9JTkRFWAotICAgICAgICAmJiBpICE9IExGQUNF X0RJU1RBTlRfRk9SRUdST1VORF9JTkRFWCkKKyAgICAgICAgJiYgaSAhPSBMRkFDRV9ESVNUQU5U X0ZPUkVHUk9VTkRfSU5ERVggJiYgaSAhPSBMRkFDRV9GT05UX0ZFQVRVUkVTX0lOREVYKQogICAg ICAgaWYgKChVTlNQRUNJRklFRFAgKGF0dHJzW2ldKSB8fCBJR05PUkVfREVGRkFDRV9QIChhdHRy c1tpXSkpKQogCWJyZWFrOwogCkBAIC0yOTE3LDYgKzI5MjMsMTMgQEAgbWVyZ2VfZmFjZV9yZWYg KHN0cnVjdCB3aW5kb3cgKncsCiAJCSAgZWxzZQogCQkgICAgZXJyID0gdHJ1ZTsKIAkJfQorCSAg ICAgIGVsc2UgaWYgKEVRIChrZXl3b3JkLCBRQ2ZvbnRfZmVhdHVyZXMpKQorCQl7CisJCSAgaWYg KE5JTFAgKHZhbHVlKSB8fCBDT05TUCAodmFsdWUpKQorCQkgICAgdG9bTEZBQ0VfRk9OVF9GRUFU VVJFU19JTkRFWF0gPSB2YWx1ZTsKKwkJICBlbHNlCisJCSAgICBlcnIgPSB0cnVlOworCQl9CiAJ ICAgICAgZWxzZQogCQllcnIgPSB0cnVlOwogCkBAIC0zNjQ1LDYgKzM2NTgsMzIgQEAgREVGVU4g KCJpbnRlcm5hbC1zZXQtbGlzcC1mYWNlLWF0dHJpYnV0ZSIsIEZpbnRlcm5hbF9zZXRfbGlzcF9m YWNlX2F0dHJpYnV0ZSwKIAl9CiAjZW5kaWYgLyogSEFWRV9XSU5ET1dfU1lTVEVNICovCiAgICAg fQorICBlbHNlIGlmIChFUSAoYXR0ciwgUUNmb250X2ZlYXR1cmVzKSkKKyAgICB7CisgICAgICBp ZiAoIVVOU1BFQ0lGSUVEUCAodmFsdWUpCisJICAmJiAhSUdOT1JFX0RFRkZBQ0VfUCAodmFsdWUp CisJICAmJiAhUkVTRVRfUCAodmFsdWUpKQorCXsKKwkgIC8qIFZhbGlkYXRlIGZvbnQgZmVhdHVy ZXMgbGlzdCBmb3JtYXQ6CisJICAgICBTaG91bGQgYmUgYSBsaXN0IG9mIChmZWF0dXJlIC4gdmFs dWUpIHBhaXJzICovCisJICBpZiAoIU5JTFAgKHZhbHVlKSkKKwkgICAgeworCSAgICAgIExpc3Bf T2JqZWN0IHRhaWw7CisJICAgICAgZm9yICh0YWlsID0gdmFsdWU7IENPTlNQICh0YWlsKTsgdGFp bCA9IFhDRFIgKHRhaWwpKQorCQl7CisJCSAgTGlzcF9PYmplY3QgZmVhdHVyZV9zcGVjID0gWENB UiAodGFpbCk7CisJCSAgaWYgKCFDT05TUCAoZmVhdHVyZV9zcGVjKQorCQkgICAgICB8fCAhU1lN Qk9MUCAoWENBUiAoZmVhdHVyZV9zcGVjKSkKKwkJICAgICAgfHwgIUZJWE5VTVAgKFhDRFIgKGZl YXR1cmVfc3BlYykpKQorCQkgICAgc2lnbmFsX2Vycm9yICgiSW52YWxpZCBmb250IGZlYXR1cmVz IGZvcm1hdCIsIHZhbHVlKTsKKwkJfQorCSAgICAgIGlmICghTklMUCAodGFpbCkpCisJCXNpZ25h bF9lcnJvciAoIkludmFsaWQgZm9udCBmZWF0dXJlcyBmb3JtYXQiLCB2YWx1ZSk7CisJICAgIH0K Kwl9CisgICAgICBvbGRfdmFsdWUgPSBMRkFDRV9GT05UX0ZFQVRVUkVTIChsZmFjZSk7CisgICAg ICBBU0VUIChsZmFjZSwgTEZBQ0VfRk9OVF9GRUFUVVJFU19JTkRFWCwgdmFsdWUpOworICAgIH0K ICAgZWxzZSBpZiAoRVEgKGF0dHIsIFFDaW5oZXJpdCkpCiAgICAgewogICAgICAgTGlzcF9PYmpl Y3QgdGFpbDsKQEAgLTQyMTMsNiArNDI1Miw4IEBAIERFRlVOICgiaW50ZXJuYWwtZ2V0LWxpc3At ZmFjZS1hdHRyaWJ1dGUiLCBGaW50ZXJuYWxfZ2V0X2xpc3BfZmFjZV9hdHRyaWJ1dGUsCiAgICAg dmFsdWUgPSBMRkFDRV9GT05UIChsZmFjZSk7CiAgIGVsc2UgaWYgKEVRIChrZXl3b3JkLCBRQ2Zv bnRzZXQpKQogICAgIHZhbHVlID0gTEZBQ0VfRk9OVFNFVCAobGZhY2UpOworICBlbHNlIGlmIChF USAoa2V5d29yZCwgUUNmb250X2ZlYXR1cmVzKSkKKyAgICB2YWx1ZSA9IExGQUNFX0ZPTlRfRkVB VFVSRVMgKGxmYWNlKTsKICAgZWxzZQogICAgIHNpZ25hbF9lcnJvciAoIkludmFsaWQgZmFjZSBh dHRyaWJ1dGUgbmFtZSIsIGtleXdvcmQpOwogCkBAIC00NTM5LDcgKzQ1ODAsNyBAQCBsZmFjZV9o YXNoIChMaXNwX09iamVjdCAqdikKIAkgIF4gWEhBU0ggKHZbTEZBQ0VfV0VJR0hUX0lOREVYXSkK IAkgIF4gWEhBU0ggKHZbTEZBQ0VfU0xBTlRfSU5ERVhdKQogCSAgXiBYSEFTSCAodltMRkFDRV9T V0lEVEhfSU5ERVhdKQotCSAgXiBYSEFTSCAodltMRkFDRV9IRUlHSFRfSU5ERVhdKSk7CisJICBe IFhIQVNIICh2W0xGQUNFX0ZPTlRfRkVBVFVSRVNfSU5ERVhdKSk7CiB9CiAKICNpZmRlZiBIQVZF X1dJTkRPV19TWVNURU0KQEAgLTQ1NjMsNiArNDYwNCw3IEBAIGxmYWNlX3NhbWVfZm9udF9hdHRy aWJ1dGVzX3AgKExpc3BfT2JqZWN0ICpsZmFjZTEsIExpc3BfT2JqZWN0ICpsZmFjZTIpCiAJICAm JiBFUSAobGZhY2UxW0xGQUNFX1dFSUdIVF9JTkRFWF0sIGxmYWNlMltMRkFDRV9XRUlHSFRfSU5E RVhdKQogCSAgJiYgRVEgKGxmYWNlMVtMRkFDRV9TTEFOVF9JTkRFWF0sIGxmYWNlMltMRkFDRV9T TEFOVF9JTkRFWF0pCiAJICAmJiBFUSAobGZhY2UxW0xGQUNFX0ZPTlRfSU5ERVhdLCBsZmFjZTJb TEZBQ0VfRk9OVF9JTkRFWF0pCisJICAmJiBFUSAobGZhY2UxW0xGQUNFX0ZPTlRfRkVBVFVSRVNf SU5ERVhdLCBsZmFjZTJbTEZBQ0VfRk9OVF9GRUFUVVJFU19JTkRFWF0pCiAJICAmJiAoRVEgKGxm YWNlMVtMRkFDRV9GT05UU0VUX0lOREVYXSwgbGZhY2UyW0xGQUNFX0ZPTlRTRVRfSU5ERVhdKQog CSAgICAgIHx8IChTVFJJTkdQIChsZmFjZTFbTEZBQ0VfRk9OVFNFVF9JTkRFWF0pCiAJCSAgJiYg U1RSSU5HUCAobGZhY2UyW0xGQUNFX0ZPTlRTRVRfSU5ERVhdKQpAQCAtNzM2Niw2ICs3NDA4LDcg QEAgaW5pdF94ZmFjZXMgKHZvaWQpCiAgIGZhY2VfYXR0cl9zeW1bTEZBQ0VfRk9OVFNFVF9JTkRF WF0gPSBRQ2ZvbnRzZXQ7CiAgIGZhY2VfYXR0cl9zeW1bTEZBQ0VfRElTVEFOVF9GT1JFR1JPVU5E X0lOREVYXSA9IFFDZGlzdGFudF9mb3JlZ3JvdW5kOwogICBmYWNlX2F0dHJfc3ltW0xGQUNFX0VY VEVORF9JTkRFWF0gPSBRQ2V4dGVuZDsKKyAgZmFjZV9hdHRyX3N5bVtMRkFDRV9GT05UX0ZFQVRV UkVTX0lOREVYXSA9IFFDZm9udF9mZWF0dXJlczsKIH0KIAogdm9pZApAQCAtNzM5Nyw2ICs3NDQw LDcgQEAgc3ltc19vZl94ZmFjZXMgKHZvaWQpCiAgIERFRlNZTSAoUUN3aWR0aCwgIjp3aWR0aCIp OwogICBERUZTWU0gKFFDZm9udCwgIjpmb250Iik7CiAgIERFRlNZTSAoUUNmb250c2V0LCAiOmZv bnRzZXQiKTsKKyAgREVGU1lNIChRQ2ZvbnRfZmVhdHVyZXMsICI6Zm9udC1mZWF0dXJlcyIpOwog ICBERUZTWU0gKFFDZGlzdGFudF9mb3JlZ3JvdW5kLCAiOmRpc3RhbnQtZm9yZWdyb3VuZCIpOwog ICBERUZTWU0gKFFDYm9sZCwgIjpib2xkIik7CiAgIERFRlNZTSAoUUNpdGFsaWMsICI6aXRhbGlj Iik7Ci0tIAoyLjQ3LjIKCg== --000000000000594a7b063ce0e9d1-- From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 23 08:51:29 2025 Received: (at 79285) by debbugs.gnu.org; 23 Aug 2025 12:51:29 +0000 Received: from localhost ([127.0.0.1]:39034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1upniS-0006Ax-Pc for submit@debbugs.gnu.org; Sat, 23 Aug 2025 08:51:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35576) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1upniO-0006Ab-8M for 79285@debbugs.gnu.org; Sat, 23 Aug 2025 08:51:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1upniI-0003Nw-Lw; Sat, 23 Aug 2025 08:51:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=n5cf3h4uyZtosi32lvBaQKCyGTGq45HHTKhNauzlFCU=; b=h0WRzfzMDlE5 jIigdF85L1ofQYzoRrWAFRpRChkWSmWJeYo6uJTdsbFHFpTE4q6XdGLkTOZN1CKV6qAuEicZanH8L QzSAuc2zM5sgMVvvF23erprVnsua+xIas4upTi9Bv/fc4bhtRVj+69m3gNFiYH3+K5odQLqHOX3F8 g7fSM3ZqHeJjMcW+Ag7HWlYP8FvXsD1y+Zksccc45QG5EPNp/wjNAWVfa2lXFRfPbNNwUc4pLRc/Y KcZfc+PnY6sDFohlSYEA77VZs5t1yZzJkp3kv9kVILGq2Sx8aElVbGWVdksEMmtQT/ECVMiWl12Fb 6IoGtPOg6AJLyonPDEhEnA==; Date: Sat, 23 Aug 2025 15:51:16 +0300 Message-Id: <861pp2b3qz.fsf@gnu.org> From: Eli Zaretskii To: Binbin YE In-Reply-To: (message from Binbin YE on Thu, 21 Aug 2025 23:28:53 +0900) Subject: Re: bug#79285: [Patch] support :font-features in face References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Binbin YE > Date: Thu, 21 Aug 2025 23:28:53 +0900 > > It is my first time trying to contribute to Emacs source code. > > The change is adding support for enabling stylistic set (font features) when using harfbuzz font backend. It is > a commonly supported feature in the editors. See following links > > https://code.visualstudio.com/docs/terminal/appearance#_font-feature-settings > > https://developer.mozilla.org/en-US/docs/Web/CSS/font-feature-settings > > The change adds :font-feature configuration like following > > (set-face-attribute 'default nil :font "JetBrains Mono" :height 80 > :font-features '((zero . 1) (ss19 . 0) (calt . 1))) > > The render result can be confirmed by adding "0" to composition table > > (set-char-table-range composition-function-table > ?0 > '(["." 0 font-shape-gstring])) Thanks, this is an important feature to have in Emacs. If implemented as a face property, as you have done in your patch, we should also modify the face-merging code to be able to merge two lists of features int a single list that includes all of the features, right? This is what should happen when two faces with non-nil :font-features attribute are merged. > I have read the CONTRIBUTE file and tried to make the commit message as clear as possible. Please let me > know the code review process to get the patch accepted. See a few comments below. In addition, this will need s NEWS item and a suitable addition to the ELisp manual, where the face attributes are described. Last, but not least, to accept a contribution of this size, we will need you to sign a copyright-assignment agreement with the FSF. If you are prepared to do that, I will send you the form to fill and the instructions to go with it. > + /* Store font features from face attributes for use during shaping */ ^^ Our style is to end the commend with a period and two spaces, before "*/". > + if (CONSP (font_features)) > + font_put_extra (entity, QCfont_features, font_features); ^^^^ We use indentation offset of 2 columns in C sources. > +/* Convert Lisp font features to HarfBuzz features. > + FEATURES is a list of (feature . value) pairs. > + Returns the number of features converted, fills HBFEATURES array. > + Caller must ensure HBFEATURES has enough space. */ ^^ Two spaces there. About "enough space" -- how many features could a font have? And what to do if it has more than 32? GNU coding conventions frown on arbitrary limits, and 32 sounds like it's quite arbitrary. Can we do better? > + Lisp_Object feature_sym = XCAR (feature_spec); > + Lisp_Object feature_val = XCDR (feature_spec); > + > + if (SYMBOLP (feature_sym) && FIXNUMP (feature_val)) Are we sure the value cannot be larger than most-positive-fixnum? Emacs can handle larger values if needed. > @@ -491,7 +526,20 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction) > if (!hb_font) > return make_fixnum (0); > > - hb_bool_t success = hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL); > + > + /* Get font features from the font object */ > + Lisp_Object font_features = Ffont_get (LGSTRING_FONT (lgstring), QCfont_features); > + static hb_feature_t features[32]; /* Cache features array, reasonable max size */ > + int num_features = 0; > + > + if (!NILP (font_features)) > + { > + num_features = hb_features_from_lisp (font_features, features, 32); > + } > + > + hb_bool_t success = hb_shape_full (hb_font, hb_buffer, features, num_features, NULL); I think it is safer to pass NULL instead of 'features' if we know there are no features. Also, our style is not to use braces when the block has only one statement. > @@ -2917,6 +2923,13 @@ merge_face_ref (struct window *w, > else > err = true; > } > + else if (EQ (keyword, QCfont_features)) > + { > + if (NILP (value) || CONSP (value)) > + to[LFACE_FONT_FEATURES_INDEX] = value; > + else > + err = true; > + } As mentioned above, I think we should be smarter here: instead of overwriting the value of :font-features of the target face, we should merge the two lists so that it includes the features from both faces. Font features from FROM should override the same features from TO, but font features which exist in TO but not in FROM should be left in the resulting list. Thanks again for working on this, and for your interest in Emacs. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 23 20:17:31 2025 Received: (at 79285) by debbugs.gnu.org; 24 Aug 2025 00:17:31 +0000 Received: from localhost ([127.0.0.1]:42231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1upyQM-00086C-IM for submit@debbugs.gnu.org; Sat, 23 Aug 2025 20:17:30 -0400 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:49421) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1upyQK-00085y-Rk for 79285@debbugs.gnu.org; Sat, 23 Aug 2025 20:17:29 -0400 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-45a1b0d224dso16609495e9.3 for <79285@debbugs.gnu.org>; Sat, 23 Aug 2025 17:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755994642; x=1756599442; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RoT/cgnwtq0smV+fO2YpXmT4acjIZrXKWAolj+KHjFs=; b=PHmcwPmUxz9EphHWlbUfwAiWM8MHG6YJVDXM/jnQ7zWnsmAC6kT5aGwY+hdZnsFe5Z ZqpKuSMoQxglOAUUboenAyN5Y5QvnTgFpxUxAHrKRQkgqwWEGpth3jxC4tXw+WvysU4b 4e2wgeIRJkLvE5h/f3O03icS+Yn0Cvq48hIZ1mz5NXziXvDq07M8WUfi1zeHzjpPNdXX ugmNiczxMM0DXRqwzoTdGHoZ9vvLBOE9kcxND09UtmDDe/siPisLmVqes/5Sh//Jwe5F N4ruxBtOQbg2XGMer/Ci6dhtnrJEOgv2ahLk8/5ui+MYoXCcyknaFYTLJ9jYBJ2nr3+B yWEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755994642; x=1756599442; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RoT/cgnwtq0smV+fO2YpXmT4acjIZrXKWAolj+KHjFs=; b=ogMZ/F1VrjB0W9gpUoX3XKAMGaiDiea/CluFiaziwWrJwgA7/LxbvBRtAseJnJzd8K cyIc/uxCpksbLR3BwMvSha7Af0M46R0hWmIcgGv7ZBIp/OiN9RTfwnqAWlya3vX68Lma HmAkcAPyTd70h4VkjZmLRH23jen8vmR4Qb7YO7GveuCOfrTqxkq4hzlk8CDSiSEs5tA/ XYRCZy/3qeovdEQj0TkA/n5E8rRQEe3281rFNri5VhsiGlPOXJTKyPMGz8rjfltAtTXb EmYWKVCV0VWP4EH7edWWOqnEnaoTLOnZmRN7dnlNGH+ZVrn27F4HRdFQESsvbd8snADK AWKA== X-Gm-Message-State: AOJu0YybAyjRiEnSNC/KUO1l5x3e8d1Afw8UNbhbcnBWYPJdfKM1fhTK 4Fs2CKAuivpIdK8jXIXOJHHnxkBIriDaAx/CeXPkdee0XjXwhs1aizi8x23GSL5yTk9RphjHJrd +W3bRgbnIA0/Kj0GjlOQvJflC79MqCjs= X-Gm-Gg: ASbGncvMeVGqvV8ikSoffAiP0BM/TOJUG1NLNuqIGSBbHvEgvi8TLKu0hyIHIrlsQdy N06tLzfH+foPy0vUyPyl/yAMKcoyUEEbCJdJ8mYVtVULt11eibAb15AUWyrLrZPAKfvJ9/gY0dq D0K68uQ75tbo0QpHFGlZb89n3DP4G9kf4hDwEwxhik+2i9/d87PxwT1ympeOR+xcjqLCHd2FCpM NoT1/jM/WAoI7ekMnrKY0gqpL1q9GUC5usDYjNL/xDurfvXM62pKR/aLA== X-Google-Smtp-Source: AGHT+IGv2b3F3ZPo6MJRPW1LlvoS4LJOftmmazzBLE78bSpam2zaJ9OOHPxyH3oPx5RqLNrPReDC9sFtVoKq074fujk= X-Received: by 2002:a05:600c:1c11:b0:456:161c:3d6f with SMTP id 5b1f17b1804b1-45b51796376mr57680035e9.11.1755994641783; Sat, 23 Aug 2025 17:17:21 -0700 (PDT) MIME-Version: 1.0 References: <861pp2b3qz.fsf@gnu.org> In-Reply-To: <861pp2b3qz.fsf@gnu.org> From: Binbin YE Date: Sun, 24 Aug 2025 09:17:10 +0900 X-Gm-Features: Ac12FXxmiB1Oup6duB5JyWLIVN42wkv6tBKJDz0-V4BVxFProCBDe3xsZ4lChYg Message-ID: Subject: Re: bug#79285: [Patch] support :font-features in face To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000d9e0ed063d115c59" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000d9e0ed063d115c59 Content-Type: text/plain; charset="UTF-8" Hi Eli, Thank you for the review of the patch. I'll update the changes in short, together with NEWS and the ELisp manual. > Last, but not least, to accept a contribution of this size, we will > need you to sign a copyright-assignment agreement with the FSF. If > you are prepared to do that, I will send you the form to fill and the > instructions to go with it. I am aware of the existence of the agreement, and I am ready to sign it. While I'm working on the patch, we can proceed the paperwork in parallel Best, Binbin --000000000000d9e0ed063d115c59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eli,

Thank you for the review of the patch. I= 9;ll update the changes in short, together with NEWS and the ELisp manual.<= br>
> Last, but not least, to accept a contribution of this size, we = will
> need you to sign a copyright-assignment agreement with the FSF= .=C2=A0 If
> you are prepared to do that, I will send you the form to= fill and the
> instructions to go with it.

I am aware of the = existence of the agreement, and I am ready to sign it. While I'm workin= g on the patch, we can proceed the paperwork in parallel

Best,
Binbin
--000000000000d9e0ed063d115c59-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 24 01:53:17 2025 Received: (at 79285) by debbugs.gnu.org; 24 Aug 2025 05:53:17 +0000 Received: from localhost ([127.0.0.1]:43020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uq3fJ-0002Dg-7u for submit@debbugs.gnu.org; Sun, 24 Aug 2025 01:53:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47880) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uq3fH-0002DU-7q for 79285@debbugs.gnu.org; Sun, 24 Aug 2025 01:53:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uq3fB-000438-LD; Sun, 24 Aug 2025 01:53:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=42xlINnAqgpwhc8/gpQVqCm2pzbWr4kXW+Cet+jIXxw=; b=XQZqRO9bxLeN HWjYuOSP+PYEqypffLU+V6oSeI80TBySIVHgWVZE17v6zh3lIp802p4iRuo2DSU9rQkfCjDpiKidE G4/4L3Bgn4SsD71LZ62wJdj9eGP1ZHRdhsG9mifjKkZsCqxSUMXK86cYZA7esQ9PfN5TU1oh2LXKR wIwV5NtszSVQ/okwOaLYRBDiLQkgyrbitNOJYtvfWBw/WBAjGyvJwUIkwq4ramu/KKGgW5AZorT33 bLvmRy+dBYzFs8upZd1M/7BnTHC+rvpja5UPrpnvB5sg5+mgp7V1Lwt3jh6yeymdIrsLRc+8Q/h8A ouiQYDaqmv/+D48KuI7Kpg==; Date: Sun, 24 Aug 2025 08:53:06 +0300 Message-Id: <86frdh8dvh.fsf@gnu.org> From: Eli Zaretskii To: Binbin YE In-Reply-To: (message from Binbin YE on Sun, 24 Aug 2025 09:17:10 +0900) Subject: Re: bug#79285: [Patch] support :font-features in face References: <861pp2b3qz.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Binbin YE > Date: Sun, 24 Aug 2025 09:17:10 +0900 > Cc: 79285@debbugs.gnu.org > > Thank you for the review of the patch. I'll update the changes in short, together with NEWS and the ELisp > manual. Thanks. > > Last, but not least, to accept a contribution of this size, we will > > need you to sign a copyright-assignment agreement with the FSF. If > > you are prepared to do that, I will send you the form to fill and the > > instructions to go with it. > > I am aware of the existence of the agreement, and I am ready to sign it. While I'm working on the patch, we > can proceed the paperwork in parallel Form sent off-list. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 21:37:07 2025 Received: (at 79285) by debbugs.gnu.org; 28 Aug 2025 01:37:07 +0000 Received: from localhost ([127.0.0.1]:37546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1urRZa-0000aW-3E for submit@debbugs.gnu.org; Wed, 27 Aug 2025 21:37:07 -0400 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:47310) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1urRZX-0000Z8-6C for 79285@debbugs.gnu.org; Wed, 27 Aug 2025 21:37:03 -0400 Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-3c84925055aso308105f8f.2 for <79285@debbugs.gnu.org>; Wed, 27 Aug 2025 18:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756345017; x=1756949817; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iQuoL/OshslHSzpYKKinErhw+2/HPYj3IGFjpNWiiyU=; b=Sk4le60d17+hxJfELWQ/10WCBSpoDeSonh6ZU0zslKVoyz582zKWEyFzNPdIeGzdJe Wcpv3gbFeNmnZG4C6Tb9Xilips8TP1g3gqp3Oqx8ErpCNco/fEE9gK95hZ5tnTur8OlW 2trkuafxlqbJZt19FPnCv4X7F/OApUq6agw0IPSb9pKkjzApq+P//qmA0snn/MnJVZfG SCGgCcEPke+1UYk3IFzxtnMXxSe/KNRTS8nzlLwyiTx7E4x9kN/9Vbb5UJ+EJOUr9k36 HJ8l7CkA4HTpOTlxrouMvPiss+ics7Du3v6r0nBchG48ue0ClLzAJDNCU9IvVCjrfCxV dcxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756345017; x=1756949817; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iQuoL/OshslHSzpYKKinErhw+2/HPYj3IGFjpNWiiyU=; b=Gn1w3EgHlLaJv0FDaZskGFm0rr9KegSw28UyYLlDiPqj1xIH3zst4yhC4uUQBt121o TB36R17J8PfLQuxudQQvcIBKh7brdGUgGbpojuDmPUh1JQDpS5WKHNYtANfHHzTnsBtj 0Rt0vyvVxfBEg4Orx1/d5AqiaE3E7foytjTvjwfmZyoGHfqgOOZ9hNjpjJZGjYAyJ4ya qUnUdW1cElDMZNcz3JuRBDmMDMjtjucOLzf7v/zWl05hU+1tvrQ3ZSDO6ywkF8SMB2tW 0qVu1OdCXHGWilxTB6zOKgsABlfDzzXC0bFwvEP23hRCodl1SsgZA69KWNPM93v2OLs7 HnpA== X-Gm-Message-State: AOJu0YzyByfqBRs2T2mRRI0UUtZFVL2ESnD1TB7rVISNN9WFk3hpaVyK qO5fe/PiUwl7PpjSDBkF4il7zgwlLNwUpzUUSJynFv+Ut+aFKK5hZZSZybC83JSRYny1zfyG6IR Zk6r+yONg63Bpd63SIFirzPLxvz3ly7TDTm8v X-Gm-Gg: ASbGnctJvK2/gAB0XW2dfQL+jMtUhjPlLDDlMqObK4fYN1OWBO92LBRLxxO3/jXotqs n2H5Yd5no+YP+rCn44Q56M5QjOX9uxyu3e6N0ilcX+tMq4cL5zbaFsTbVTf52qt0sY8G7M8lmxU IvOccj1WO8D4zRuUErBOcEthwFqUC95gbB8WxdSpRqNZd70Rwizrdf69CtNzrKpuZaRecMtiY1Z Pabz+ctC2t/nSJHITY= X-Google-Smtp-Source: AGHT+IEBuLLjEEb5ckww8nvE4Xiwz4EPcry1+f5MX+ZM+9xJUlUoUKegz0aE95kNkS611/JT8wGTt6geyKWf0+5xZL0= X-Received: by 2002:a05:6000:240c:b0:3c9:9ec0:203b with SMTP id ffacd0b85a97d-3c99ec02f4bmr10158179f8f.27.1756345016417; Wed, 27 Aug 2025 18:36:56 -0700 (PDT) MIME-Version: 1.0 References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> In-Reply-To: <86frdh8dvh.fsf@gnu.org> From: Binbin YE Date: Thu, 28 Aug 2025 10:36:45 +0900 X-Gm-Features: Ac12FXxk7jbPaAoyH3Npnsd7LVDt1Q1ou2W9p4yfMjD8epnpinyo7orwSi5TC5M Message-ID: Subject: Re: bug#79285: [Patch] support :font-features in face To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000ce808d063d62f0c2" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000ce808d063d62f0c2 Content-Type: text/plain; charset="UTF-8" Hi Eli, I found I needed extra handling to support alist merging for the font features, which took a bit longer than expected. I am currently wrapping up the code before sending the updated patch. Can you help me understand what indentation guidelines are? > > + if (CONSP (font_features)) > > + font_put_extra (entity, QCfont_features, font_features); ^^^^ > We use indentation offset of 2 columns in C sources. I tried clang-format with .clang-format configuration in the repository and it produces indents mixed with tab and space. Like And I spotted the existing code base in xfaces.c sometimes uses all spaces and sometimes uses mixture of tab and space for indentation. Is it OK to treat 1 indent level = 2 spaces? --000000000000ce808d063d62f0c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Eli,

I found I needed extr= a handling to support alist=C2=A0merging for the font features, which took = a bit longer than expected.

I am = currently wrapping up the code before sending the updated patch. Can you he= lp me understand what indentation guidelines are?

= > > +=C2=A0 =C2=A0 =C2=A0 if (CONSP (font_features))
> > += =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 font_put_extra (entity, QCfont_features,= font_features);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^
> We use i= ndentation offset of 2 columns in C sources.

I tri= ed clang-format with .clang-format configuration in the repository and it p= roduces indents mixed with tab and space. Like <tab><space><= space>

And I spotted the existing code base in = xfaces.c sometimes uses all spaces and sometimes uses mixture=C2=A0of tab a= nd space for indentation.

Is it OK to treat 1 inde= nt level =3D 2 spaces?
--000000000000ce808d063d62f0c2-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 28 02:05:11 2025 Received: (at 79285) by debbugs.gnu.org; 28 Aug 2025 06:05:11 +0000 Received: from localhost ([127.0.0.1]:38004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1urVkz-0006Dr-Qi for submit@debbugs.gnu.org; Thu, 28 Aug 2025 02:05:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45596) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1urVkx-0006AB-0d for 79285@debbugs.gnu.org; Thu, 28 Aug 2025 02:05:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1urVkr-0001kY-Ki; Thu, 28 Aug 2025 02:05:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WKr5m68JgJLLQmWtWNfsIsbgcy2v0q1DjnR9hmLxeO0=; b=gn3u53x5PWEC k++bJRm3pxIyIet8IdUJM7CIOV7fhq+WStceNp7S84tw8/vftQo12UEMOXi0O5JvjfEDgnm/D1HVv DOGewyf1jGHUVgbJrKSVd0WKyICSAJOQJdMyTJsWWKmhtd2gWneBN5hD8gs/s9Jc/G0vSuGZbNKOI 1X7ibBS/vy1HZQC7OXHQOHxrRGk3X1pqH0jdijfInSNcSZgzrc675EMg62h8SVzEadwkgZewyqnj2 1g74+GTSm+adyhuCz8MqbBDsZowsqbIY4JEOMTxYOidZLGNFwbE6SoAXP8S+bPS+YErrRcxVX8G2f me19gvtcGWXwhcUMiYxCdA==; Date: Thu, 28 Aug 2025 09:04:59 +0300 Message-Id: <86y0r4rng4.fsf@gnu.org> From: Eli Zaretskii To: Binbin YE In-Reply-To: (message from Binbin YE on Thu, 28 Aug 2025 10:36:45 +0900) Subject: Re: bug#79285: [Patch] support :font-features in face References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Binbin YE > Date: Thu, 28 Aug 2025 10:36:45 +0900 > Cc: 79285@debbugs.gnu.org > > I found I needed extra handling to support alist merging for the font features, which took a bit longer than > expected. Thanks, and take your time. There's no rush. > I am currently wrapping up the code before sending the updated patch. Can you help me understand what > indentation guidelines are? Sure. > > > + if (CONSP (font_features)) > > > + font_put_extra (entity, QCfont_features, font_features); > ^^^^ > > We use indentation offset of 2 columns in C sources. > > I tried clang-format with .clang-format configuration in the repository and it produces indents mixed with tab > and space. Like We use mixed TABs+SPCes for indentation, so this is okay. > And I spotted the existing code base in xfaces.c sometimes uses all spaces and sometimes uses mixture of > tab and space for indentation. That is in general a mistake, it should use TABs where possible. But we don't make whitespace-only changes, we only fix these issues as part of a larger changeset that touches the relevant places in the code. So sometimes such mistakes are left alone for some time. > Is it OK to treat 1 indent level = 2 spaces? Yes. If you edit with Emacs, then the .dir-locals.el file in our repository should set up the indentation for you, and then marking the region and typing C-M-\ will reindent the region according to our rules. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 30 22:43:12 2025 Received: (at 79285) by debbugs.gnu.org; 31 Aug 2025 02:43:12 +0000 Received: from localhost ([127.0.0.1]:50913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1usY2A-0001Vu-QH for submit@debbugs.gnu.org; Sat, 30 Aug 2025 22:43:12 -0400 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:43079) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1usY27-0001VH-Sl for 79285@debbugs.gnu.org; Sat, 30 Aug 2025 22:43:09 -0400 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3ceb830dd58so1490375f8f.0 for <79285@debbugs.gnu.org>; Sat, 30 Aug 2025 19:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756608181; x=1757212981; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2vM7l7Wd7RKy8MsmVzcXWrUn4PsPFA7TXt0nhT1Q6eY=; b=JN9dggzy4AHR0L+nn9OAnqNIB878MrySryUUTQ7XDsDzrqTmNJf+nTq2JYDSfo8UdF j1Gz3PTxQ86QrcL+TnEGbMNhoyVrS2CwnHKzOi0taKi6RDf4X+7UM1/qE5IDmfx9wAXb Ju8Z4TLqJt0Ch4tVMsBkp6PUEOU5Ary/kSdR3Ul3XmktaF5u0o72dsozd0fejCTVzEAv BmBt9i9AEZUK61ZxMJF8fDMgSDBVYA9lVtDaOVNryUXISYog+icR/Fl4BZJdFnIQgaZA kasNnteHGucEw5nYoDC2niztz42/g10/XuHdHPwPUdqT6TuIhTQyBRZ8BxPLO+buLZsw zZpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756608181; x=1757212981; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2vM7l7Wd7RKy8MsmVzcXWrUn4PsPFA7TXt0nhT1Q6eY=; b=peXelcKTol8GGnExsB0qOduSsH6WJ2vFnW9pJTRqdtHnWIHgtGQd/VfzxemGJAwP9E Hcs+TAtqYzjERYFwdvukpTi2AT+xJ7+eM/5QN4cDAcLN3uErKyFNDtMBwZEEwRYuxogM mjN0WH7svfEOjiYmmy/6a5HU2ezPZ3uQ3kcpn6WOTJ6sUuKCnRxdsXeJ4hWC42WmGSLl G26rUmMFP5mpeASaU3KlyBe6SbIDXG340vJ+SV3T2HyA+XM0wOuSwStJfOwIPY3shblZ peFCzQbOaxCFVSt6Pm8Fv8KK/n76jod8P4QFUa55z2FSpZFsW4I7ZUcthWWegzq79mBo pAUg== X-Gm-Message-State: AOJu0Yy44Mhjw5kspQz1FeMzcdyCLVRi4nNZDLcyutzC31LCrnS0YP8S askSwBYKvlBdNNdyICSkFzHxx9IHaELQejsSwRrYsxQScr3jiNe3LrfzucgT7NiOeeCWfRjyelq eq0RRU+gxUp5m9a/sgDYsW8IaFrVMeek= X-Gm-Gg: ASbGnctujyboFFnqXPrtyYiuQfhemsp6doSqLsW6oLAOtXmMTLoL4ZflyaefYNC80/d 7kJOJooU0INksfIkWTfpdY3G4dQBrhQT12M4/PpHInKZvYEWq30EtqMf4yk6lhARWZ3RSWr2BXN 2FHPNJ7xG+UBMQvtEe5EkSQlugNXlVMui2pL65w00s/9rr9bEMbTDRsIwfGkDOzXfFVgWeLEj37 ssQi9/P0fIW8IZmzAhjm7BA6LuSL35V81Lsfu0bGNQJwg== X-Google-Smtp-Source: AGHT+IF92xtYarGxn2kaAlaw0iBiyp4tchx+OI0dCdON5spKtXFFvPgaokdaSNktnlcApiETfpMNw4/4P2J4Vu+J19A= X-Received: by 2002:a5d:5f4c:0:b0:3c6:e655:e878 with SMTP id ffacd0b85a97d-3d1dfb0f809mr2407248f8f.31.1756608181379; Sat, 30 Aug 2025 19:43:01 -0700 (PDT) MIME-Version: 1.0 References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> In-Reply-To: <86y0r4rng4.fsf@gnu.org> From: Binbin YE Date: Sun, 31 Aug 2025 11:42:50 +0900 X-Gm-Features: Ac12FXzfQ_Sn79iPGPxuhkQ73vfWgK0uI4FobsCiH7Rrq1j8aW0a1lMB0MOFdRg Message-ID: Subject: Re: bug#79285: [Patch] support :font-features in face To: Eli Zaretskii Content-Type: multipart/mixed; boundary="000000000000a96bf4063da036d6" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000a96bf4063da036d6 Content-Type: multipart/alternative; boundary="000000000000a96bf3063da036d4" --000000000000a96bf3063da036d4 Content-Type: text/plain; charset="UTF-8" Hi Eli, Thanks for the review and explanation, I addressed the issues you brought up and it should be ready for the next round. > If you edit with Emacs, then the .dir-locals.el file in our repository > should set up the indentation for you, and then marking the region and > typing C-M-\ will reindent the region according to our rules. Somehow my Emacs does not respect the .dir-locals.el file, but I used clang-format to format the changed lines > Also, our style is not to use braces when the block has only one > statement. I have to say I had a hard time with this :P I should have removed the braces from the one statement blocks. > About "enough space" -- how many features could a font have? And what > to do if it has more than 32? GNU coding conventions frown on > arbitrary limits, and 32 sounds like it's quite arbitrary. Can we do > better? I changed it to dynamically increase the size using existing xpalloc pattern > + Lisp_Object feature_sym = XCAR (feature_spec); > + Lisp_Object feature_val = XCDR (feature_spec); > + > + if (SYMBOLP (feature_sym) && FIXNUMP (feature_val)) > > Are we sure the value cannot be larger than most-positive-fixnum? > Emacs can handle larger values if needed. According to the harfbuzz document and the fonts I've seen, mostly the values are either 0 or 1, occasionally you see 3 for different variations. This should be fine. > As mentioned above, I think we should be smarter here: instead of > overwriting the value of :font-features of the target face, we should > merge the two lists so that it includes the features from both faces. > Font features from FROM should override the same features from TO, but > font features which exist in TO but not in FROM should be left in the > resulting list. I added support for attribute merging according to the review comment. > In addition, this will need s NEWS item and a suitable addition to the > ELisp manual, where the face attributes are described. That's right, I've added both. > Last, but not least, to accept a contribution of this size, we will > need you to sign a copyright-assignment agreement with the FSF. If > you are prepared to do that, I will send you the form to fill and the > instructions to go with it. I have signed and sent the scanned version and I am currently waiting for the digital copy from FSF. --000000000000a96bf3063da036d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eli,

Thanks for the revie= w and explanation, I addressed the issues you brought up and it should be r= eady for the next round.

> If you edit with Emacs, t= hen the .dir-locals.el file in our repository
> should set up the ind= entation for you, and then marking the region and
> typing C-M-\ will= reindent the region according to our rules.

Somehow my Emacs does n= ot respect the .dir-locals.el file, but I used clang-format to format the c= hanged lines

> Also, our style is not to use braces when the bloc= k has only one
> statement.

I have to say I had a hard time wi= th this :P I should have removed the braces from the one statement blocks.<= br>
> About "enough space" -- how many features could a fon= t have?=C2=A0 And what
> to do if it has more than 32?=C2=A0 GNU codi= ng conventions frown on
> arbitrary limits, and 32 sounds like it'= ;s quite arbitrary.=C2=A0 Can we do
> better?

I changed it to = dynamically increase the size using existing xpalloc pattern

> = =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lisp_Object feature_sym =3D XCAR = (feature_spec);
> =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lisp_Obje= ct feature_val =3D XCDR (feature_spec);
> =C2=A0+
> =C2=A0+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (SYMBOLP (feature_sym) && FIXNUMP= (feature_val))
>
> Are we sure the value cannot be larger than= most-positive-fixnum?
> Emacs can handle larger values if needed.
According to the harfbuzz document and the fonts I've seen, mostly= the values are either 0 or 1, occasionally you see 3
for different vari= ations. This should be fine.

> As mentioned above, I think we sho= uld be smarter here: instead of
> overwriting the value of :font-feat= ures of the target face, we should
> merge the two lists so that it i= ncludes the features from both faces.
> Font features from FROM shoul= d override the same features from TO, but
> font features which exist= in TO but not in FROM should be left in the
> resulting list.
I added support for attribute merging according to the review comment.
=
> In addition, this will need s NEWS item and a suitable addition to= the
> ELisp manual, where the face attributes are described.

= That's right, I've added both.

> Last, but not least, to = accept a contribution of this size, we will
> need you to sign a copy= right-assignment agreement with the FSF.=C2=A0 If
> you are prepared = to do that, I will send you the form to fill and the
> instructions t= o go with it.

I have signed and sent the scanned version and I am cu= rrently waiting for the digital copy from FSF.
--000000000000a96bf3063da036d4-- --000000000000a96bf4063da036d6 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-support-configuring-font-features-in-face.patch" Content-Disposition: attachment; filename="0001-support-configuring-font-features-in-face.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mez33p5l0 RnJvbSAwYzlkYmFmZjYyNjY5Y2NhNTRjMjNkZjA1M2Y2NTVkYzQ3ZjkxYWI3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCaW5iaW4gWWUgPHBoYW50b20yNTAxQGdtYWlsLmNvbT4KRGF0 ZTogU3VuLCAzMSBBdWcgMjAyNSAxMTozNTozMyArMDkwMApTdWJqZWN0OiBbUEFUQ0hdIHN1cHBv cnQgY29uZmlndXJpbmcgZm9udCBmZWF0dXJlcyBpbiBmYWNlCgpzdXBwb3J0IGNvbmZpZ3VyaW5n IGZvbnQgZmVhdHVyZXMgaW4gZmFjZSB3aGVuIHVzaW5nIGhhcmZidXp6IGJhY2tlbmQKdXNpbmcg YDpmb250LWZlYXR1cmVzJwoKKiBzcmMvZGlzcGV4dGVybi5oIChsZmFjZV9hdHRyaWJ1dGVfaW5k ZXgpOiBBZGQKTEZBQ0VfRk9OVF9GRUFUVVJFU19JTkRFWAoKKiBzcmMvZm9udC5jIChmb250X2xv YWRfZm9yX2xmYWNlKTogU3RvcmUgZm9udCBmZWF0dXJzIGluIGV4dHJhIGluZm8KCiogc3JjL2hi Zm9udC5jIChoYl9mZWF0dXJlc19mcm9tX2xpc3AsIGhiZm9udF9zaGFwZSk6IENvbnZlcnQgZmFj ZQpzZXR0aW5ncyB0byBoYXJmYnV6eiBmZWF0dXJlcyBhbmQgcGFzcyB0byBoYl9zaGFwZV9mdWxs CgoqIHNyYy94ZmFjZXMuYyAoRmludGVybmFsX3NldF9saXNwX2ZhY2VfYXR0cmlidXRlKQoobGZh Y2VfZnVsbHlfc3BlY2lmaWVkX3AsIGNoZWNrX2xmYWNlX2F0dHJzLCBpbml0X3hmYWNlcykKKHN5 bXNfb2ZfeGZhY2VzKTogQWRkIGRlZmluaXRpb24gb2YgZm9udCBmZWF0dXJlcyBhdHRyaWJ1dGUg YW5kIHVwZGF0ZQpzZXR0ZXIgZnVuY3Rpb24KKGxmYWNlX2hhc2gsIGxmYWNlX3NhbWVfZm9udF9h dHRyaWJ1dGVzX3ApOiBVcGRhdGUgZmFjZSBjb21wYXJzaW9uIGFuZApoYXNoaW5nIGZvciBmb250 IGZlYXR1cmVzCihtZXJnZV9mYWNlX2ZvbnRfZmVhdHVyZXMsIG1lcmdlX2ZhY2VfdmVjdG9ycywg bWVyZ2VfZmFjZV9yZWYpOiBTdXBwb3J0CmZvbnQgZmVhdHVyZXMgYXR0cmlidXRlIG1lcmdpbmcK CiogZXRjL05FV1M6IEFubm91bmNlIGZhY2UgYXR0cmlidXRlIHVwZGF0ZQoKKiBkb2MvbGlzcHJl Zi9kaXNwbGF5LnRleGk6IEFkZCBkb2N1bWVudGF0aW9uIGZvciBmb250IGZlYXR1cmVzIGZhY2UK YXR0cmlidXRlCi0tLQogZG9jL2xpc3ByZWYvZGlzcGxheS50ZXhpIHwgIDEwICsrKysKIGV0Yy9O RVdTICAgICAgICAgICAgICAgICB8ICAgNyArKysKIHNyYy9kaXNwZXh0ZXJuLmggICAgICAgICB8 ICAgMiArLQogc3JjL2ZvbnQuYyAgICAgICAgICAgICAgIHwgICA2ICsrCiBzcmMvaGJmb250LmMg ICAgICAgICAgICAgfCAgNjAgKysrKysrKysrKysrKysrKysrKy0KIHNyYy94ZmFjZXMuYyAgICAg ICAgICAgICB8IDExNiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0KIDYg ZmlsZXMgY2hhbmdlZCwgMTk3IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCgpkaWZmIC0t Z2l0IGEvZG9jL2xpc3ByZWYvZGlzcGxheS50ZXhpIGIvZG9jL2xpc3ByZWYvZGlzcGxheS50ZXhp CmluZGV4IGQwNDQ3NjM1MjNiLi4xYjdmNWY2N2UyMyAxMDA2NDQKLS0tIGEvZG9jL2xpc3ByZWYv ZGlzcGxheS50ZXhpCisrKyBiL2RvYy9saXNwcmVmL2Rpc3BsYXkudGV4aQpAQCAtMjkxNyw2ICsy OTE3LDE2IEBAIEZhY2UgQXR0cmlidXRlcwogY2hhcmFjdGVyLCBwb2ludCBjYW4gYmUgcGxhY2Vk IG9uIHdoYXQgaXMgc2VlbWluZ2x5IGEgbGluZSBhdCB0aGUgZW5kCiBvZiB0aGUgYnVmZmVyLS0t YnV0IEVtYWNzIGNhbid0IGhpZ2hsaWdodCB0aGF0IGBgbGluZScnLCBiZWNhdXNlIGl0CiBkb2Vz bid0IHJlYWxseSBleGlzdC4KKworQGl0ZW0gOmZvbnQtZmVhdHVyZXMKK0ZvbnQgZmVhdHVyZXMg dG8gdHVybiBvbiBvciBvZmYuICBJdHMgdmFsdWUgaXMgYW4gYXNzb2NpYXRpb24gbGlzdCBvZgor b3BlbiB0eXBlIHRhZyBhbmQgdGhlIHRhZyB2YWx1ZSBwYWlycyBpbiB0aGUgZm9sbG93aW5nIGZv cm06CisKK0BleGFtcGxlCisoKEBjb2Rle3plcm99IC4gQHZhcnsxfSkgKEBjb2Rle3NzMDF9IC4g QHZhcnswfSkpCitAZW5kIGV4YW1wbGUKKworVGhlIGF0dHJpYnV0ZSBpcyBvbmx5IGVmZmVjdGl2 ZSB3aGVuIHVzaW5nIEBjb2Rle2hhcmZidXp6fSBmb250IGJhY2tlbmQuCiBAZW5kIHRhYmxlCiAK IEBkZWZ1biBmb250LWZhbWlseS1saXN0ICZvcHRpb25hbCBmcmFtZQpkaWZmIC0tZ2l0IGEvZXRj L05FV1MgYi9ldGMvTkVXUwppbmRleCA0YTE5MzQ4NDU5MS4uOWRjYTgxNjU3MDggMTAwNjQ0Ci0t LSBhL2V0Yy9ORVdTCisrKyBiL2V0Yy9ORVdTCkBAIC03MSw2ICs3MSwxMyBAQCBkb25lIGZyb20g ZWFybHktaW5pdC5lbCwgc3VjaCBhcyBhZGRpbmcgdG8gJ3BhY2thZ2UtZGlyZWN0b3J5LWxpc3Qn LgogDAogKiBDaGFuZ2VzIGluIEVtYWNzIDMxLjEKIAorKiogTmV3IGZhY2Ugb3B0aW9uICc6Zm9u dC1mZWF0dXJlcycuCitFbWFjcyBub3cgc3VwcG9ydHMgZW5hYmxlIG9yIGRpc2FibGUgZm9udCBm ZWF0dXJlcyB3aGVuIHVzaW5nIGhhcmZidXp6Citmb250IGJhY2tlbmQgd2l0aCBhbiBhbGlzdC4K KworJyhzZXQtZmFjZS1hdHRyaWJ1dGUgJ2RlZmF1bHQgbmlsIDpmb250ICJGb250IG5hbWUiIDpo ZWlnaHQgODUKKyAgOmZvbnQtZmVhdHVyZXMgJygoemVybyAuIDEpIChzczE5IC4gMSkgKGN2MDEg LiAwKSApKScKKwogKiogJ3ByZXR0aWZ5LXN5bWJvbHMtbW9kZScgYXR0ZW1wdHMgdG8gaWdub3Jl IHVuZGlzcGxheWFibGUgY2hhcmFjdGVycy4KIFByZXZpb3VzbHksIHN1Y2ggY2hhcmFjdGVycyB3 b3VsZCBiZSByZW5kZXJlZCBhcywgZS5nLiwgd2hpdGUgYm94ZXMuCiAKZGlmZiAtLWdpdCBhL3Ny Yy9kaXNwZXh0ZXJuLmggYi9zcmMvZGlzcGV4dGVybi5oCmluZGV4IDE5YWIxMDRkMmU2Li42ZmM5 OGQ0MzAyZiAxMDA2NDQKLS0tIGEvc3JjL2Rpc3BleHRlcm4uaAorKysgYi9zcmMvZGlzcGV4dGVy bi5oCkBAIC0xNzA1LDEwICsxNzA1LDEwIEBAICNkZWZpbmUgRk9OVF9UT09fSElHSChmdCkJCQkJ CQlcCiAgIExGQUNFX0ZPTlRTRVRfSU5ERVgsCiAgIExGQUNFX0RJU1RBTlRfRk9SRUdST1VORF9J TkRFWCwKICAgTEZBQ0VfRVhURU5EX0lOREVYLAorICBMRkFDRV9GT05UX0ZFQVRVUkVTX0lOREVY LAogICBMRkFDRV9WRUNUT1JfU0laRQogfTsKIAotCiAvKiBCb3ggdHlwZXMgb2YgZmFjZXMuICAq LwogCiBlbnVtIGZhY2VfYm94X3R5cGUKZGlmZiAtLWdpdCBhL3NyYy9mb250LmMgYi9zcmMvZm9u dC5jCmluZGV4IGRmZTQ3OWY5MzU1Li43NjdkZTUyZjJmYSAxMDA2NDQKLS0tIGEvc3JjL2ZvbnQu YworKysgYi9zcmMvZm9udC5jCkBAIC0zNDgyLDYgKzM0ODIsMTIgQEAgZm9udF9sb2FkX2Zvcl9s ZmFjZSAoc3RydWN0IGZyYW1lICpmLCBMaXNwX09iamVjdCAqYXR0cnMsIExpc3BfT2JqZWN0IHNw ZWMpCiAgICAgewogICAgICAgbmFtZSA9IEZmb250X2dldCAoc3BlYywgUUN1c2VyX3NwZWMpOwog ICAgICAgaWYgKFNUUklOR1AgKG5hbWUpKSBmb250X3B1dF9leHRyYSAoZW50aXR5LCBRQ3VzZXJf c3BlYywgbmFtZSk7CisKKyAgICAgIC8qIFN0b3JlIGZvbnQgZmVhdHVyZXMgZnJvbSBmYWNlIGF0 dHJpYnV0ZXMgZm9yIHVzZSBkdXJpbmcKKyAgICAgICAqIHNoYXBpbmcuICAqLworICAgICAgTGlz cF9PYmplY3QgZm9udF9mZWF0dXJlcyA9IGF0dHJzW0xGQUNFX0ZPTlRfRkVBVFVSRVNfSU5ERVhd OworICAgICAgaWYgKENPTlNQIChmb250X2ZlYXR1cmVzKSkKKwlmb250X3B1dF9leHRyYSAoZW50 aXR5LCBRQ2ZvbnRfZmVhdHVyZXMsIGZvbnRfZmVhdHVyZXMpOwogICAgIH0KICAgcmV0dXJuIGVu dGl0eTsKIH0KZGlmZiAtLWdpdCBhL3NyYy9oYmZvbnQuYyBiL3NyYy9oYmZvbnQuYwppbmRleCAz ZDhkZmI0YjBlNi4uODY1NWI5NTA1ZWEgMTAwNjQ0Ci0tLSBhL3NyYy9oYmZvbnQuYworKysgYi9z cmMvaGJmb250LmMKQEAgLTIzOSw2ICsyMzksNDkgQEAgaGJmb250X290Zl9jYXBhYmlsaXR5IChz dHJ1Y3QgZm9udCAqZm9udCkKIAogLyogU3VwcG9ydCBmdW5jdGlvbnMgZm9yIEhhcmZCdXp6IHNo YXBlci4gICovCiAKKy8qIENvbnZlcnQgTGlzcCBmb250IGZlYXR1cmVzIHRvIEhhcmZCdXp6IGZl YXR1cmVzLgorICAgRkVBVFVSRVMgaXMgYSBsaXN0IG9mIChmZWF0dXJlIC4gdmFsdWUpIHBhaXJz LgorICAgUmV0dXJucyB0aGUgbnVtYmVyIG9mIGZlYXR1cmVzIGNvbnZlcnRlZCwgZmlsbHMgSEJf RkVBVFVSRVMgYXJyYXkuCisgICBIQl9GRUFUVVJFU19TSVpFIGlzIHRoZSBjdXJyZW50IHNpemUg b2YgSEJfRkVBVFVSRVMgYXJyYXkuIFRoZQorICAgZnVuY3Rpb24gYWxsb2NhdGUgbW9yZSBkZXBl bmRzIG9uIHNpemUgb2YgRkVBVFVSRVMuICAqLworc3RhdGljIHB0cmRpZmZfdAoraGJfZmVhdHVy ZXNfZnJvbV9saXNwIChMaXNwX09iamVjdCBmZWF0dXJlcywKKwkJICAgICAgIGhiX2ZlYXR1cmVf dCAqKmhiX2ZlYXR1cmVzLAorCQkgICAgICAgcHRyZGlmZl90ICpoYl9mZWF0dXJlc19zaXplKQor eworICBwdHJkaWZmX3QgY291bnQgPSAwOworCisgIGZvciAoTGlzcF9PYmplY3QgdGFpbCA9IGZl YXR1cmVzOyBDT05TUCAodGFpbCk7IHRhaWwgPSBYQ0RSICh0YWlsKSkKKyAgICB7CisgICAgICBM aXNwX09iamVjdCBmZWF0dXJlX3NwZWMgPSBYQ0FSICh0YWlsKTsKKyAgICAgIGlmIChDT05TUCAo ZmVhdHVyZV9zcGVjKSkKKwl7CisJICBpZiAoY291bnQgPj0gKmhiX2ZlYXR1cmVzX3NpemUpCisJ ICAgICpoYl9mZWF0dXJlcyA9IHhwYWxsb2MgKCpoYl9mZWF0dXJlcywgaGJfZmVhdHVyZXNfc2l6 ZSwKKwkJCQkgICAgY291bnQgLSAqaGJfZmVhdHVyZXNfc2l6ZSArIDEsIC0xLAorCQkJCSAgICBz aXplb2YgKipoYl9mZWF0dXJlcyk7CisKKwkgIExpc3BfT2JqZWN0IGZlYXR1cmVfc3ltID0gWENB UiAoZmVhdHVyZV9zcGVjKTsKKwkgIExpc3BfT2JqZWN0IGZlYXR1cmVfdmFsID0gWENEUiAoZmVh dHVyZV9zcGVjKTsKKworCSAgaWYgKFNZTUJPTFAgKGZlYXR1cmVfc3ltKSAmJiBGSVhOVU1QIChm ZWF0dXJlX3ZhbCkpCisJICAgIHsKKwkgICAgICAvKiBDb252ZXJ0IHN5bWJvbCB0byBIYXJmQnV6 eiB0YWcuICAqLworCSAgICAgIGNvbnN0IGNoYXIgKmZlYXR1cmVfbmFtZQorCQk9IFNTREFUQSAo U1lNQk9MX05BTUUgKGZlYXR1cmVfc3ltKSk7CisJICAgICAgaGJfdGFnX3QgdGFnID0gaGJfdGFn X2Zyb21fc3RyaW5nIChmZWF0dXJlX25hbWUsIC0xKTsKKworCSAgICAgICgqaGJfZmVhdHVyZXMp W2NvdW50XS50YWcgPSB0YWc7CisJICAgICAgKCpoYl9mZWF0dXJlcylbY291bnRdLnZhbHVlID0g WEZJWE5VTSAoZmVhdHVyZV92YWwpOworCSAgICAgICgqaGJfZmVhdHVyZXMpW2NvdW50XS5zdGFy dCA9IDA7CisJICAgICAgKCpoYl9mZWF0dXJlcylbY291bnRdLmVuZCA9ICh1bnNpZ25lZCBpbnQp IC0xOworCSAgICAgIGNvdW50Kys7CisJICAgIH0KKwl9CisgICAgfQorICByZXR1cm4gY291bnQ7 Cit9CisKIHN0YXRpYyBib29sIGNvbWJpbmluZ19jbGFzc19sb2FkZWQgPSBmYWxzZTsKIHN0YXRp YyBMaXNwX09iamVjdCBjYW5vbmljYWxfY29tYmluaW5nX2NsYXNzX3RhYmxlOwogCkBAIC00OTEs NyArNTM0LDIyIEBAIGhiZm9udF9zaGFwZSAoTGlzcF9PYmplY3QgbGdzdHJpbmcsIExpc3BfT2Jq ZWN0IGRpcmVjdGlvbikKICAgaWYgKCFoYl9mb250KQogICAgIHJldHVybiBtYWtlX2ZpeG51bSAo MCk7CiAKLSAgaGJfYm9vbF90IHN1Y2Nlc3MgPSBoYl9zaGFwZV9mdWxsIChoYl9mb250LCBoYl9i dWZmZXIsIE5VTEwsIDAsIE5VTEwpOworICAvKiBHZXQgZm9udCBmZWF0dXJlcyBmcm9tIHRoZSBm b250IG9iamVjdC4gICovCisgIExpc3BfT2JqZWN0IGZvbnRfZmVhdHVyZXMKKyAgICA9IEZmb250 X2dldCAoTEdTVFJJTkdfRk9OVCAobGdzdHJpbmcpLCBRQ2ZvbnRfZmVhdHVyZXMpOworCisgIC8q IENhY2hlIGZlYXR1cmVzIGFycmF5IHRvIHN0b3JlIGVuYWJsZWQgZm9udCBmZWF0dXJlcy4gICov CisgIHN0YXRpYyBoYl9mZWF0dXJlX3QgKmhiX2ZlYXR1cmVzOworICBzdGF0aWMgcHRyZGlmZl90 IGhiX2ZlYXR1cmVzX3NpemU7CisgIHVuc2lnbmVkIGludCBudW1fZmVhdHVyZXMgPSAwOworICBp ZiAoIU5JTFAgKGZvbnRfZmVhdHVyZXMpKQorICAgIG51bV9mZWF0dXJlcyA9IGhiX2ZlYXR1cmVz X2Zyb21fbGlzcCAoZm9udF9mZWF0dXJlcywgJmhiX2ZlYXR1cmVzLAorCQkJCQkgICZoYl9mZWF0 dXJlc19zaXplKTsKKyAgaGJfYm9vbF90IHN1Y2Nlc3MKKyAgICA9IGhiX3NoYXBlX2Z1bGwgKGhi X2ZvbnQsIGhiX2J1ZmZlciwKKwkJICAgICBudW1fZmVhdHVyZXMgPT0gMCA/IE5VTEwgOiBoYl9m ZWF0dXJlcywKKwkJICAgICBudW1fZmVhdHVyZXMsIE5VTEwpOworCiAgIGlmIChmb250LT5kcml2 ZXItPmVuZF9oYl9mb250KQogICAgIGZvbnQtPmRyaXZlci0+ZW5kX2hiX2ZvbnQgKGZvbnQsIGhi X2ZvbnQpOwogICBpZiAoIXN1Y2Nlc3MpCmRpZmYgLS1naXQgYS9zcmMveGZhY2VzLmMgYi9zcmMv eGZhY2VzLmMKaW5kZXggNzYyNmRmZWI3NWMuLmNhOTQ5ODNlOWY5IDEwMDY0NAotLS0gYS9zcmMv eGZhY2VzLmMKKysrIGIvc3JjL3hmYWNlcy5jCkBAIC0xODA0LDYgKzE4MDQsOCBAQCAjZGVmaW5l IExGQUNFX0ZPTlQoTEZBQ0UpCSAgICBBUkVGIChMRkFDRSwgTEZBQ0VfRk9OVF9JTkRFWCkKICNk ZWZpbmUgTEZBQ0VfSU5IRVJJVChMRkFDRSkJICAgIEFSRUYgKExGQUNFLCBMRkFDRV9JTkhFUklU X0lOREVYKQogI2RlZmluZSBMRkFDRV9GT05UU0VUKExGQUNFKQkgICAgQVJFRiAoTEZBQ0UsIExG QUNFX0ZPTlRTRVRfSU5ERVgpCiAjZGVmaW5lIExGQUNFX0VYVEVORChMRkFDRSkJICAgIEFSRUYg KExGQUNFLCBMRkFDRV9FWFRFTkRfSU5ERVgpCisjZGVmaW5lIExGQUNFX0ZPTlRfRkVBVFVSRVMo TEZBQ0UpIFwKKyAgQVJFRiAoTEZBQ0UsIExGQUNFX0ZPTlRfRkVBVFVSRVNfSU5ERVgpCiAjZGVm aW5lIExGQUNFX0RJU1RBTlRfRk9SRUdST1VORChMRkFDRSkgXAogICBBUkVGIChMRkFDRSwgTEZB Q0VfRElTVEFOVF9GT1JFR1JPVU5EX0lOREVYKQogCkBAIC0xOTE0LDYgKzE5MTYsMTEgQEAgY2hl Y2tfbGZhY2VfYXR0cnMgKExpc3BfT2JqZWN0IGF0dHJzW0xGQUNFX1ZFQ1RPUl9TSVpFXSkKIAkg ICB8fCBTVFJJTkdQIChhdHRyc1tMRkFDRV9GT05UU0VUX0lOREVYXSkKIAkgICB8fCBSRVNFVF9Q IChhdHRyc1tMRkFDRV9GT05UU0VUX0lOREVYXSkKIAkgICB8fCBOSUxQIChhdHRyc1tMRkFDRV9G T05UU0VUX0lOREVYXSkpOworICBlYXNzZXJ0IChVTlNQRUNJRklFRFAgKGF0dHJzW0xGQUNFX0ZP TlRfRkVBVFVSRVNfSU5ERVhdKQorCSAgIHx8IElHTk9SRV9ERUZGQUNFX1AgKGF0dHJzW0xGQUNF X0ZPTlRfRkVBVFVSRVNfSU5ERVhdKQorCSAgIHx8IFJFU0VUX1AgKGF0dHJzW0xGQUNFX0ZPTlRf RkVBVFVSRVNfSU5ERVhdKQorCSAgIHx8IE5JTFAgKGF0dHJzW0xGQUNFX0ZPTlRfRkVBVFVSRVNf SU5ERVhdKQorCSAgIHx8IENPTlNQIChhdHRyc1tMRkFDRV9GT05UX0ZFQVRVUkVTX0lOREVYXSkp OwogI2VuZGlmCiB9CiAKQEAgLTIxNjIsNyArMjE2OSw4IEBAIGxmYWNlX2Z1bGx5X3NwZWNpZmll ZF9wIChMaXNwX09iamVjdCBhdHRyc1tMRkFDRV9WRUNUT1JfU0laRV0pCiAKICAgZm9yIChpID0g MTsgaSA8IExGQUNFX1ZFQ1RPUl9TSVpFOyArK2kpCiAgICAgaWYgKGkgIT0gTEZBQ0VfRk9OVF9J TkRFWCAmJiBpICE9IExGQUNFX0lOSEVSSVRfSU5ERVgKLSAgICAgICAgJiYgaSAhPSBMRkFDRV9E SVNUQU5UX0ZPUkVHUk9VTkRfSU5ERVgpCisJJiYgaSAhPSBMRkFDRV9ESVNUQU5UX0ZPUkVHUk9V TkRfSU5ERVgKKwkmJiBpICE9IExGQUNFX0ZPTlRfRkVBVFVSRVNfSU5ERVgpCiAgICAgICBpZiAo KFVOU1BFQ0lGSUVEUCAoYXR0cnNbaV0pIHx8IElHTk9SRV9ERUZGQUNFX1AgKGF0dHJzW2ldKSkp CiAJYnJlYWs7CiAKQEAgLTIyNzIsNiArMjI4MCw2MCBAQCBtZXJnZV9mYWNlX2hlaWdodHMgKExp c3BfT2JqZWN0IGZyb20sIExpc3BfT2JqZWN0IHRvLCBMaXNwX09iamVjdCBpbnZhbGlkKQogICBy ZXR1cm4gcmVzdWx0OwogfQogCisvKiBNZXJnZXMgdGhlIGZhY2UgZm9udCBmZWF0dXJlcyBGUk9N IHdpdGggdGhlIGZhY2UgZm9udCBmZWF0dXJlcyBUTywKKyAgIGFuZCByZXR1cm5zIHRoZSBtZXJn ZWQgZm9udCBmZWF0dXJlcy4gICovCisKK3N0YXRpYyBMaXNwX09iamVjdAorbWVyZ2VfZmFjZV9m b250X2ZlYXR1cmVzIChMaXNwX09iamVjdCBmcm9tLCBMaXNwX09iamVjdCB0bykKK3sKKyAgaWYg KENPTlNQIChmcm9tKSkKKyAgICB7CisgICAgICBpZiAoTklMUCAodG8pIHx8IFVOU1BFQ0lGSUVE UCAodG8pKQorCXRvID0gUW5pbDsKKyAgICAgIGVsc2UKKwkvKiBDb3B5IHRvIGJlZm9yZSBtZXJn aW5nIHNvIHRoYXQgY29tcGFyc2lvbiBjYW4ga25vdyBpdCBpcyBhCisgICAgICAgZGlmZmVyZW50 IGF0dHJpYnV0ZS4gICovCisJdG8gPSBGY29weV9hbGlzdCAodG8pOworCisgICAgICBMaXNwX09i amVjdCB0YWlsID0gdG87CisgICAgICB3aGlsZSAoQ09OU1AgKHRhaWwpICYmICFOSUxQIChYQ0RS ICh0YWlsKSkpCisJdGFpbCA9IFhDRFIgKHRhaWwpOworCisgICAgICBmb3IgKExpc3BfT2JqZWN0 IGZyb21fdGFpbCA9IGZyb207ICFOSUxQIChmcm9tX3RhaWwpOworCSAgIGZyb21fdGFpbCA9IFhD RFIgKGZyb21fdGFpbCkpCisJeworCSAgTGlzcF9PYmplY3QgZm9udF9mZWF0dXJlID0gWENBUiAo ZnJvbV90YWlsKTsKKworCSAgaWYgKENPTlNQIChmb250X2ZlYXR1cmUpKQorCSAgICB7CisJICAg ICAgTGlzcF9PYmplY3QgZmVhdHVyZV9zeW0gPSBYQ0FSIChmb250X2ZlYXR1cmUpOworCSAgICAg IExpc3BfT2JqZWN0IGZlYXR1cmVfdmFsID0gWENEUiAoZm9udF9mZWF0dXJlKTsKKworCSAgICAg IGlmIChOSUxQICh0YWlsKSkKKwkJeworCQkgIC8qIENvbnN0cnVjdCBUQUlMIHRvIGEgbGlzdCBh bmQgbGV0IFRPIHBvaW50IHRvIHRoZQorCQkgICAqIHN0YXJ0IG9mIHRoZSBsaXN0LiAgKi8KKwkJ ICB0YWlsID0gRmNvbnMgKGZvbnRfZmVhdHVyZSwgUW5pbCk7CisJCSAgdG8gPSB0YWlsOworCQkg IGNvbnRpbnVlOworCQl9CisJICAgICAgTGlzcF9PYmplY3QgZXhpc2luZ19mZWF0dXJlID0gRmFz c3EgKGZlYXR1cmVfc3ltLCB0byk7CisKKwkgICAgICBpZiAoQ09OU1AgKGV4aXNpbmdfZmVhdHVy ZSkpCisJCS8qIElmIFRPIGFscmVhZHkgY29udGFpbnMgdGhlIGZlYXR1cmUsIHVwZGF0ZSB0aGUK KwkJICogdmFsdWUuICAqLworCQlYU0VUQ0RSIChleGlzaW5nX2ZlYXR1cmUsIGZlYXR1cmVfdmFs KTsKKwkgICAgICBlbHNlCisJCXsKKwkJICBYU0VUQ0RSICh0YWlsLCBGY29ucyAoZm9udF9mZWF0 dXJlLCBRbmlsKSk7CisJCSAgdGFpbCA9IFhDRFIgKHRhaWwpOworCQl9CisJICAgIH0KKwl9Cisg ICAgfQorCisgIHJldHVybiB0bzsKK30KIAogLyogTWVyZ2UgdHdvIExpc3AgZmFjZSBhdHRyaWJ1 dGUgdmVjdG9ycyBvbiBmcmFtZSBGLCBGUk9NIGFuZCBUTywgYW5kCiAgICBzdG9yZSB0aGUgcmVz dWx0aW5nIGF0dHJpYnV0ZXMgaW4gVE8sIHdoaWNoIG11c3QgYmUgYWxyZWFkeSBiZQpAQCAtMjMx OCw2ICsyMzgwLDEwIEBAIG1lcmdlX2ZhY2VfdmVjdG9ycyAoc3RydWN0IHdpbmRvdyAqdywKIAkg ICAgdG9baV0gPSBtZXJnZV9mYWNlX2hlaWdodHMgKGZyb21baV0sIHRvW2ldLCB0b1tpXSk7CiAJ ICAgIGZvbnRfY2xlYXJfcHJvcCAodG8sIEZPTlRfU0laRV9JTkRFWCk7CiAJICB9CisJZWxzZSBp ZiAoaSA9PSBMRkFDRV9GT05UX0ZFQVRVUkVTX0lOREVYCisJCSAmJiAhRVEgKHRvW2ldLCBmcm9t W2ldKSkKKwkgIHRvW2ldID0gbWVyZ2VfZmFjZV9mb250X2ZlYXR1cmVzIChmcm9tW2ldLCB0b1tp XSk7CisKIAllbHNlIGlmIChpICE9IExGQUNFX0ZPTlRfSU5ERVggJiYgISBFUSAodG9baV0sIGZy b21baV0pKQogCSAgewogCSAgICB0b1tpXSA9IGZyb21baV07CkBAIC0yOTE3LDYgKzI5ODMsMTUg QEAgbWVyZ2VfZmFjZV9yZWYgKHN0cnVjdCB3aW5kb3cgKncsCiAJCSAgZWxzZQogCQkgICAgZXJy ID0gdHJ1ZTsKIAkJfQorCSAgICAgIGVsc2UgaWYgKEVRIChrZXl3b3JkLCBRQ2ZvbnRfZmVhdHVy ZXMpKQorCQl7CisJCSAgaWYgKE5JTFAgKHZhbHVlKSB8fCBDT05TUCAodmFsdWUpKQorCQkgICAg dG9bTEZBQ0VfRk9OVF9GRUFUVVJFU19JTkRFWF0KKwkJICAgICAgPSBtZXJnZV9mYWNlX2ZvbnRf ZmVhdHVyZXMgKAorCQkJdmFsdWUsIHRvW0xGQUNFX0ZPTlRfRkVBVFVSRVNfSU5ERVhdKTsKKwkJ ICBlbHNlCisJCSAgICBlcnIgPSB0cnVlOworCQl9CiAJICAgICAgZWxzZQogCQllcnIgPSB0cnVl OwogCkBAIC0zNjQ1LDYgKzM3MjAsMzggQEAgREVGVU4gKCJpbnRlcm5hbC1zZXQtbGlzcC1mYWNl LWF0dHJpYnV0ZSIsIEZpbnRlcm5hbF9zZXRfbGlzcF9mYWNlX2F0dHJpYnV0ZSwKIAl9CiAjZW5k aWYgLyogSEFWRV9XSU5ET1dfU1lTVEVNICovCiAgICAgfQorICBlbHNlIGlmIChFUSAoYXR0ciwg UUNmb250X2ZlYXR1cmVzKSkKKyAgICB7CisgICAgICBpZiAoIVVOU1BFQ0lGSUVEUCAodmFsdWUp ICYmICFJR05PUkVfREVGRkFDRV9QICh2YWx1ZSkKKwkgICYmICFSRVNFVF9QICh2YWx1ZSkpCisJ eworCSAgLyogVmFsaWRhdGUgZm9udCBmZWF0dXJlcyBsaXN0IGZvcm1hdDogU2hvdWxkIGJlIGEg bGlzdCBvZgorCSAgICAgKGZlYXR1cmUgLiB2YWx1ZSkgcGFpcnMsIHdpdGhvdXQgZGVwbGljYXRl IGZlYXR1cmUgICovCisJICBpZiAoIU5JTFAgKHZhbHVlKSkKKwkgICAgeworCSAgICAgIExpc3Bf T2JqZWN0IHRhaWw7CisJICAgICAgTGlzcF9PYmplY3Qgc2VlbiA9IFFuaWw7CisJICAgICAgZm9y ICh0YWlsID0gdmFsdWU7IENPTlNQICh0YWlsKTsgdGFpbCA9IFhDRFIgKHRhaWwpKQorCQl7CisJ CSAgTGlzcF9PYmplY3QgZmVhdHVyZV9zcGVjID0gWENBUiAodGFpbCk7CisJCSAgaWYgKCFDT05T UCAoZmVhdHVyZV9zcGVjKQorCQkgICAgICB8fCAhU1lNQk9MUCAoWENBUiAoZmVhdHVyZV9zcGVj KSkKKwkJICAgICAgfHwgIUZJWE5VTVAgKFhDRFIgKGZlYXR1cmVfc3BlYykpKQorCQkgICAgc2ln bmFsX2Vycm9yICgiSW52YWxpZCBmb250IGZlYXR1cmVzIGZvcm1hdCIsCisJCQkJICB2YWx1ZSk7 CisJCSAgTGlzcF9PYmplY3QgZmVhdHVyZV9zeW0gPSBYQ0FSIChmZWF0dXJlX3NwZWMpOworCQkg IGlmICghTklMUCAoRm1lbXEgKGZlYXR1cmVfc3ltLCBzZWVuKSkpCisJCSAgICBzaWduYWxfZXJy b3IgKCJEdXBsaWNhdGUgZm9udCBmZWF0dXJlIHRhZyIsCisJCQkJICBmZWF0dXJlX3N5bSk7CisJ CSAgc2VlbiA9IEZjb25zIChmZWF0dXJlX3N5bSwgc2Vlbik7CisJCX0KKwkgICAgICBpZiAoIU5J TFAgKHRhaWwpKQorCQlzaWduYWxfZXJyb3IgKCJJbnZhbGlkIGZvbnQgZmVhdHVyZXMgZm9ybWF0 IiwgdmFsdWUpOworCSAgICB9CisJfQorICAgICAgb2xkX3ZhbHVlID0gTEZBQ0VfRk9OVF9GRUFU VVJFUyAobGZhY2UpOworICAgICAgQVNFVCAobGZhY2UsIExGQUNFX0ZPTlRfRkVBVFVSRVNfSU5E RVgsIHZhbHVlKTsKKyAgICB9CiAgIGVsc2UgaWYgKEVRIChhdHRyLCBRQ2luaGVyaXQpKQogICAg IHsKICAgICAgIExpc3BfT2JqZWN0IHRhaWw7CkBAIC00MjEzLDYgKzQzMjAsOCBAQCBERUZVTiAo ImludGVybmFsLWdldC1saXNwLWZhY2UtYXR0cmlidXRlIiwgRmludGVybmFsX2dldF9saXNwX2Zh Y2VfYXR0cmlidXRlLAogICAgIHZhbHVlID0gTEZBQ0VfRk9OVCAobGZhY2UpOwogICBlbHNlIGlm IChFUSAoa2V5d29yZCwgUUNmb250c2V0KSkKICAgICB2YWx1ZSA9IExGQUNFX0ZPTlRTRVQgKGxm YWNlKTsKKyAgZWxzZSBpZiAoRVEgKGtleXdvcmQsIFFDZm9udF9mZWF0dXJlcykpCisgICAgdmFs dWUgPSBMRkFDRV9GT05UX0ZFQVRVUkVTIChsZmFjZSk7CiAgIGVsc2UKICAgICBzaWduYWxfZXJy b3IgKCJJbnZhbGlkIGZhY2UgYXR0cmlidXRlIG5hbWUiLCBrZXl3b3JkKTsKIApAQCAtNDUzOSw3 ICs0NjQ4LDcgQEAgbGZhY2VfaGFzaCAoTGlzcF9PYmplY3QgKnYpCiAJICBeIFhIQVNIICh2W0xG QUNFX1dFSUdIVF9JTkRFWF0pCiAJICBeIFhIQVNIICh2W0xGQUNFX1NMQU5UX0lOREVYXSkKIAkg IF4gWEhBU0ggKHZbTEZBQ0VfU1dJRFRIX0lOREVYXSkKLQkgIF4gWEhBU0ggKHZbTEZBQ0VfSEVJ R0hUX0lOREVYXSkpOworCSAgXiBYSEFTSCAodltMRkFDRV9GT05UX0ZFQVRVUkVTX0lOREVYXSkp OwogfQogCiAjaWZkZWYgSEFWRV9XSU5ET1dfU1lTVEVNCkBAIC00NTYzLDYgKzQ2NzIsNyBAQCBs ZmFjZV9zYW1lX2ZvbnRfYXR0cmlidXRlc19wIChMaXNwX09iamVjdCAqbGZhY2UxLCBMaXNwX09i amVjdCAqbGZhY2UyKQogCSAgJiYgRVEgKGxmYWNlMVtMRkFDRV9XRUlHSFRfSU5ERVhdLCBsZmFj ZTJbTEZBQ0VfV0VJR0hUX0lOREVYXSkKIAkgICYmIEVRIChsZmFjZTFbTEZBQ0VfU0xBTlRfSU5E RVhdLCBsZmFjZTJbTEZBQ0VfU0xBTlRfSU5ERVhdKQogCSAgJiYgRVEgKGxmYWNlMVtMRkFDRV9G T05UX0lOREVYXSwgbGZhY2UyW0xGQUNFX0ZPTlRfSU5ERVhdKQorCSAgJiYgRVEgKGxmYWNlMVtM RkFDRV9GT05UX0ZFQVRVUkVTX0lOREVYXSwgbGZhY2UyW0xGQUNFX0ZPTlRfRkVBVFVSRVNfSU5E RVhdKQogCSAgJiYgKEVRIChsZmFjZTFbTEZBQ0VfRk9OVFNFVF9JTkRFWF0sIGxmYWNlMltMRkFD RV9GT05UU0VUX0lOREVYXSkKIAkgICAgICB8fCAoU1RSSU5HUCAobGZhY2UxW0xGQUNFX0ZPTlRT RVRfSU5ERVhdKQogCQkgICYmIFNUUklOR1AgKGxmYWNlMltMRkFDRV9GT05UU0VUX0lOREVYXSkK QEAgLTczNjYsNiArNzQ3Niw3IEBAIGluaXRfeGZhY2VzICh2b2lkKQogICBmYWNlX2F0dHJfc3lt W0xGQUNFX0ZPTlRTRVRfSU5ERVhdID0gUUNmb250c2V0OwogICBmYWNlX2F0dHJfc3ltW0xGQUNF X0RJU1RBTlRfRk9SRUdST1VORF9JTkRFWF0gPSBRQ2Rpc3RhbnRfZm9yZWdyb3VuZDsKICAgZmFj ZV9hdHRyX3N5bVtMRkFDRV9FWFRFTkRfSU5ERVhdID0gUUNleHRlbmQ7CisgIGZhY2VfYXR0cl9z eW1bTEZBQ0VfRk9OVF9GRUFUVVJFU19JTkRFWF0gPSBRQ2ZvbnRfZmVhdHVyZXM7CiB9CiAKIHZv aWQKQEAgLTczOTcsNiArNzUwOCw3IEBAIHN5bXNfb2ZfeGZhY2VzICh2b2lkKQogICBERUZTWU0g KFFDd2lkdGgsICI6d2lkdGgiKTsKICAgREVGU1lNIChRQ2ZvbnQsICI6Zm9udCIpOwogICBERUZT WU0gKFFDZm9udHNldCwgIjpmb250c2V0Iik7CisgIERFRlNZTSAoUUNmb250X2ZlYXR1cmVzLCAi OmZvbnQtZmVhdHVyZXMiKTsKICAgREVGU1lNIChRQ2Rpc3RhbnRfZm9yZWdyb3VuZCwgIjpkaXN0 YW50LWZvcmVncm91bmQiKTsKICAgREVGU1lNIChRQ2JvbGQsICI6Ym9sZCIpOwogICBERUZTWU0g KFFDaXRhbGljLCAiOml0YWxpYyIpOwotLSAKMi40Ny4yCgo= --000000000000a96bf4063da036d6-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 31 05:08:30 2025 Received: (at 79285) by debbugs.gnu.org; 31 Aug 2025 09:08:30 +0000 Received: from localhost ([127.0.0.1]:51964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1use34-0008Qk-5T for submit@debbugs.gnu.org; Sun, 31 Aug 2025 05:08:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38410) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1use31-0008QX-JP for 79285@debbugs.gnu.org; Sun, 31 Aug 2025 05:08:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1use2w-0007Ha-4S; Sun, 31 Aug 2025 05:08:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jZqIN3wHN4GR4qcKOBE80YeuKFP9DY8L9vff4m3XDME=; b=DJd4BD1Jm3Ti zg3+Lo1QmssrePi8hwVEE2eJsbL+E+nmNJXzPHfpOTFIokh2V7QBLOSd0W3CFvlsEaZQVWO75MEvn iRd/VN3ejTWUWgoJ7aDvLVhuDLpUqzeaLSZlCQpiTkw6vTgwZj6xeWPA+K/xeE4UD8wyLgMevhAyR uJh54W/z6FZVxAk3pAEyL/9I7StExCdKJF6zhXry7g1Ok2MuFHsuaEcIomRU0s4r8z5zN3dLjuluC 64OHw0AGdN3N28EJigD0TU0bIV6SIkscHF7eeGK0C0VFzXtZFlLLOrjNNfx2e4Lq/bqveDOQW0ikS 14wl8sLciS+RivomNg9hrw==; Date: Sun, 31 Aug 2025 12:08:18 +0300 Message-Id: <86ms7foo3h.fsf@gnu.org> From: Eli Zaretskii To: Binbin YE In-Reply-To: (message from Binbin YE on Sun, 31 Aug 2025 11:42:50 +0900) Subject: Re: bug#79285: [Patch] support :font-features in face References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Binbin YE > Date: Sun, 31 Aug 2025 11:42:50 +0900 > Cc: 79285@debbugs.gnu.org > > Thanks for the review and explanation, I addressed the issues you brought up and it should be ready for the > next round. Thanks, see further comments below. > From 0c9dbaff62669cca54c23df053f655dc47f91ab7 Mon Sep 17 00:00:00 2001 > From: Binbin Ye > Date: Sun, 31 Aug 2025 11:35:33 +0900 > Subject: [PATCH] support configuring font features in face > > support configuring font features in face when using harfbuzz backend > using `:font-features' > > * src/dispextern.h (lface_attribute_index): Add > LFACE_FONT_FEATURES_INDEX > > * src/font.c (font_load_for_lface): Store font featurs in extra info > > * src/hbfont.c (hb_features_from_lisp, hbfont_shape): Convert face > settings to harfbuzz features and pass to hb_shape_full > > * src/xfaces.c (Finternal_set_lisp_face_attribute) > (lface_fully_specified_p, check_lface_attrs, init_xfaces) > (syms_of_xfaces): Add definition of font features attribute and update > setter function > (lface_hash, lface_same_font_attributes_p): Update face comparsion and > hashing for font features > (merge_face_font_features, merge_face_vectors, merge_face_ref): Support > font features attribute merging > > * etc/NEWS: Announce face attribute update > > * doc/lispref/display.texi: Add documentation for font features face > attribute All the entries in the log message should begin with an upper-case letter and end with a period. > +@item :font-features > +Font features to turn on or off. Its value is an association list of > +open type tag and the tag value pairs in the following form: > + > +@example > +((@code{zero} . @var{1}) (@code{ss01} . @var{0})) > +@end example > + > +The attribute is only effective when using @code{harfbuzz} font backend. Several minor nits here: . the official spelling is "HarfBuzz", so please use that . 1 and 0 are literal constants, so @var is not appropriate . you say "the following form", but actually show an example, not the general shape of the form So my suggestion is to rephrase as follows: @item :font-features Font features to turn on or off. The value is an association list of open type tag and the tag value pairs in the form @w{@code{((@var{tag1} . @var{val1}) (@var{tag2} . @var{val2})@dots{})}}. The tag values are in most cases either 1 to turn the feature on or 0 to turn it off. For example: @example ((@code{zero} . 1) (@code{ss01} . 0)) @end example @noindent This example turns on the @code{zero} feature and turns off the @code{ss01} feature. This attribute is only effective when using @code{HarfBuzz} font backend (@pxref{Low-Level Font}). And I think we should have here a @uref pointer to the Web page that documents the OpenType tags. > +** New face option ':font-features'. ^^^^^^^^^^^ "face attribute" > +Emacs now supports enable or disable font features when using harfbuzz ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^ "enabling or disabling of font features" Also, "HarfBuzz". > +font backend with an alist. ^^^^^^^^^^^^^ I would say "by specifying this attribute whose value is an alist of OpenType tags and tag values" > +'(set-face-attribute 'default nil :font "Font name" :height 85 > + :font-features '((zero . 1) (ss19 . 1) (cv01 . 0) ))' This should have "For example:" before it. > @@ -3482,6 +3482,12 @@ font_load_for_lface (struct frame *f, Lisp_Object *attrs, Lisp_Object spec) > { > name = Ffont_get (spec, QCuser_spec); > if (STRINGP (name)) font_put_extra (entity, QCuser_spec, name); > + > + /* Store font features from face attributes for use during > + * shaping. */ We don't use this style of comments, so please remove the leading "*" in the second line. > + if (SYMBOLP (feature_sym) && FIXNUMP (feature_val)) > + { > + /* Convert symbol to HarfBuzz tag. */ > + const char *feature_name > + = SSDATA (SYMBOL_NAME (feature_sym)); > + hb_tag_t tag = hb_tag_from_string (feature_name, -1); We will need to DEF_DLL_FN and LOAD_DLL_FN for hb_tag_from_string, for this to work on Windows. But you can leave this to me, if you want. > + (*hb_features)[count].start = 0; > + (*hb_features)[count].end = (unsigned int) -1; Shouldn't we use HB_FEATURE_GLOBAL_START and HB_FEATURE_GLOBAL_END here? > + /* Cache features array to store enabled font features. */ > + static hb_feature_t *hb_features; > + static ptrdiff_t hb_features_size; > + unsigned int num_features = 0; > + if (!NILP (font_features)) > + num_features = hb_features_from_lisp (font_features, &hb_features, > + &hb_features_size); > + hb_bool_t success > + = hb_shape_full (hb_font, hb_buffer, > + num_features == 0 ? NULL : hb_features, > + num_features, NULL); Hmm... not sure I understand what kind of caching is being used here. AFAIU, hb_features are recomputed anew each time we call hbfont_shape, so how does this caching help? > +/* Merges the face font features FROM with the face font features TO, > + and returns the merged font features. */ "Merge" and "return", according to our style of such commentary. > + if (NILP (tail)) > + { > + /* Construct TAIL to a list and let TO point to the > + * start of the list. */ Style of comments again. > + if (CONSP (exising_feature)) > + /* If TO already contains the feature, update the > + * value. */ And here. > + /* Validate font features list format: Should be a list of > + (feature . value) pairs, without deplicate feature */ Period missing at the end of this comment. > + if (!CONSP (feature_spec) > + || !SYMBOLP (XCAR (feature_spec)) > + || !FIXNUMP (XCDR (feature_spec))) > + signal_error ("Invalid font features format", > + value); > + Lisp_Object feature_sym = XCAR (feature_spec); > + if (!NILP (Fmemq (feature_sym, seen))) > + signal_error ("Duplicate font feature tag", > + feature_sym); > + seen = Fcons (feature_sym, seen); > + } > + if (!NILP (tail)) > + signal_error ("Invalid font features format", value); Can we show the offending feature and value as part of the error message here? IME, it makes debugging problematic Lisp code much easier. Thanks again for working on this. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 31 05:26:19 2025 Received: (at 79285) by debbugs.gnu.org; 31 Aug 2025 09:26:19 +0000 Received: from localhost ([127.0.0.1]:51986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1useKI-0000oO-Or for submit@debbugs.gnu.org; Sun, 31 Aug 2025 05:26:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53510) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1useKF-0000o4-TE for 79285@debbugs.gnu.org; Sun, 31 Aug 2025 05:26:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1useK8-0006wJ-Np; Sun, 31 Aug 2025 05:26:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=oonMm7Yq35axWG6tIZ+kRK9dc83VXU2hbK/bOqlQYbg=; b=Zt2mOJqIhCFn A4foUNn519FMUwukguwGutgPJlUFp4cLpp6d4oNTd7fIgYGfpRF0MDsvUqOcpIqh2uQgU+AaTHJzG /mNTM9+xxOQhW3aDHQhi+RGM4Mh+kH+VCpPx+EiYlFxZBVpf2hQIFbw91iMV398FeJCAUP+z9v+CW M98up7PPdZovUF62bQo7hrImwKDCboB7CxyujTtUuKdU1USW/f3euq904kKXB3S1LeN4r8xgIRhQA WnkVaPZTGwxt0nK387xoi+eQ0MwzVeeoecHppw+JcQX2YtP4aJ/+e+aBhCp75YTrtADNLpKB4EHYg DbkpLVCsyDxqygI+FT2Gbw==; Date: Sun, 31 Aug 2025 12:25:32 +0300 Message-Id: <86ldmzonar.fsf@gnu.org> From: Eli Zaretskii To: phantom2501@gmail.com In-Reply-To: <86ms7foo3h.fsf@gnu.org> (message from Eli Zaretskii on Sun, 31 Aug 2025 12:08:18 +0300) Subject: Re: bug#79285: [Patch] support :font-features in face References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 79285@debbugs.gnu.org > Date: Sun, 31 Aug 2025 12:08:18 +0300 > From: Eli Zaretskii > > > From: Binbin YE > > Date: Sun, 31 Aug 2025 11:42:50 +0900 > > Cc: 79285@debbugs.gnu.org > > > > Thanks for the review and explanation, I addressed the issues you brought up and it should be ready for the > > next round. > > Thanks, see further comments below. One more comment: did you try this code with text that we normally don't pass to the shaping engine to display, like plain-ASCII text? Emacs normally calls the shaping engine only for characters whose slots in composition-function-table are non-nil. Otherwise we display the font glyphs directly without shaping. (This is an optimization: using the shaping engine slows down redisplay, because it is implemented by calling to Lisp, which then calls back into C.) So, for example, if someone places a face with :font-features attribute on plain-ASCII text, they will probably not see any effect. If I'm right, then we will need to make changes in display-engine functions like composition_compute_stop_pos, composition_reseat_it, find_composition, and others, to force the text which has such a face attribute to be handed to HarfBuzz for shaping. An alternative is to require that use of this face attribute needs special setup of composition-function-table, but that is IMO worse because it will slow down display of the relevant characters even if they don't have the face with this attribute. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 31 05:35:18 2025 Received: (at 79285) by debbugs.gnu.org; 31 Aug 2025 09:35:18 +0000 Received: from localhost ([127.0.0.1]:52008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1useT0-0001Hm-Fb for submit@debbugs.gnu.org; Sun, 31 Aug 2025 05:35:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49872) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1useSy-0001HY-Pg for 79285@debbugs.gnu.org; Sun, 31 Aug 2025 05:35:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1useSt-0001gl-6a; Sun, 31 Aug 2025 05:35:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=SWaIKjg3+K8ZcTvku7On5z3js49BhDqQUkA35hVcH+k=; b=kfZcGNxSGaPd GX8ArrZ0T3QihM5gqiCrdC1jPWEJZm1PLomqXRhZ1DyDmgTyriLfaMrnbiA16abcBkY1kq8A/wYt3 mPEUkFND//IsyqeBlN/QrL9ROiToOgHG7nF9+6YSJ7BYbAIrEFIRUzvbvTeb8EfRllSYWhuYQ16bD P/OtqzRSiDMAZt0Ujd+neK9x3fYzl4U5Z5mDpfg/BsiOLiDL5soTj1VtHAMTo944g+R+XwFiRJ9fc VBDz3OZp5M9ULtl1S79VPCVHJTJxydDCGCMy4Zb/TIZUJd+xJVcfslRFQDIaBXEXGzy1ApUGB5Sfo 6k7R3gtU3jQxufq8FUiDgg==; Date: Sun, 31 Aug 2025 12:35:05 +0300 Message-Id: <86iki3omuu.fsf@gnu.org> From: Eli Zaretskii To: phantom2501@gmail.com In-Reply-To: <86ldmzonar.fsf@gnu.org> (message from Eli Zaretskii on Sun, 31 Aug 2025 12:25:32 +0300) Subject: Re: bug#79285: [Patch] support :font-features in face References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> <86ldmzonar.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 79285@debbugs.gnu.org > Date: Sun, 31 Aug 2025 12:25:32 +0300 > From: Eli Zaretskii > > If I'm right, then we will need to make changes in display-engine > functions like composition_compute_stop_pos, composition_reseat_it, > find_composition, and others, to force the text which has such a face > attribute to be handed to HarfBuzz for shaping. An alternative is to > require that use of this face attribute needs special setup of > composition-function-table, but that is IMO worse because it will slow > down display of the relevant characters even if they don't have the > face with this attribute. Or maybe it will be enough to make the change in get_glyph_face_and_encoding, as the etc/TODO item suggests: instead of calling the 'encode_char' method of the font driver, we should invoke the 'shape' method But this will only work if the effect of the relevant font features is per-character, i.e. HarfBuzz doesn't need to see the entire word to shape the characters according to the requested feature(s). Do you happen to know if all the features that are relevant for us can be applied on a character-by-character basis? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 31 06:06:08 2025 Received: (at 79285) by debbugs.gnu.org; 31 Aug 2025 10:06:08 +0000 Received: from localhost ([127.0.0.1]:52126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1usewq-0003AQ-3l for submit@debbugs.gnu.org; Sun, 31 Aug 2025 06:06:08 -0400 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:44394) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1usewn-00039b-NK for 79285@debbugs.gnu.org; Sun, 31 Aug 2025 06:06:06 -0400 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3d2564399a5so326013f8f.1 for <79285@debbugs.gnu.org>; Sun, 31 Aug 2025 03:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756634759; x=1757239559; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i09efq5+AOFg9K/YNWcQkRP7iK103oEcs51nkteC030=; b=M9ytLo1aCHLrkh9aiHJuDayynQDYTUVdS5eTVoozkEbXKutmjk38n7oEd0jBaukpk2 nAbY8eTNOUBfeE7ym0Xz3GxYMQOhfdOP3pV3xe4IJEv2ddKVdRp8Ja8MGA9UrCZafThI G//LL3WwTl2XiTPE8iYoeMDI0MptZ8cqEmOfEMrS1zgxrH7F0Zkd6OfLl04NrDM4Jb29 xOyq7UAsEoqoxF6Qzy/TX+t4t7O2WAErS1M5Lo/XmBoUMQ6GKO7IVr55Oa2iDCnAgCAY Ob9N6CheGY6TGuXsoKuspZyLlMzhRf2PXBn7KiyO5wtgFHRiEosbBeq7ee8jfT+v7MGx KSvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756634759; x=1757239559; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i09efq5+AOFg9K/YNWcQkRP7iK103oEcs51nkteC030=; b=Be7FCeB5WYx/PxQI4TcCs1kt6NULi/19sc1UI7wwkV8vsZC+5rUQtnCGcIDxSFsreD fhJz2mO+m2AAZrkjVMFe96kYkrtTNoKAroxEuvdBlgNvC3Sqhj3CLitxZMRPK7A/1IIR 1GMltXuwAvJa1SuQWGoafQW+07uAN03f89ypK/0rI2QWr/h5BgYgUMa+RglOSjLOjP+i xFY8T+DeKJvXFOaMWGe9yhBDwbv5vBJNRn7EgZ4ON3j4m88/x6Ux+rBeb0OUZx4RsSk0 3LzBVimzTGGZWt8BBVCSGIJ+v8RSTWlX/McjPYUBSpVW6bUZ8RxnYt7xs1+19suP8sv/ 4qNg== X-Gm-Message-State: AOJu0YxqBoC0/L7IuQ9FVut0duFtSc2iOBdsYAfuxjldw4oNFRq1EiBn US5fCnA1iHap4e+J6jVYCp2AiJiHazmyfZnwjLuCYuIXkSPXRB+Y80DDuOUcwsAShhsPX+HxCrp xdkoycN7A53iu9pdyDdNYmFHOk85TG7Uu9bTL X-Gm-Gg: ASbGncv/011Hmm+oYxkc5gTekcUGFJXrKzGk6G6CP9v/X3zsYcHlsNJVinUtDWulYrR aga5derRB5t8NVKYRa6BdLSvEKu/kIOyw3Iw0b8gmz0aDR8gUQdIjcB8sbAJ+J8lKdbKZi7ZyBb CW9C4AZmbCJSjojQbiQyf2w7H+6P1RkiMkg0KHS2Q1zymXXXeuWU2thnSqL6Z0sy+GSLRyW+PYK kKeuZFq0ALVdLXB7M2LMES2HHIT+QNKqouzdSDKl4iazyRT9QBXPvM+ X-Google-Smtp-Source: AGHT+IEUvHEaNlo1srsZvshmBjoqhpVEUGmuDHUq+eqMjVUayB0euHld97BBVs0IylI99zN7TpCM+8RHv22+OF5Bf6M= X-Received: by 2002:a05:6000:1a8c:b0:3cf:74e0:55ac with SMTP id ffacd0b85a97d-3d1dfb108b2mr3109583f8f.38.1756634759258; Sun, 31 Aug 2025 03:05:59 -0700 (PDT) MIME-Version: 1.0 References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> In-Reply-To: <86ms7foo3h.fsf@gnu.org> From: Binbin YE Date: Sun, 31 Aug 2025 19:05:48 +0900 X-Gm-Features: Ac12FXzOmBoFel-nQbsK29zGrE1qymNMWOMbZG0slev-Ut9afs6qtNw3JkVZ4M0 Message-ID: Subject: Re: bug#79285: [Patch] support :font-features in face To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000d36829063da66618" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000d36829063da66618 Content-Type: text/plain; charset="UTF-8" Hi Eli, Thanks for the comments. Some quick responses: > + if (SYMBOLP (feature_sym) && FIXNUMP (feature_val)) > + { > > + /* Convert symbol to HarfBuzz tag. */ > + const char *feature_name > + = SSDATA (SYMBOL_NAME (feature_sym)); > + hb_tag_t tag = hb_tag_from_string (feature_name, -1); > > We will need to DEF_DLL_FN and LOAD_DLL_FN for hb_tag_from_string, for > this to work on Windows. But you can leave this to me, if you want. I don't have access to a Windows machine, it would be great if you can help me with that. > + /* Cache features array to store enabled font features. */ > + static hb_feature_t *hb_features; > + static ptrdiff_t hb_features_size; > + unsigned int num_features = 0; > + if (!NILP (font_features)) > + num_features = hb_features_from_lisp (font_features, &hb_features, > > + &hb_features_size); > + hb_bool_t success > + = hb_shape_full (hb_font, hb_buffer, > > + num_features == 0 ? NULL : hb_features, > + num_features, NULL); > > Hmm... not sure I understand what kind of caching is being used here. > AFAIU, hb_features are recomputed anew each time we call hbfont_shape, > so how does this caching help? I saw the comment a few lines below for the hb_buffer (static hb_buffer_t *hb_buffer = NULL;) to have less allocation and I followed that. It is true that the features are recomputed but the array can be reused in the next call. If new allocation is preferred I can change to that. > One more comment: did you try this code with text that we normally > don't pass to the shaping engine to display, like plain-ASCII text? > Emacs normally calls the shaping engine only for characters whose > slots in composition-function-table are non-nil. Otherwise we display > the font glyphs directly without shaping. (This is an optimization: > using the shaping engine slows down redisplay, because it is > implemented by calling to Lisp, which then calls back into C.) So, > for example, if someone places a face with :font-features attribute on > plain-ASCII text, they will probably not see any effect. > Yes you are right about it. I was confused why it did not have any effect initially. And I figured I needed to do something with composition-function-table. This is my test code #+begin_src elisp (set-char-table-range composition-function-table ?0 '(["." 0 font-shape-gstring])) (set-char-table-range composition-function-table ?! '(["\\(!==\\)" 0 font-shape-gstring])) #+end_src #+begin_src elisp (set-face-attribute 'default nil :font "JetBrains Mono" :height 100 :font-features '((zero . 0) (ss19 . 1) (zero . 1))) #+end_src #+begin_src elisp (set-face-attribute 'default nil :font "JetBrains Mono" :height 100 :font-features '((zero . 1))) #+end_src > If I'm right, then we will need to make changes in display-engine > functions like composition_compute_stop_pos, composition_reseat_it, > find_composition, and others, to force the text which has such a face > attribute to be handed to HarfBuzz for shaping. An alternative is to > require that use of this face attribute needs special setup of > composition-function-table, but that is IMO worse because it will slow > down display of the relevant characters even if they don't have the > face with this attribute. Thanks for pointing that out, I can explore that part of the code. I have not looked much into composite.c --000000000000d36829063da66618 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eli,

Thanks for the comments. Some quick respons= es:

> =C2=A0+ =C2=A0 =C2=A0 =C2=A0 if (SYMBOLP (feature_sym) &= ;& FIXNUMP (feature_val))
> =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 {=
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Convert symbol to Har= fBuzz tag. =C2=A0*/
> =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cons= t char *feature_name
> =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =3D SSDATA (SYMBOL_NAME (feature_sym));
> =C2=A0+ =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 hb_tag_t tag =3D hb_tag_from_string (feature_name, -1)= ;
>
> We will need to DEF_DLL_FN and LOAD_DLL_FN for hb_tag_fro= m_string, for
> this to work on Windows.=C2=A0 But you can leave this= to me, if you want.

I don't have access to a Windows machine, i= t would be great if you can help me with that.

> =C2=A0+ =C2=A0/*= Cache features array to store enabled font features. =C2=A0*/
> =C2= =A0+ =C2=A0static hb_feature_t *hb_features;
> =C2=A0+ =C2=A0static p= trdiff_t hb_features_size;
> =C2=A0+ =C2=A0unsigned int num_features = =3D 0;
> =C2=A0+ =C2=A0if (!NILP (font_features))
> =C2=A0+ =C2= =A0 =C2=A0num_features =3D hb_features_from_lisp (font_features, &hb_fe= atures,
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 &hb_features_size);
> =C2=A0+ =C2=A0hb_bool_t success
&= gt; =C2=A0+ =C2=A0 =C2=A0=3D hb_shape_full (hb_font, hb_buffer,
> >= ; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0num_featu= res =3D=3D 0 ? NULL : hb_features,
> =C2=A0+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0num_features, NULL);
>
>= Hmm... not sure I understand what kind of caching is being used here.
&= gt; AFAIU, hb_features are recomputed anew each time we call hbfont_shape,<= br>> so how does this caching help?

I saw the comment a few lines= below for the hb_buffer (static hb_buffer_t *hb_buffer =3D NULL;) to have = less allocation and
I followed that. It is true that the features are re= computed but the array can be reused in the next call. If new
allocation= is preferred I can change to that.


> One more comment: did y= ou try this code with text that we normally
> don't pass to the s= haping engine to display, like plain-ASCII text?
> Emacs normally cal= ls the shaping engine only for characters whose
> slots in compositio= n-function-table are non-nil.=C2=A0 Otherwise we display
> the font g= lyphs directly without shaping. =C2=A0(This is an optimization:
> usi= ng the shaping engine slows down redisplay, because it is
> implement= ed by calling to Lisp, which then calls back into C.) =C2=A0So,
> for= example, if someone places a face with :font-features attribute on
>= plain-ASCII text, they will probably not see any effect.
>

Y= es you are right about it. I was confused why it did not have any effect in= itially. And I figured I needed to do
something with composition-functio= n-table. This is my test code

#+begin_src elisp
=C2=A0 (set-char-= table-range composition-function-table
=C2=A0 =C2=A0 ?0
=C2=A0 =C2=A0= '(["." 0 font-shape-gstring]))

=C2=A0 (set-char-table= -range composition-function-table
=C2=A0 =C2=A0 ?!
=C2=A0 =C2=A0 '= ;(["\\(!=3D=3D\\)" 0 font-shape-gstring]))
#+end_src

#+= begin_src elisp
=C2=A0 (set-face-attribute 'default nil :font "= JetBrains Mono" :height 100
=C2=A0 =C2=A0 :font-features '((zer= o . 0) (ss19 . 1) (zero . 1)))
#+end_src

#+begin_src elisp
=C2= =A0 (set-face-attribute 'default nil :font "JetBrains Mono" := height 100
=C2=A0 =C2=A0 :font-features '((zero . 1)))
#+end_src<= br>

> If I'm right, then we will need to make changes in disp= lay-engine
> functions like composition_compute_stop_pos, composition= _reseat_it,
> find_composition, and others, to force the text which h= as such a face
> attribute to be handed to HarfBuzz for shaping.=C2= =A0 An alternative is to
> require that use of this face attribute ne= eds special setup of
> composition-function-table, but that is IMO wo= rse because it will slow
> down display of the relevant characters ev= en if they don't have the
> face with this attribute.

Than= ks for pointing that out, I can explore that part of the code. I have not l= ooked much into composite.c
--000000000000d36829063da66618-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 31 06:24:07 2025 Received: (at 79285) by debbugs.gnu.org; 31 Aug 2025 10:24:07 +0000 Received: from localhost ([127.0.0.1]:52159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1usfEE-0003xl-Gz for submit@debbugs.gnu.org; Sun, 31 Aug 2025 06:24:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45598) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1usfEA-0003xE-T6 for 79285@debbugs.gnu.org; Sun, 31 Aug 2025 06:24:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1usfE5-0001eg-K9; Sun, 31 Aug 2025 06:23:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mYpUiIdm0mierL/Hs3mwuCNH2BHQbPf1TYRQ3HePAHI=; b=Ex0ohF9TWSgn kDpHYUgeowZx7NTzjrF2bZQNE+N4yDOgdH7Zy8EAdCelfWtFzsVJOldC+ltdNIN2f+x4ks7V/l6yN MFovyYg2KP5FoVK3erw+B3W3ZeTkjy6SJdu2vuKPjwJ1aRftmnq//bQqhck/Q54GRXhYbMRJGc/Dq TeadisDA9GlyKhbyp2gn/krXeRTRKwAg1t7jbiesp+eJnOrjZ8YjUkwX+bdGpiSixUflEa8XPz+pI 8Wkxoi5dbUnQenhPZwx1JqCcIDWXsclZieaSEaGVJdU3mtidrjHMuvb3Ak/mcxVeel03JcH4PNyz5 4RjMkFJcs0aRKJtrXVdD0g==; Date: Sun, 31 Aug 2025 13:23:55 +0300 Message-Id: <86h5xnoklg.fsf@gnu.org> From: Eli Zaretskii To: Binbin YE In-Reply-To: (message from Binbin YE on Sun, 31 Aug 2025 19:05:48 +0900) Subject: Re: bug#79285: [Patch] support :font-features in face References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Binbin YE > Date: Sun, 31 Aug 2025 19:05:48 +0900 > Cc: 79285@debbugs.gnu.org > > > + if (SYMBOLP (feature_sym) && FIXNUMP (feature_val)) > > + { > > > + /* Convert symbol to HarfBuzz tag. */ > > + const char *feature_name > > + = SSDATA (SYMBOL_NAME (feature_sym)); > > + hb_tag_t tag = hb_tag_from_string (feature_name, -1); > > > > We will need to DEF_DLL_FN and LOAD_DLL_FN for hb_tag_from_string, for > > this to work on Windows. But you can leave this to me, if you want. > > I don't have access to a Windows machine, it would be great if you can help me with that. OK, so I will add that when the patch is installed. > > + /* Cache features array to store enabled font features. */ > > + static hb_feature_t *hb_features; > > + static ptrdiff_t hb_features_size; > > + unsigned int num_features = 0; > > + if (!NILP (font_features)) > > + num_features = hb_features_from_lisp (font_features, &hb_features, > > > + &hb_features_size); > > + hb_bool_t success > > + = hb_shape_full (hb_font, hb_buffer, > > > + num_features == 0 ? NULL : hb_features, > > + num_features, NULL); > > > > Hmm... not sure I understand what kind of caching is being used here. > > AFAIU, hb_features are recomputed anew each time we call hbfont_shape, > > so how does this caching help? > > I saw the comment a few lines below for the hb_buffer (static hb_buffer_t *hb_buffer = NULL;) to have less > allocation and > I followed that. It is true that the features are recomputed but the array can be reused in the next call. If new > allocation is preferred I can change to that. No, I guess it's okay to leave your code as it is. > > One more comment: did you try this code with text that we normally > > don't pass to the shaping engine to display, like plain-ASCII text? > > Emacs normally calls the shaping engine only for characters whose > > slots in composition-function-table are non-nil. Otherwise we display > > the font glyphs directly without shaping. (This is an optimization: > > using the shaping engine slows down redisplay, because it is > > implemented by calling to Lisp, which then calls back into C.) So, > > for example, if someone places a face with :font-features attribute on > > plain-ASCII text, they will probably not see any effect. > > > > Yes you are right about it. I was confused why it did not have any effect initially. And I figured I needed to do > something with composition-function-table. This is my test code > > #+begin_src elisp > (set-char-table-range composition-function-table > ?0 > '(["." 0 font-shape-gstring])) > > (set-char-table-range composition-function-table > ?! > '(["\\(!==\\)" 0 font-shape-gstring])) > #+end_src > > #+begin_src elisp > (set-face-attribute 'default nil :font "JetBrains Mono" :height 100 > :font-features '((zero . 0) (ss19 . 1) (zero . 1))) > #+end_src > > #+begin_src elisp > (set-face-attribute 'default nil :font "JetBrains Mono" :height 100 > :font-features '((zero . 1))) > #+end_src > > > If I'm right, then we will need to make changes in display-engine > > functions like composition_compute_stop_pos, composition_reseat_it, > > find_composition, and others, to force the text which has such a face > > attribute to be handed to HarfBuzz for shaping. An alternative is to > > require that use of this face attribute needs special setup of > > composition-function-table, but that is IMO worse because it will slow > > down display of the relevant characters even if they don't have the > > face with this attribute. > > Thanks for pointing that out, I can explore that part of the code. I have not looked much into composite.c See my other mail: perhaps using the shape method in get_glyph_face_and_encoding will be enough. If that works, it's a much simpler change. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 02 19:40:59 2025 Received: (at 79285) by debbugs.gnu.org; 2 Sep 2025 23:40:59 +0000 Received: from localhost ([127.0.0.1]:37153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utacU-0004Gg-LP for submit@debbugs.gnu.org; Tue, 02 Sep 2025 19:40:59 -0400 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:55683) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1utacR-0004GR-QP for 79285@debbugs.gnu.org; Tue, 02 Sep 2025 19:40:56 -0400 Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-45b7da4101fso17375905e9.3 for <79285@debbugs.gnu.org>; Tue, 02 Sep 2025 16:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756856450; x=1757461250; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7eCMDZWYGbr1fI3GCQxKSKUdIS0BJ0BBAuL1GebZiYY=; b=H2zwfq3z+S+P87k9yrMXbTufXLZfXqW3sQcHhnuMyvf0AYBFdW8oni1pIugTozBU3E TwY96q5iYoVjCXTxUtqlnHyQM4rFgRFOYrPY7FeK5VdV0tDS2Fbvb8eNWnZY8LWqb9kB /X65IFKSheTah9PUk4aFYQnQMmANzmGpFKRwMjcl/03WMc0JtoL2dJCcrq9J8ZEFgXW4 oGSb41IJuxkBt3/uiIPt+0sc4gaNHKuLheAA/lvC7i23qVxsOXT6rRxHVizge5OfGXFK UBbWVaFAk6GHPRtvWLE1Sx2F2PxOkdcdNI09+AnrJyh1X0KY5Iw0O+GtPQPYl1N+Kd98 zLdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756856450; x=1757461250; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7eCMDZWYGbr1fI3GCQxKSKUdIS0BJ0BBAuL1GebZiYY=; b=j4rDtdQJK8ZKmL+CAFXIxq527hVnRY1Mf+QxvgYcArakA2rg5tD8BKFp/+q4AjnliK XJKlBxzAhq2Ngufl3ceX32NkLKMBJzd/tAmegA6PkiRa2OYwzOK9en/Ehvt6afy5A0cG BIT1OKuWB9kyW8q9n8usV3YZxwOjb75uQIsBiC4U7Nr9Z15hMCGwhgWTYWORVVHPCXMY sTblZomspbwjhoeDUGCVEI9hL3T0hnseAEjUsysm8H/CyNPhAxKCWm6FioylgbHoqOWS ABCJVsEDyKWaRZV5hK81QkA2Uc7DykSkzdVciZ9JJoHpPLkg7pabT0qWDGFOJoasyOlw 6zKw== X-Gm-Message-State: AOJu0YxbPIoi0+U8EOVQdoBsLrv6z5foakjTf2JrdtvbZQH9YrrG70JT e4grmNahZFBJimHJAKqdIdg03TVK/uGOQww94jlZSnfbSuCxhxErmyGY+JbsuVCXRAkMojmhlRU AIMJtqvkSTutIDH1aBAfO+l0t30Y53kk= X-Gm-Gg: ASbGncsphTPN+tn+dp1nGjQHwbYow38bX/v0uVJWEDPHxMJdI6EB+FJyw98kXGMr9jw uWeuneWjzD/Ii0OtBmeZGpT9uRNK/n454KEKf160BgbCp2ZI5y1D6WodvEpBNkqFKeq2Ianfz4g XINe3EjgV6ssRFvs42WZ5fhXqGPFduUe4Mm7mzgchAhSHGPPfxZguJKTamYfadtt31U8F7YgR3H wzbLyj+yDMX8TTCDxMC7w+EA4NAzUHsSIOEYHmKbRrm4nKHZQju2QRmCDp1 X-Google-Smtp-Source: AGHT+IG6aXJzdSh7U4ahnYSaCzbnNyrrPv3CXv8cQFNa0pqEJvZIZZt3vm4i+A2TNpYH9Gc0A6IHmOjdQBPGFkM7RZs= X-Received: by 2002:a05:6000:1883:b0:3cb:3490:6ba5 with SMTP id ffacd0b85a97d-3d1dd81d999mr7178851f8f.9.1756856449477; Tue, 02 Sep 2025 16:40:49 -0700 (PDT) MIME-Version: 1.0 References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> <86ldmzonar.fsf@gnu.org> <86iki3omuu.fsf@gnu.org> In-Reply-To: <86iki3omuu.fsf@gnu.org> From: Binbin YE Date: Wed, 3 Sep 2025 08:40:38 +0900 X-Gm-Features: Ac12FXzq0oGMB7SbNCry1j1YZ3z5L6LKp4Iae81Fx2gYdYDn4qIgz4T0YlA6N1M Message-ID: Subject: Re: bug#79285: [Patch] support :font-features in face To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000097af23063dda0486" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --00000000000097af23063dda0486 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 31, 2025 at 18:35 Eli Zaretskii wrote: > > Cc: 79285@debbugs.gnu.org > > Date: Sun, 31 Aug 2025 12:25:32 +0300 > > From: Eli Zaretskii > > > > If I'm right, then we will need to make changes in display-engine > > functions like composition_compute_stop_pos, composition_reseat_it, > > find_composition, and others, to force the text which has such a face > > attribute to be handed to HarfBuzz for shaping. An alternative is to > > require that use of this face attribute needs special setup of > > composition-function-table, but that is IMO worse because it will slow > > down display of the relevant characters even if they don't have the > > face with this attribute. > > Or maybe it will be enough to make the change in > get_glyph_face_and_encoding, as the etc/TODO item suggests: > > instead of calling the 'encode_char' method of the font driver, we > should invoke the 'shape' method > > But this will only work if the effect of the relevant font features is > per-character, i.e. HarfBuzz doesn't need to see the entire word to > shape the characters according to the requested feature(s). Do you > happen to know if all the features that are relevant for us can be > applied on a character-by-character basis? I was diving into a bit more detail of how text is rendered in Emacs. If I understand correctly the your suggestion is bypassing the composite.el and constructing the glyph string directly in xdisp.c and pass it to all kinds of shape function in different backend directly? I=E2=80=99d need to wrap my head around the display engine first to have mo= re constructive discussion. A bit more direction from you on what to look for will be very helpful. --00000000000097af23063dda0486 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 31, 2025 at 18:35 Eli Zaretskii &l= t;eliz@gnu.org> wr= ote:
> Cc: 79285@debbugs.gnu.org
> Date: Sun, 31 Aug 2025 12:25:32 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> If I'm right, then we will need to make changes in display-engine<= br> > functions like composition_compute_stop_pos, composition_reseat_it, > find_composition, and others, to force the text which has such a face<= br> > attribute to be handed to HarfBuzz for shaping.=C2=A0 An alternative i= s to
> require that use of this face attribute needs special setup of
> composition-function-table, but that is IMO worse because it will slow=
> down display of the relevant characters even if they don't have th= e
> face with this attribute.

Or maybe it will be enough to make the change in
get_glyph_face_and_encoding, as the etc/TODO item suggests:

=C2=A0 instead of calling the 'encode_char' method of the font driv= er, we
=C2=A0 should invoke the 'shape' method

But this will only work if the effect of the relevant font features is
per-character, i.e. HarfBuzz doesn't need to see the entire word to
shape the characters according to the requested feature(s).=C2=A0 Do you happen to know if all the features that are relevant for us can be
applied on a character-by-character basis?

I was = diving into a bit more detail of how text is rendered in Emacs. If I unders= tand correctly the your suggestion is bypassing the composite.el and constr= ucting the glyph string directly in xdisp.c and pass it to all kinds of sha= pe function in different backend directly?

I=E2=80=99d need to wrap my head around the display engi= ne first to have more constructive discussion. A bit more direction from yo= u on what to look for will be very helpful.=C2=A0
--00000000000097af23063dda0486-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 03 08:10:52 2025 Received: (at 79285) by debbugs.gnu.org; 3 Sep 2025 12:10:52 +0000 Received: from localhost ([127.0.0.1]:39089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1utmKC-0005wz-3z for submit@debbugs.gnu.org; Wed, 03 Sep 2025 08:10:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56270) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1utmK9-0005wj-C1 for 79285@debbugs.gnu.org; Wed, 03 Sep 2025 08:10:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1utmK3-0003vV-PF; Wed, 03 Sep 2025 08:10:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/3V1El3EN0nxuvteMVOvEgI3Oj9Lwe3nhKzr+wDi2Pc=; b=j5StVh8sgl3qa0E1Eije GJBtjPsy79J2/Elb8aA0fRUjJJ5TJXoD5fcHzbdruLw+FJjDwzDjLCEGALR5hSnvbtEFnjpTTKMKo 8fAQf9YMTZGWHxUU2ZTgWoq6/3czbaAMjgMyzqyp00Hx6/QOopTusWL1m+L/doKwgOVe0z1OJjQh7 Wza8SQH1AJ2MtkI7UIgq8NqzDf8mEo+j1wpbZM8mmwpaOWkET80K7IqXjyv68dt1YcdYeC2mSVTJu DxwjIWjL/TBRNfHEFP5wRFR93Z91uCtolgK9eMEd3Jj75/FcYZvkzBX8kG/RuT5R/rzVZPK//yC2B hYbwn+o7kyqjDg==; Date: Wed, 03 Sep 2025 15:10:31 +0300 Message-Id: <864itjloso.fsf@gnu.org> From: Eli Zaretskii To: Binbin YE In-Reply-To: (message from Binbin YE on Wed, 3 Sep 2025 08:40:38 +0900) Subject: Re: bug#79285: [Patch] support :font-features in face References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> <86ldmzonar.fsf@gnu.org> <86iki3omuu.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Binbin YE > Date: Wed, 3 Sep 2025 08:40:38 +0900 > Cc: 79285@debbugs.gnu.org > > Or maybe it will be enough to make the change in > get_glyph_face_and_encoding, as the etc/TODO item suggests: > > instead of calling the 'encode_char' method of the font driver, we > should invoke the 'shape' method > > But this will only work if the effect of the relevant font features is > per-character, i.e. HarfBuzz doesn't need to see the entire word to > shape the characters according to the requested feature(s). Do you > happen to know if all the features that are relevant for us can be > applied on a character-by-character basis? > > I was diving into a bit more detail of how text is rendered in Emacs. If I understand correctly the your > suggestion is bypassing the composite.el and constructing the glyph string directly in xdisp.c and pass it to > all kinds of shape function in different backend directly? That's the idea, yes. It would mean to have a function in hbfont.c that is the subset of hbfont_shape, and which accepts a single character (not a Lisp string) and a font, and then constructs the hb_buffer and submits that to hb_shape_full. But please test if this should give good results by simulating it, as follows: . make composition-function-table whose cells for several characters match only that one character, and see how a string of such characters is rendered using a font with relevant OpenType features . then compare that with rendering when composition-function-table has the same rule in the cell of each of those characters, matching any sequence of these characters (as in "[abcdefg]+") If applying stylistic sets by rendering text one character at a time produces different results from rendering them all as a single string, then this idea is not workable, and we will need to use the (slower and more complex) composite.c machinery instead. If the idea does work, then presumably a change in get_glyph_face_and_encoding for characters that have this special face attribute will be all that's needed, perhaps together with some flag in the 'struct it' to make that faster. Details later, when we know whether the idea works or not. > I’d need to wrap my head around the display engine first to have more constructive discussion. A bit more > direction from you on what to look for will be very helpful. See above. If the idea of shaping one character at a time doesn't work, I will then tell you how to study the code which handles character compositions. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 08 11:26:34 2025 Received: (at 79285) by debbugs.gnu.org; 8 Sep 2025 15:26:34 +0000 Received: from localhost ([127.0.0.1]:51727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvdlJ-0001HN-Kd for submit@debbugs.gnu.org; Mon, 08 Sep 2025 11:26:34 -0400 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:52727) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uvdlF-0001Gs-NI for 79285@debbugs.gnu.org; Mon, 08 Sep 2025 11:26:30 -0400 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-3dae49b117bso4000604f8f.1 for <79285@debbugs.gnu.org>; Mon, 08 Sep 2025 08:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757345183; x=1757949983; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Sn3eYJLw+k7WyYI+O+3s+++C2cIcl3noxOVeqKZk/oE=; b=YkK/bWklsglb3dQg8BkC6BBoY7vHPJ0D91EnxZINrnIbeg52MxWIy6jQzT941wm09k zJEnaQH5WdfOIRf9Ywu/1TmpTjioLDl+gmp0nt8oRpAiEUsJWwNDDxzO4BV2iKM1j/Tl r3YjIKpvDHI1Zktv0Ms/AQFAeX+BGDW+iygXsyh1BCMSpB0ZSFwHnM+ZgyvRq7J/rtK2 vbHV7RLsq3gFnEALcKm/WuUgIIRCTVVf1H6kATjOixb3wIYoNiO0nHFxs3mqCquBEffA bObpASIjuf8vAOXcQ+aSkSbsUSYJUNoCW7OTpM6NhWyZFec5L3Q3M7SrgcNYThsD3u8Z LqNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757345183; x=1757949983; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Sn3eYJLw+k7WyYI+O+3s+++C2cIcl3noxOVeqKZk/oE=; b=cKLmbAD8MajJYe4b81UGdFq6g4WsiBIpx0c4XxGWGV+NwV7vZa0ATdYXR5bZz00171 syR4ojowz222PRfzAoQVMidR53A/Zs7NucxjWcUcz7uX+mbbaZDsWwe3E4b459nxyGy7 jyv512H5xvEK6niJexlybb8joC6J/lquj5CuiFwIbm/ApAN7t4JtlryjXYjRcBrGzeQd pMOyzFEAPIj3i3amtgDytTfisdUtTSnv1UHtKJ7pIkhgg4KWdph/jevZemwowupEkZP1 SZrQX6/d8SIGtCBz1iUltJB68pUo2OgDf89QUFTKURKYsu1GHUauhZDhKX6VKQnTbFvY +b/g== X-Gm-Message-State: AOJu0YwNBOXMkt08TSsLkgKUDQeaIl+T0Lb4rGcDfzy5iBNSLEZnms9A SNT4tmIKC73ke5SFaVQswSBYvhnWQ/RJyVeDXaUZ45lQdOxsSDAECvh/r6y9I6SFPuFh5teFxC2 56jvxWoi/FbmgfAIN2pwZhCtIk0DX5MmwtblV X-Gm-Gg: ASbGncvymCG9pgtOXOnQ2AzTdgvJZI6o+9VqpawcC8jiW9fx+d+Oxxj9J+XHnMOaQvH WbEdX06zjr2l3eIqXCxgmWG0KkCbg053zHOVhJHG73fafFPIDvNam5RYYs6ShFt583tp9rCAXgw uJ+mQG537kE3bP5Ar6qBYskXHRhBzPlweZV6COVl7daT+H01CH6SHuE6NVOS/NrqYh/vJcOnBBU RMdb/wR4VPbjz3ofzIbPAwQLxE48yuNWE2H X-Google-Smtp-Source: AGHT+IHvcrOVE/4F3XI/HPQgBCqgRjEH2K7V1hfquGE0iyXDQ2728d/ddACy0QOWNXwpHu/rwH9O6Q9sxl/+87z3VOU= X-Received: by 2002:a5d:5f96:0:b0:3b7:8da6:1bb4 with SMTP id ffacd0b85a97d-3e64cd59b54mr6090085f8f.58.1757345182406; Mon, 08 Sep 2025 08:26:22 -0700 (PDT) MIME-Version: 1.0 References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> <86ldmzonar.fsf@gnu.org> <86iki3omuu.fsf@gnu.org> <864itjloso.fsf@gnu.org> In-Reply-To: <864itjloso.fsf@gnu.org> From: Binbin YE Date: Tue, 9 Sep 2025 00:26:11 +0900 X-Gm-Features: AS18NWB1jiBUoxS_VpY_HrcmM9fHxld51hgEj3wxKVt6RtajCwVsGh0QVzknvrk Message-ID: Subject: Re: bug#79285: [Patch] support :font-features in face To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000585e32063e4bcfd8" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --000000000000585e32063e4bcfd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 3, 2025 at 9:10=E2=80=AFPM Eli Zaretskii wrote: > > That's the idea, yes. It would mean to have a function in hbfont.c > that is the subset of hbfont_shape, and which accepts a single > character (not a Lisp string) and a font, and then constructs the > hb_buffer and submits that to hb_shape_full. > > But please test if this should give good results by simulating it, as > follows: > > . make composition-function-table whose cells for several characters > match only that one character, and see how a string of such > characters is rendered using a font with relevant OpenType features > . then compare that with rendering when composition-function-table > has the same rule in the cell of each of those characters, matching > any sequence of these characters (as in "[abcdefg]+") > > If applying stylistic sets by rendering text one character at a time > produces different results from rendering them all as a single string, > then this idea is not workable, and we will need to use the (slower > and more complex) composite.c machinery instead. > > If the idea does work, then presumably a change in > get_glyph_face_and_encoding for characters that have this special > face attribute will be all that's needed, perhaps together with some > flag in the 'struct it' to make that faster. Details later, when we > know whether the idea works or not. > > I compared the result between #+begin_src elisp (set-char-table-range composition-function-table ?! '(["\\(!=3D=3D\\)" 0 font-shape-gstring])) #+end_src and #+begin_src elisp (set-char-table-range composition-function-table ?! '(["\\(!\\)" 0 font-shape-gstring])) (set-char-table-range composition-function-table ?=3D '(["\\(=3D\\)" 0 font-shape-gstring])) #+end_src They are different, only matching the sequence produces the desired result for multi-character ligatures. I read the hbfont.c code and the hb buffer is cleared every time handling the shaping. I think it makes sense that it should not store the state of the Emacs buffer in hb buffer, and HarfBuzz needs to know the whole sequence to shape according to their document. I did some research on how other programs make use of HarfBuzz. They typically put an entire paragraph or put a line into the shaping function. It is quite an interesting way for Emacs to detect a sequence first and specifically shape that sequence using HarfBuzz. It might be historical reason but it seems a lot more work needs to be done in composite.c or we need to figure out something better. --000000000000585e32063e4bcfd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 3, 2025 at 9:10=E2=80=AF= PM Eli Zaretskii <eliz@gnu.org> w= rote:

That's the idea, yes.=C2=A0 It would mean to have a function in hbfont.= c
that is the subset of hbfont_shape, and which accepts a single
character (not a Lisp string) and a font, and then constructs the
hb_buffer and submits that to hb_shape_full.

But please test if this should give good results by simulating it, as
follows:

=C2=A0. make composition-function-table whose cells for several characters<= br> =C2=A0 =C2=A0match only that one character, and see how a string of such =C2=A0 =C2=A0characters is rendered using a font with relevant OpenType fea= tures
=C2=A0. then compare that with rendering when composition-function-table =C2=A0 =C2=A0has the same rule in the cell of each of those characters, mat= ching
=C2=A0 =C2=A0any sequence of these characters (as in "[abcdefg]+"= )

If applying stylistic sets by rendering text one character at a time
produces different results from rendering them all as a single string,
then this idea is not workable, and we will need to use the (slower
and more complex) composite.c machinery instead.

If the idea does work, then presumably a change in
get_glyph_face_and_encoding for characters that have this special
face attribute will be all that's needed, perhaps together with some flag in the 'struct it' to make that faster.=C2=A0 Details later, w= hen we
know whether the idea works or not.


I co= mpared the result between

#+begin_src elisp
=C2=A0 (set-char-tabl= e-range composition-function-table
=C2=A0 =C2=A0 ?!
=C2=A0 =C2=A0 = 9;(["\\(!=3D=3D\\)" 0 font-shape-gstring]))
#+end_src

a= nd

#+begin_src elisp
=C2=A0 (set-char-table-range composition-fun= ction-table
=C2=A0 =C2=A0 ?!
=C2=A0 =C2=A0 '(["\\(!\\)"= 0 font-shape-gstring]))

=C2=A0 (set-char-table-range composition-fu= nction-table
=C2=A0 =C2=A0 ?=3D
=C2=A0 =C2=A0 '(["\\(=3D\\)&= quot; 0 font-shape-gstring]))
#+end_src

They are different, only = matching the sequence produces the desired result for multi-character ligat= ures.


I read the hbfont.c code and the hb buffer is cleared ever= y time handling the shaping. I think it makes sense that it
should not s= tore the state of the Emacs buffer in hb buffer, and HarfBuzz needs to know= the whole sequence to shape
according to their document.

I did s= ome research on how other programs make use of HarfBuzz. They typically put= an entire paragraph or put a line
into the shaping function. It is quit= e an interesting way for Emacs to detect a sequence first and specifically = shape
that sequence using HarfBuzz. It might be historical reason but it= seems a lot more work needs to be done in composite.c
or we need to fig= ure out something better.
=C2=A0
--000000000000585e32063e4bcfd8-- From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 08 12:34:40 2025 Received: (at 79285) by debbugs.gnu.org; 8 Sep 2025 16:34:40 +0000 Received: from localhost ([127.0.0.1]:52003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvepD-00055W-Mf for submit@debbugs.gnu.org; Mon, 08 Sep 2025 12:34:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41174) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvep4-000558-CC for 79285@debbugs.gnu.org; Mon, 08 Sep 2025 12:34:33 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uveoy-0006Wv-OD; Mon, 08 Sep 2025 12:34:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=56WDiPI/MsCXe7ukrUmbsMzSuwaYgxyzwCZp97t5Ptc=; b=hxlQIGS6mYVVcD39dF1e MzZJCjwSzDpz1PUsgM4ehtxYpuRtboBVw6MmlKLjpwrxosaAwDQz7sWzxWgti7ifDJeYI6mGG5Hk9 U+qWbtSUtzVU0j0+NAaK/LIo0vq76JVx/H+VeeItmspAsaUutFg2L2q2Ms7aNujFDRW95eKpOQto8 a7RcENXwOob7lRLwOIu6jbkKuJ4sW7eyh6bBHDHbi63U3Rf6G1wH8/b8zn4bjFEpv/4G4hSSOUWw+ uqy6ItVOI2swIe61yjlp23gz9Of145IZiEt0NJ7AIk0jDPBf3U/vuQRGml5ZEq+4ZH3MC/Mj4CHIo syltkoWVRMvmiA==; Date: Mon, 08 Sep 2025 19:33:53 +0300 Message-Id: <86ms74dhu6.fsf@gnu.org> From: Eli Zaretskii To: Binbin YE In-Reply-To: (message from Binbin YE on Tue, 9 Sep 2025 00:26:11 +0900) Subject: Re: bug#79285: [Patch] support :font-features in face References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> <86ldmzonar.fsf@gnu.org> <86iki3omuu.fsf@gnu.org> <864itjloso.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Binbin YE > Date: Tue, 9 Sep 2025 00:26:11 +0900 > Cc: 79285@debbugs.gnu.org > > On Wed, Sep 3, 2025 at 9:10 PM Eli Zaretskii wrote: > > That's the idea, yes. It would mean to have a function in hbfont.c > that is the subset of hbfont_shape, and which accepts a single > character (not a Lisp string) and a font, and then constructs the > hb_buffer and submits that to hb_shape_full. > > But please test if this should give good results by simulating it, as > follows: > > . make composition-function-table whose cells for several characters > match only that one character, and see how a string of such > characters is rendered using a font with relevant OpenType features > . then compare that with rendering when composition-function-table > has the same rule in the cell of each of those characters, matching > any sequence of these characters (as in "[abcdefg]+") > > If applying stylistic sets by rendering text one character at a time > produces different results from rendering them all as a single string, > then this idea is not workable, and we will need to use the (slower > and more complex) composite.c machinery instead. > > If the idea does work, then presumably a change in > get_glyph_face_and_encoding for characters that have this special > face attribute will be all that's needed, perhaps together with some > flag in the 'struct it' to make that faster. Details later, when we > know whether the idea works or not. > > I compared the result between > > #+begin_src elisp > (set-char-table-range composition-function-table > ?! > '(["\\(!==\\)" 0 font-shape-gstring])) > #+end_src > > and > > #+begin_src elisp > (set-char-table-range composition-function-table > ?! > '(["\\(!\\)" 0 font-shape-gstring])) > > (set-char-table-range composition-function-table > ?= > '(["\\(=\\)" 0 font-shape-gstring])) > #+end_src > > They are different, only matching the sequence produces the desired result for multi-character ligatures. > > I read the hbfont.c code and the hb buffer is cleared every time > handling the shaping. I think it makes sense that it should not > store the state of the Emacs buffer in hb buffer, and HarfBuzz needs > to know the whole sequence to shape according to their document. OK, thanks. This is what I suspected. Unfortunately, it means we need to use the full machinery of character composition to support this face attribute on arbitrary text: the entire chunk of text which has this attribute, or at least its individual wortds, will need to be passed through HarfBuzz en-masse. It also means using this will probably slow down redisplay of the relevant text parts, unless we find a way of avoiding some of the slow code parts. Let me think about the best way of doing this. Meanwhile, I invite you to read the large commentary at the beginning of xdisp.c, which mentions character composition, and also take at least a cursory look at the "automatic compositions" parts of composite.c, which is where most of the code that deals with character compositions lives. > I did some research on how other programs make use of HarfBuzz. They > typically put an entire paragraph or put a line into the shaping > function. It is quite an interesting way for Emacs to detect a > sequence first and specifically shape that sequence using > HarfBuzz. It might be historical reason but it seems a lot more work > needs to be done in composite.c or we need to figure out something > better. It's not just a historical accident. The Emacs display engine is special, in that it examines text one character (or one grapheme cluster, in case of compositions) at a time, and makes all the layout decisions on the fly. So passing large chunks of text to a shaping engine, like other programs do, is out of the question, as long as we keep this basic design of the Emacs display. The reason why Emacs tries to avoid using the shaper, unless composition-function-table tells us we must, is that the implementation of shaping and composition in Emacs is exposed to Lisp and uses Lisp code for some of its workings, and thus is slow. Emacs is unique in this: no other program allows the user to affect character composition and shaping by a simple change of a character-indexed table, while the session keeps running. This gives Lisp programs and users an unprecedented freedom of affecting how stuff is displayed, but it comes at a price. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 09 11:52:04 2025 Received: (at 79285) by debbugs.gnu.org; 9 Sep 2025 15:52:05 +0000 Received: from localhost ([127.0.0.1]:59949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uw0dY-0007oQ-0r for submit@debbugs.gnu.org; Tue, 09 Sep 2025 11:52:04 -0400 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:48505) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uw0dU-0007ns-Bq for 79285@debbugs.gnu.org; Tue, 09 Sep 2025 11:52:01 -0400 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-45deccb2c1eso9633195e9.1 for <79285@debbugs.gnu.org>; Tue, 09 Sep 2025 08:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757433114; x=1758037914; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+3U+3bankvXmg9fbq4tYU4vGSkI0MxhB1v6S9fFhHsw=; b=aVox00NUI6INlwLJBo4YZR+R2hPAQO+SR2SJ9YJQbYSNmcbbVWHI6j8aK2taHlWR9D vV36bADskXAUua41jiLV4VP29YsVwkDCRnp1vN2vO/MMnliKwRl9t+uwbq4hg+1WgbFr g5OCOv56P+8FT+X/DX85SVJAKoZIwSImyRKbj3huQvc6osFn++G4rA4aXkfaDXa8MHo/ LuKlbegdIejrp7nJOGLFyhJe3bp6E3YoumxWN1DPFzyXIYnlCq6gW21z1Rfl9UiMbTi/ XvBtpiMgFpxgu0l8WWnHEyvTXmIYJ3d+Gzc2px8QjqCTIKmecsE5J9DoTp9CdVFeKkfo Spew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757433114; x=1758037914; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+3U+3bankvXmg9fbq4tYU4vGSkI0MxhB1v6S9fFhHsw=; b=FlMcEnmUny2wi+R59lJujdHnO8Lcctn3iq27/r4WhEDIPHREfLwh1yBA2vZnotWuNk vUC90cdLaPq2ccURgy0wcpMd1HpUU08NrgQWb6kIQpDytaM/SgsZWLnJuxehD+R6hBjI bfMLpCt8z8yX2UVE+dc3Q2thJ44zobejZ1+wIKDFFdmT23t4tAEuBBC270hifd+c+T6E nTb4YxYsT32L3MS5Qw8o0nGSj7fbpnuFHp6GOwk/YXT3Cx+3uBLk40dO0LcfQmLosuLw msZQ3zXPlh2gsNd1O5Duxg7F7D4c/Bl8q2VoZSAhtlzBRrMQzUBRLpV66tgU0S/GqT72 hG4A== X-Gm-Message-State: AOJu0Ywt/KKxY5rDCLOrtIVbyTxRnrNJZDif9iKM5bnFoO4iHIjx6ugs XRmiTGX1ovlk7UIeBZ2XHFDAPNAr+/nJ2zi04kGWrqKnF0EuGjIKpvi80327/d/boeaZ78xj6OR 1lJTq98zWKafoyu1WvcxR1qX4V/m+3rWARQ== X-Gm-Gg: ASbGncvMSmC7IK7XcOanQM4lVUmcjHFwncQ+n/toHn2aonWboP3YKgfZaA9XS8Ez9T0 +xCBD1Wm/fleGkA3iFZ7hB7kb1Gs7GBA34aZHFHFdDEovvIP953MjEGhZ9YZi8FGZGloyy6x/jf vAGfSICSgIvRgHa4xVasL9QbwG/6yUAnxq3yFVbk4z6a6DagIXZxdV6DLsRKqqqd2jyI65wUlIJ IsDDwc1DUYaN0F918bo6deqAOkEIFvymbtIrZ2lkLHgpO4= X-Google-Smtp-Source: AGHT+IERzL740J019vSdc943UdTREwtLfRa4oFSpuYFIjBb1C3zjqgh1hKjwtS5CMFMa9wRbbhuU7JWKNIisFYHzzOg= X-Received: by 2002:a05:600c:1f91:b0:45d:d5df:ab2d with SMTP id 5b1f17b1804b1-45dddeef92cmr105652305e9.26.1757433113583; Tue, 09 Sep 2025 08:51:53 -0700 (PDT) MIME-Version: 1.0 References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> <86ldmzonar.fsf@gnu.org> <86iki3omuu.fsf@gnu.org> <864itjloso.fsf@gnu.org> <86ms74dhu6.fsf@gnu.org> In-Reply-To: <86ms74dhu6.fsf@gnu.org> From: Binbin YE Date: Wed, 10 Sep 2025 00:51:42 +0900 X-Gm-Features: AS18NWCegEmXtCVjoaZEoOHOhsY6qNqumVrXBSMNWUAuwwulSJLxjlTPxeImrSg Message-ID: Subject: Re: bug#79285: [Patch] support :font-features in face To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000073a4b1063e604813" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --00000000000073a4b1063e604813 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 9, 2025 at 1:34 Eli Zaretskii wrote: > > It also means using this will > probably slow down redisplay of the relevant text parts, unless we > find a way of avoiding some of the slow code parts. > > Let me think about the best way of doing this. Meanwhile, I invite > you to read the large commentary at the beginning of xdisp.c, which > mentions character composition, and also take at least a cursory look > at the "automatic compositions" parts of composite.c, which is where > most of the code that deals with character compositions lives. Thanks for pointing out the direction, I might need to digest all that with extra time. I=E2=80=99ll see if I can also help improving the commentary if= there=E2=80=99s a chance. > The reason why Emacs tries to avoid using the shaper, unless > composition-function-table tells us we must, is that the > implementation of shaping and composition in Emacs is exposed to Lisp > and uses Lisp code for some of its workings, and thus is slow. Emacs > is unique in this: no other program allows the user to affect > character composition and shaping by a simple change of a > character-indexed table, while the session keeps running. This gives > Lisp programs and users an unprecedented freedom of affecting how > stuff is displayed, but it comes at a price. It is extremely powerful design, maybe there is a chance that the shaping engine can serve as additional source of information passing to the composition =E2=80=94 so that we can take advantage of both. I=E2=80=99m gu= essing, I probably will realize how unpractical this idea is, later. --00000000000073a4b1063e604813 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 9, 2025 at 1:34 Eli Zaretsk= ii <eliz@gnu.org> wrote:

=C2=A0It also means using this will
probably slow down redisplay of the relevant text parts, unless we
find a way of avoiding some of the slow code parts.

Let me think about the best way of doing this.=C2=A0 Meanwhile, I invite you to read the large commentary at the beginning of xdisp.c, which
mentions character composition, and also take at least a cursory look
at the "automatic compositions" parts of composite.c, which is wh= ere
most of the code that deals with character compositions lives.
=

Thanks for pointing out the d= irection, I might need to digest all that with extra time. I=E2=80=99ll see= if I can also help improving the commentary if there=E2=80=99s a chance.= =C2=A0



The reason why Emacs tries to avoid using the sh= aper, unless
composition-function-table tells us we must, is that the
implementation of shaping and composition in Emacs is exposed to Lisp
and uses Lisp code for some of its workings, and thus is slow.=C2=A0 Emacs<= br> is unique in this: no other program allows the user to affect
character composition and shaping by a simple change of a
character-indexed table, while the session keeps running.=C2=A0 This gives<= br> Lisp programs and users an unprecedented freedom of affecting how
stuff is displayed, but it comes at a price.

It is extremely powerful design, ma= ybe there is a chance that the shaping engine can serve as additional sourc= e of information passing to the composition =E2=80=94 so that we can take a= dvantage of both. I=E2=80=99m guessing, I probably will realize how unpract= ical this idea is, later.=C2=A0
--00000000000073a4b1063e604813-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 09 12:20:49 2025 Received: (at 79285) by debbugs.gnu.org; 9 Sep 2025 16:20:49 +0000 Received: from localhost ([127.0.0.1]:60071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uw15M-0000yT-Mk for submit@debbugs.gnu.org; Tue, 09 Sep 2025 12:20:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54056) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uw15H-0000yB-Pn for 79285@debbugs.gnu.org; Tue, 09 Sep 2025 12:20:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uw15B-0002t7-OL; Tue, 09 Sep 2025 12:20:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=hAE7sno01YI9md3mGu88uDewYWH1A8YNaj05AfIw61Q=; b=QkVaDqiay6TwlFxFkM++ 5unttiZCjffI/MKRgvOSDhKReWLlbzS6/r6Jn2x83P7JqhUJfKq5AaSe6lvJG0CkPO3AXo9LpR/jT cIieqF2m9qU3ifIbrR7qEn+9zt7k0DCuFbeJAsADCWRoW4cTTgEsYA3i0pXa392FALoDaWDiPGX+j xj0GQAiMPSagM1ghv9BKBdNXSRWNKuWSmO1i8RYBBgjHCn/11kKABV2xSnsVPKu6hK5vcXYUTHN3D qwor/BntLG2apYMTlrvYVn0lfRGhXvRM7KdfVEV8Rg2AFOlmBVpEbf86GQTQqfc5K6OZ88zDTFcP3 hp/Q9+eoDiddlg==; Date: Tue, 09 Sep 2025 19:20:33 +0300 Message-Id: <867by7d2cu.fsf@gnu.org> From: Eli Zaretskii To: Binbin YE In-Reply-To: (message from Binbin YE on Wed, 10 Sep 2025 00:51:42 +0900) Subject: Re: bug#79285: [Patch] support :font-features in face References: <861pp2b3qz.fsf@gnu.org> <86frdh8dvh.fsf@gnu.org> <86y0r4rng4.fsf@gnu.org> <86ms7foo3h.fsf@gnu.org> <86ldmzonar.fsf@gnu.org> <86iki3omuu.fsf@gnu.org> <864itjloso.fsf@gnu.org> <86ms74dhu6.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79285 Cc: 79285@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Binbin YE > Date: Wed, 10 Sep 2025 00:51:42 +0900 > Cc: 79285@debbugs.gnu.org > > The reason why Emacs tries to avoid using the shaper, unless > composition-function-table tells us we must, is that the > implementation of shaping and composition in Emacs is exposed to Lisp > and uses Lisp code for some of its workings, and thus is slow. Emacs > is unique in this: no other program allows the user to affect > character composition and shaping by a simple change of a > character-indexed table, while the session keeps running. This gives > Lisp programs and users an unprecedented freedom of affecting how > stuff is displayed, but it comes at a price. > > It is extremely powerful design, maybe there is a chance that the shaping engine can serve as additional > source of information passing to the composition — so that we can take advantage of both. I’m guessing, I > probably will realize how unpractical this idea is, later. It should be possible to bypass the current flow of processing. But it will not be easy, and will require additional non-trivial effort. Character composition currently works by passing to the shaper a chunk of buffer text (one or more characters), receiving a series of font glyphs for those characters from the shaper, and then laying out these glyphs one by one. The workhorse of the latter step is next_element_from_composition; as long as we use that in the display engine, restructuring the code that fills up 'struct composition_it' which stores the information about the composed characters will basically need to duplicate a lot of what we already do anyway. So I think for starters we should reuse as much code of character composition as possible, and leave optimizations (if needed) for later. The minimum that is needed is to replace the code which uses composition rules stored in composition-function-table to determine the sequence of characters to be passed to HarfBuzz by something similar which determines that sequence by looking for stretches of text that have the face property with this new attribute. I'd suggest to do this minimum first, and see how well/fast that works.