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: Unify the Platforms: Cairo+FreeType+Harfbuzz Everywhere (except TTY) Date: Sun, 17 May 2020 18:50:19 +0000 Message-ID: References: <20200517124125.000013a4@web.de> <97C7EAB7-10AB-4702-ABC8-EB6C1C50ABDB@gnu.org> <20200517165953.000044d2@web.de> <83lflqblp0.fsf@gnu.org> <83ftbybio3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="12537"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, julius.pfrommer@web.de To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 17 20:52:10 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 1jaOOQ-00039R-6p for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 20:52:10 +0200 Original-Received: from localhost ([::1]:54000 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaOOP-0007a6-9T for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 14:52:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43790) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaONI-0006lm-2F for emacs-devel@gnu.org; Sun, 17 May 2020 14:51:00 -0400 Original-Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]:39333) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaONG-0002Da-Uw; Sun, 17 May 2020 14:50:59 -0400 Original-Received: by mail-ot1-x332.google.com with SMTP id q11so6213872oti.6; Sun, 17 May 2020 11:50:58 -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; bh=l6EtPlG+w4BnAEjtZmig/WPn7dfYmwYlCtUJuuRRt5Q=; b=sH1hVEHpo88d7hGdIAUCnRkd6kzEdmguMNPIsHSEp343AdFExxUjz7hAA/4/eProKr GDxcvOkxtGPuLO6xQzVdV+9mmwfKv9mKf91g8h6n+ApMgnFozd+5PtBPM2Zq5kjXHH8U 3QOVukv7h7LdavSD+KriVD1Kh2zaTmki8NmDB+A8Qj3jjfg4W8ot//S13Dcn1SVaoK7T q9ADTuLzSktPeNz10yjThBSpwG6EdqJPqtJH+0pUVpAPXS2wSdBlTG6urpiYhNQXpgbE frWdSir3gRUi+RLW+ZhxJdMBwL7LPt4FOrzNrfL7PZut+s8tDDyls04k+ixZQZwx+3Se Gw0Q== 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; bh=l6EtPlG+w4BnAEjtZmig/WPn7dfYmwYlCtUJuuRRt5Q=; b=H0pzZ/jI0F+EZBpvRQOrfLmDbU3CTNeU5Ras43SNDtulRyO08DjA/sa0+02ENKeLev 8GZXQ2moLaGUFMzsQzYm78xHtVe8ENFAUGAyWzGbAmwWt14vw7pUIeseCzdmerfAJafJ O7XAEJZS7vEq4ZQ1GUieIWOd2H0IgVFmxSNJhbCAhUC2xOv94Y8kjIBDcssUKiNFQgy2 MC4dIr+IIJL0RjMh932dsK3Uq2YePAXeWXXi+ILeooBUZ0+fW89+2lIUIJXOwrMjXuBH DLkCq17+6fYVk/KclN5azUR6qWZUEcCpZPMZN5D6ebFdZppZLQsmPqbYsUN0oxPB6iPv K6ng== X-Gm-Message-State: AOAM533yb2yE/Yt6GGajNHA1ONumwyl7YUQL+yNfCAGdXCKsdH5UOJJv 64xZ6KqdRVKyDy19MPqZg1k3MeJcdihkq1VEjCoJuwvG X-Google-Smtp-Source: ABdhPJzVtrQQGv3I2mvWuj8CiIiy3R0mHtVYeKC97Eba1U5jzcQvnB2UIdZ4PzPN1qUUfc5BAP8xjnK9lGVTzTCuR+E= X-Received: by 2002:a9d:6a44:: with SMTP id h4mr5229479otn.287.1589741456936; Sun, 17 May 2020 11:50:56 -0700 (PDT) In-Reply-To: <83ftbybio3.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::332; envelope-from=pipcet@gmail.com; helo=mail-ot1-x332.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:250646 Archived-At: On Sun, May 17, 2020 at 5:00 PM Eli Zaretskii wrote: > > 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. I don't think that's true. > 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. HarfBuzz also tells you which codepoints are used for which glyphs. It should also, for languages where it can do so, tell you which codepoints are used for which subglyphs. It fails to do the latter. (I'm aware of what the Emacs display engine does; I'm, obviously, not accusing HarfBuzz of failing to present ligatures, because that's easily fixable. What isn't easily fixable is going back from the ligature glyph to its subglyphs. LibreOffice does it, and I wonder how, because the alternative is jumping back and forth between ligatures and individual characters depending on where PT is, and that looks horrible.) > 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. I'm using a different design :-) That one is simply unworkable for English and its limited traditional set of ligatures. > 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: No, it's not. It's meaningless for some languages, but not for English and its limited set of traditional ligatures. That a problem cannot be solved in general is no excuse to refuse to solve it in the specific cases where it can be. > > I'm not sure PangoCairo does better, but whatever Libreoffice uses > > appears to get the job done > > What job is that? LibreOffice highlights sub-glyphs of ligatures correctly. I enter "official", and it renders . I move the cursor right twice, and it highlights precisely what it should, the middle "f" of the ligature glyph. > > (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. I don't see how that's true. Treating a ligature as a single character for entry purposes is simply unworkable for English. It might be okay for other languages, but for English, we really need to display "ffi" correctly and still allow it to be edited as three characters. > That's > the shaper's job, and HarfBuzz does its job very well and stays on top > of the relevant technological advances. I don't see any evidence for that positive statement about HarfBuzz: out of the box, Emacs fails miserably to do anything about English ligatures. Trying to find a way to fix it, I ran into HarfBuzz limitations that appear to make it impossible to use it to deal with English ligatures. It might deal very well with other languages and their ligatures, but for English text, it fails to do what TeX did since its inception. > > 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. Yes, that's correct. Which means that a WebAssembly version of Emacs would need to bundle Cairo, even though it would prefer to simply render things in the browser using HTML 5 canvases or something similar.