From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Steve Molitor Newsgroups: gmane.emacs.devel Subject: Re: How to use "smart kerning" font features in Emacs using composition-function-table Date: Sun, 26 Nov 2023 13:49:13 -0600 Message-ID: References: <83ttp89zbk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5615"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 26 20:50:19 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r7L91-0001Im-II for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Nov 2023 20:50:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7L8G-0005gm-3n; Sun, 26 Nov 2023 14:49:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r7L8C-0005gM-5o for emacs-devel@gnu.org; Sun, 26 Nov 2023 14:49:28 -0500 Original-Received: from mail-vs1-xe2e.google.com ([2607:f8b0:4864:20::e2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r7L8A-0007qi-F4; Sun, 26 Nov 2023 14:49:27 -0500 Original-Received: by mail-vs1-xe2e.google.com with SMTP id ada2fe7eead31-462f7ba24d1so81803137.1; Sun, 26 Nov 2023 11:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701028164; x=1701632964; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9VcBQYipszZG316cdVpayjQ1x/zW1gUnwHcydVac7Rc=; b=BjaJHr50DJDA+sadyAYo+U/FUUZPSJ7Y6odzlPQhCyXt0bTlSWEuDzIevUah563nIw LK1A27K/5T3mwM9CpqGoKHkc/n+57TK7DwsiWfKNj1zALoHWk36Qn7OEBKroLHOdl7mg L7Op2GIVo0Orno/9OxPpGbG3LF9Eyn7NgDWa6F9DBUPbtcWAdr90evxcWR/sp4e3PPpU opeDgHgf2/Wq40UhjHbOO0RwSrj2VcOjDydtYBV0AfGzpgrHRGU5Zz4XxjCUu1xd5ZA9 IP5PaxuXj99YH1gkikCOP2zDMk8h6/OSRRVNB6LDOZq+jM5Dt3mXRKoS4WVKSd/8e3SD MSfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701028164; x=1701632964; h=content-transfer-encoding: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=9VcBQYipszZG316cdVpayjQ1x/zW1gUnwHcydVac7Rc=; b=OEkJZNtx4Tld1l0jHPlnOYbWw4mxnFuOSWadso8pxyJKziMN2AKLmJhZczS6Dg9eec WlYODzoEsaXF1REnNgTtXC4scs8N+yANZbNSySiziEwDIJZjvB5HQW12Jv4eMOpkvHo7 PY+Vrj83dH0j77Abjiz8Zz6iQrxagGYaK6SRNiX4hGm3mnr3voBs08BVxU0txT1FS/tZ v5iFZnsaXo8Z9P/x41DQeFmC/juqeBp/yigVATfWl0LbCea+kbwEOtFoEhKYf+5uWRz+ GGtjT+MjFSVFarJznyHIHqbLymcTGRqDvjBFuogoxGXwUppIgrbBc7yBhvM3v7II42Jk 2gkA== X-Gm-Message-State: AOJu0YwDWWpqeoRSqG0V+zcneJy/qxrEOJ0J23tQJn1p/BI8BNtA3MOd jHbm6is/wWaHbGABVCqE4fnrUk0fYtHQwvlrMj031vu6Scg= X-Google-Smtp-Source: AGHT+IGpCx8uSADXCzMcBIC2QqYh50AgcA78e9u+zLdfb2LZ+HU9Z/cwGT3kTlwqKtPSYgH5dC8DVn9BZEOYfAb/o8s= X-Received: by 2002:a67:f4c5:0:b0:462:fab3:6908 with SMTP id s5-20020a67f4c5000000b00462fab36908mr775125vsn.13.1701028164456; Sun, 26 Nov 2023 11:49:24 -0800 (PST) In-Reply-To: <83ttp89zbk.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::e2e; envelope-from=stevemolitor@gmail.com; helo=mail-vs1-xe2e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:313247 Archived-At: Thanks for the clear response! It makes perfect sense and confirms what I was seeing. > So to use kerning like the one you describe, I think you must have a > rule that matches any sequence of ASCII letters, not just the triplets > where the kerning is supposed to happen. Thanks. This indeed does work (matching against the characters Commit Mono applies its kerning effect to): (set-char-table-range composition-function-table t `(["[ ,-.:;A-Z_a-z]+" 0 font-shape-gstring])) I see the "smart kerning" effect as expected. So far after a quick test performance seems ok but we'll see. I did notice that if I changed the PREV-CHARS value from 0 to 1 I would get seconds-long redisplay delays! > But -- and it's a very significant "but" -- displaying text via the > shaping engine is expensive -- it involves calls from the display > engine to Lisp, which then calls back into C. So rules that match any > sequence of ASCII letters will slow down redisplay of almost any text > in Emacs. This is why Emacs by default doesn't use the text-shaping > engine except for scripts that cannot be displayed without non-trivial > character compositions. Which scripts use the text-shaping engine? Is it possible to optionally use the text-shaping engine and bypass Lisp in say the "English" script? I understand that certain features like mode-specific ligatures might stop working, but it could be a nice option. Thanks again, Steve On Sun, Nov 26, 2023 at 11:53=E2=80=AFAM Eli Zaretskii wrote= : > > > From: Steve Molitor > > Date: Sun, 26 Nov 2023 09:48:34 -0600 > > > > Using composition-function-table, is it possible to have the font > > render a glyph for each character, based on the previous and following > > character, in a moving window? For example, the rendering of character > > 1 will depend on what characters 0 and 2 are, character 2 depends on 1 > > and 3, etc. > > Not really, see below. > > > I decided to see if I could get it to work just for the "Commit" > > string by adding the following elisp: > > > > (set-char-table-range composition-function-table ?o > > '(["Com" 1 font-shape-gstring])) > > (set-char-table-range composition-function-table ?m > > '(["mmi" 1 font-shape-gstring])) > > > > My thinking was if the current character is "o", preceded by a "C" and > > followed by an "m", let the font replace the "o". Next, if the current > > character is an "m" preceded by an "m" and followed by an "i", let the > > font render the middle "m". If that worked I was going to do something > > more generic. > > > > It half worked. If I type "Com" it works as expected - the "o" shifts > > slightly to the left when I type the "m": > > > > https://cdn.zappy.app/f1506de028c470750428ebf984dfbe41.gif > > > > If I type "mmi" on a separate line it also works - the second "m" > > shifts to the left when I type the "i": > > > > https://cdn.zappy.app/6a1a90013d102bfb494fc7d1de54ca32.gif > > > > However, if I type "Commit", the "Com" works (the "o" shifts"), but > > nothing happens when I type "mit". If I use three m's and type > > "Commmit" I do see the effect on the final "mit": > > > > https://cdn.zappy.app/e98141872235a25bf52f6e332b610d7b.gif > > > > It seems I've created 3 character, non-overlapping gifs, which is not > > the effect I want. > > > > For comparison, here it is in VSCode, typing "Commit". Various > > shifting effects happen as expected: > > > > https://cdn.zappy.app/8f3bc49a174c4673747c402f7b39d54b.gif > > > > I think when Emacs matches the 3 character regexp in the composition > > function table, it assumes that those 3 characters constitute a single > > glyph or ligature. That makes sense for ligatures, but it's not what I > > want here. I want a "moving window" where the glyph for each character > > depends on the previous and following character. > > > > Is this possible to do in Emacs currently? > > No, it's not possible. When characters are composed successfully > (i.e., they match some rule in composition-function-table, and the > font support their composition), Emacs will not examine them again for > other rules. It will restart examining from the first character > _after_ those which matched. > > So to use kerning like the one you describe, I think you must have a > rule that matches any sequence of ASCII letters, not just the triplets > where the kerning is supposed to happen. Which means that every word > using ASCII characters will be passed to the text-shaping engine. > Then the shaping engine will decide on its own where to use the > kerning, and I think you should get what you want, appearance-wise. > > But -- and it's a very significant "but" -- displaying text via the > shaping engine is expensive -- it involves calls from the display > engine to Lisp, which then calls back into C. So rules that match any > sequence of ASCII letters will slow down redisplay of almost any text > in Emacs. This is why Emacs by default doesn't use the text-shaping > engine except for scripts that cannot be displayed without non-trivial > character compositions. So if you go the above way, don't be > surprised if you see slower redisplay.