From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY) Date: Sun, 17 May 2020 20:00:44 +0300 Message-ID: <83ftbybio3.fsf@gnu.org> References: <20200517124125.000013a4@web.de> <97C7EAB7-10AB-4702-ABC8-EB6C1C50ABDB@gnu.org> <20200517165953.000044d2@web.de> <83lflqblp0.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="77714"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, julius.pfrommer@web.de To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 17 19:02:04 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 1jaMfs-000K6W-3v for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 19:02:04 +0200 Original-Received: from localhost ([::1]:49098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaMfr-00075N-2F for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 13:02:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaMen-0005vS-B6 for emacs-devel@gnu.org; Sun, 17 May 2020 13:00:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34289) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaMem-0007pF-9g; Sun, 17 May 2020 13:00:56 -0400 Original-Received: from [176.228.60.248] (port=4565 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jaMei-0005Vq-MY; Sun, 17 May 2020 13:00:55 -0400 In-Reply-To: (message from Pip Cet on Sun, 17 May 2020 16:28:30 +0000) 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:250622 Archived-At: > From: Pip Cet > Date: Sun, 17 May 2020 16:28:30 +0000 > Cc: Julius Pfrommer , emacs-devel@gnu.org > > On Sun, May 17, 2020 at 3:56 PM Eli Zaretskii wrote: > > > Date: Sun, 17 May 2020 16:59:53 +0200 > > > From: Julius Pfrommer > > > Cc: emacs-devel@gnu.org > > Next, please be aware that we already made the decision to use > > HarfBuzz as our main text-shaping engine. > > That's a decision that, having just played with HarfBuzz, I find > puzzling. It appears to have no practical support for treating > ligatures as anything but monolithic glyphs: is there a documented way > of getting HarfBuzz to tell you which part of the "ffi" ligature is > the middle "f"? You are accusing HarfBuzz of crimes it didn't commit ;-) What you see is not produced by HarfBuzz, it's produced by Emacs. HarfBuzz (and any other text-shaping engine we ever used) has a very simple job: Emacs hands it a string of codepoints, and HarfBuzz returns a series of font glyphs to be used to display that string. That's all. All the rest is the Emacs display engine. And yes, the current design is that a ligature (like any other "grapheme cluster" produced by character composition) is a single "display element": you move across all of it with a single C-f/C-b. The only exception to this rule is that we allow DEL (but not C-d or Delete) to erase individual codepoints going back from the end of the grapheme cluster -- to facilitate editing ligatures and other composed characters. This is the minimum "editing" capability that the user must have, and I don't think I've heard complaints that it wasn't enough. But if required, we could easily add special forward and backward movements that could "enter" the composed character, we just need to figure out how to display the result in order to give the user some visual feedback. (Without visual feedback, I think you can have it today if you customize global-disable-point-adjustment to a non-nil value.) In any case, the question "which part of the ligature corresponds to some codepoint" is meaningless in the context of ligation and complex text shaping: a sequence of N codepoints in general produces M font glyphs, where M can be smaller, equal, or greater than N. The relation between the N codepoints and M glyphs is many-to-many. > I'm not sure PangoCairo does better, but whatever Libreoffice uses > appears to get the job done What job is that? > (This is assuming we want kerning, ligatures, and subpixel rendering > for English text. "Real" text shaping, composition, reordrant glyphs, > and bidi concerns are something that I can't really comment on, beyond > admitting that, of course, supporting the world's major languages at > all is more important than supporting English with the typographic > finesse we currently lack). The truth is that "we" the Emacs project don't want to know anything about ligatures, we want to delegate that job to the shaper. That's the shaper's job, and HarfBuzz does its job very well and stays on top of the relevant technological advances. > Years ago, I ran a WebAssembly version of Emacs in a web browser. > (Back then, I used a terminal emulator written in JavaScript.) I'd > certainly like to do that again some day, and I think a hard > dependency on Cairo and FreeType would make that even harder. I think there's some measure of confusion here: AFAIR we don't use Cairo for text shaping, only for its display. IOW, we tell Cairo to display this and that glyphs, after HarfBuzz returned them.