From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Ligatures (was: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY)) Date: Thu, 21 May 2020 10:01:03 +0000 Message-ID: References: <20200517165953.000044d2@web.de> <83lflqblp0.fsf@gnu.org> <83ftbybio3.fsf@gnu.org> <83zha69xs2.fsf@gnu.org> <83367x9qeq.fsf@gnu.org> <0ccae2a4-533b-d15c-2884-c2f00b067776@gmail.com> <83wo5987mk.fsf@gnu.org> <99d4beed-88ae-b5cd-3ecb-a44325c8a1dc@gmail.com> <20200518215908.GA57594@breton.holly.idiocy.org> <83mu6481v3.fsf@gnu.org> <75a90563-51b4-d3b8-4832-fc0e2542af0d@gmail.com> <83blmi7hys.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="ciao.gmane.io:159.69.161.202"; logging-data="70528"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 21 12:02:52 2020 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 1jbi2O-000I9S-32 for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 12:02:52 +0200 Original-Received: from localhost ([::1]:38372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbi2N-0005ev-0x for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 06:02:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32866) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbi1I-0004Uk-4h for emacs-devel@gnu.org; Thu, 21 May 2020 06:01:44 -0400 Original-Received: from mail-oi1-x244.google.com ([2607:f8b0:4864:20::244]:40222) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbi1G-0006bH-Iz; Thu, 21 May 2020 06:01:43 -0400 Original-Received: by mail-oi1-x244.google.com with SMTP id v128so5718764oia.7; Thu, 21 May 2020 03:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SYo0zzwwdD0LRhBvivgV+O8QpYGulJiXh1AUVzthBq8=; b=Q7lzICCIoVmbu7QGcvXh/Fe7CHYANtPHVl3/x+2lhmPNlbMsdkueEMq3D7scbqk8F6 prTyHx0ioTSHO1FVG0EfKdt+dSXwSNxqgm3O9jlxgnT8qaO+mk1c3stOocN5Gattythi Hn33fODPL6kRSsrpZjG5S+IFGBCD8LcZ0cZst2RfRcCLL3uBOs5Z7Vca/b8PmwRQWrTu LYcSKGUEEWwbuUaNGKbKezGP2vnN+oWNgqLoLfiFP8bCTjxr5yBunnU46hA1MqMzYQSu UIj+L+HJWUPNomkVtW6nhc7La8GdaiFgQY/CYhxS3aJBtL7VH9B2Y3l3aWqsH1kOWyCO uqoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SYo0zzwwdD0LRhBvivgV+O8QpYGulJiXh1AUVzthBq8=; b=hLAE7EUEia9I53TCVSNG1af/StSJiJQ63FAKhXpTcsBr4ICFhXOaiBbQhJQvciNHFX YgVMO+In+Nmtd00uLghSFSejD1qZ8wYRdP3rzhbvfsLXPN9+OZrLaQ/vMpg5vIItCTI5 LZ6yPQWatvJXZQjYcCINPZEJ8LpkxdNnd5+JqGxqbzmvJrY7VX1QD+Xk1xND+KBkNhuS d2xXpFdE6iDPVUkaouCVFhk8wQvEW2K0/elNaNL34RN8+BgotMmvMN6tibyMXoR3rMA/ gQ6OOtyvlmLREmSUbKM2PcuS2puODdeFxY1KagVkxy1qzRatNRoxkDoDf6ayBfNWP6mH M4Cg== X-Gm-Message-State: AOAM532AaYZcV4bD2+ZDPeSUzqvUkfytrE49LOfENe3l3KCYU+MtMS7T i2MQqBx7tif1lmGn8j7OdRVw4/whk+wRVBU/vpVxz3PV X-Google-Smtp-Source: ABdhPJxXMgW8OZgt4upm/eOV8tPt9wU1oB3m/4qFgDk6+EV23NOcZTurxwY7Q9GibxM8+aUWCPVpM7M74AyV8jJJFUs= X-Received: by 2002:aca:ea05:: with SMTP id i5mr6445592oih.44.1590055300341; Thu, 21 May 2020 03:01:40 -0700 (PDT) In-Reply-To: <83blmi7hys.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::244; envelope-from=pipcet@gmail.com; helo=mail-oi1-x244.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:251162 Archived-At: Hi, Eli, On Wed, May 20, 2020 at 3:31 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Tue, 19 May 2020 21:43:49 +0000 > > Cc: Eli Zaretskii , Alan Third , emacs-d= evel@gnu.org > > > > And I'm afraid the difference is much more obvious with box cursors > > than it is with carets. I'm attaching a screenshot of a patched Emacs > > displaying "ffi", with point on the second f, in the "Linux Libertine > > Display O" font (using approximately equal slices). > > > > I think this is a bit of a worst-case scenario, a three-letter > > ligature in a font using ligatures and overhangs very > > enthusiastically. It might be okay for other fonts. > > I'm not sure this is the worst case. It might be the worst case if we > are talking about ligatures that involve only ASCII characters, and > don't involve symbols like =3D=3D> that gets converted to =E2=87=92. But= in > general, there are worse cases, like a=CC=81 (two codepoints). And for > kicks see the Khmer hello in etc/HELLO, where you can find 4 > codepoints that produce a grapheme cluster made of 3 glyphs. You're correct: I'm simply not dealing with Khmer or composed characters (which are different from ligatures, of course) in the patch, and I'm not certain how to deal with them in theory, either. > If we only want this feature for ASCII ligatures, then it sounds like > a limitation to me (and frankly, somewhat unclean as features go), Not "only for ASCII ligatures", but not "any conceivable combination of codepoints into glyphs" either. Just those supported by the font and Harfbuzz. > but > if we really want this only for these limited cases, we will need to > somehow indicate to the display engine which ligatures are to be > handled like this and which aren't. Well, we now know that fonts can provide information about how a ligature is to be split into one-dimensional slices; I filed a pull request against Harfbuzz (since merged) that would actually make the corresponding API work, at least for the "Libertinus" font family. Of course that means that Emacs behavior would depend on the font tables in ways it currently doesn't. That's a problem. > > My remaining idea is to stretch characters so we can break up a > > ligature without changing its total width. I'm not sure how to do > > that, though. > > I don't think I understand what you'd like to do. Can you elaborate? My idea was to display "ffi" with the point on the second f by condensing an "f" glyph to cover the middle third of the "ffi" glyph. However, I might have been too critical of how good the simple solution deals with this case. > > (I'm also attaching the patch, for the morbidly curious; it isn't > > clean, readable, or finished in any way, and contains at least one > > obvious bug. It's just good enough to produce the screenshot, and > > maybe it can serve as a hint as to which files need changing for > > ligatures to work; but such changes would have to be done very > > differently from the patch.). > > Right, the actual implementation will have to be different. In > particular, I think that if ligatures will use automatic compositions, > the information you need is already stored in the composition table > and reachable from the glyph string, so you don't need to invoke the > shaper again. Well, I'm sorry to bring up a different (though somewhat related issue), but kerning is also an issue: we need a shaper to get that right, not just a composition table, right? > I see you implemented this for static compositions, which are > semi-obsolete. I'm sorry, I'm afraid I don't understand. This should handle any composition the shaper does, and only those, but slices up everything horizontally by default. > Also, I don't see the code which moves point inside > the ligature; Emacs will not allow doing that by default. In > particular, how did you tell the display code to show the cursor on > the middle 'f', not on the first one? Did I miss something? I produce three "struct glyph"s for "ffi": each has width one third of the actual font glyph, and stores, in convoluted form, information about which slice of the font glyph is to be actually drawn. > And finally, you said you intended to do this via row->clip, but this > patch does something very different. What changed your mind? I was surprised this no longer seemed to be strictly necessary: as far as the display code is concerned, we're dealing with three separate glyphs with overhang areas, and those are already handled by the cursor-drawing code. Clipping is still needed: to deal with double-drawing issues, and to deal with such crimes as making part of a ligature have a different foreground color. I'm sorry it's not particularly obvious from the patch, but the approach I took yesterday is this: 1. every struct glyph has a "context", which specifies the character for the struct glyph and some surrounding text. 2. every struct glyph is converted to a slice of (currently) a single font glyph, by sending the context through the shaper and cutting out the relevant bits 3. struct glyphs are displayed one by one Problems: 1. ligatures can cross line boundaries 2. the context has to be updated, and trigger redisplay of the struct glyph 3. clipping is necessary 4. there are N clipped drawing operations for a single glyph covering N struct glyphs. 5. corner cases can have ambiguous context: for example, a string of many "f"s would be paired into "ff" glyphs, and simply cutting off the context after a certain number of characters might result in the wrong pairing On the other hand, it deals with kerning as well as ligatures. And other problems (right now, we call the shaper on 64 characters for every character we actually display, which makes things noticeably slow) are fixable. Overall, I'd like to think more about alternative approaches to the "context string" one before implementing anything. How would that work for kerning, in particular?