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: Sat, 23 May 2020 22:38:18 +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> <837dx55qff.fsf@gnu.org> <834ks95cmz.fsf@gnu.org> <4faa291f-f2df-36d1-73d5-332b93a9b6d8@gmail.com> <83wo544hx5.fsf@gnu.org> <831rnc43ih.fsf@gnu.org> <83ftbs2jr5.fsf@gnu.org> <83lflj16jn.fsf@gnu.org> <83eerb145r.fsf@gnu.org> <831rnb0zld.fsf@gnu.org> <83mu5yzquj.fsf@gnu.org> <838shizk35.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="23491"; 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 Sun May 24 00:39:38 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 1jccnp-00060E-Os for ged-emacs-devel@m.gmane-mx.org; Sun, 24 May 2020 00:39:37 +0200 Original-Received: from localhost ([::1]:59328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jccno-00052v-Pg for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 18:39:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42006) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jccnC-0004Qd-BE for emacs-devel@gnu.org; Sat, 23 May 2020 18:38:58 -0400 Original-Received: from mail-ot1-x330.google.com ([2607:f8b0:4864:20::330]:34839) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jccnB-0001gf-4p; Sat, 23 May 2020 18:38:58 -0400 Original-Received: by mail-ot1-x330.google.com with SMTP id 69so11176192otv.2; Sat, 23 May 2020 15:38:56 -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=4PBvRib8lv3mLowlJ7SMYpiC6yjR14s97sxvkzsxXB0=; b=GNtngkJJgVpVuuxJ8i7Kmp2EXOVfjfLxP8koTImxa0UNXK53EgKRfAw+lSs8ykeCMG XsNMM3FBUn2AV4a/pMLzJv9lngMXlVIkH1KBRQAD8AYQI5dMt1915eQeNP88Rp6d5uww W9ra5/anUrJ2gcqzgFNUtPNJQyGfsiUwj7G0bGXlyWrlRG1hD5e5/73OJ7Gfi0tMTNtL Y8dbSUzgGenCnMWyCPo1K/+A0FXcQulvkkmobR3LSPpp3JPdykJfzKl/VtzZESE0nzQZ P0IhRV9rE+UFHiKzsuKHgvAA8jM6A83NYRqn0CMvQlKeqUTBPyk7FYCs6aGNDPkBlYK+ rx0A== 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=4PBvRib8lv3mLowlJ7SMYpiC6yjR14s97sxvkzsxXB0=; b=tPlJhzMVQiY0WMNkPav+kQKbzc0zimYsmgyrN0sIAvO1aG5QHXXnjzAOQfkIyqEXEb FIeGloP4bkVnMPM8mK4xGq7BhGw+zQG96+6iH4kJtbmFmfWiGCqjHr+E6xpWAwZUSf0j OHyRtkYvRu19w8qPv9+af0uMwtWRkzd9CX66qheYH+hGvO2ZOsWSe+0mvmbDeQdgI8aH J6SMia3b55F6lvL1nb3kmpiNzo4bzO/v6t3x5+B/J4j7T2XR54IqTuTB6OJ6NvTc7Qh7 q14e59jTGEaOMjn/Q/X5a1Jf6ox9YUGxHswvfRfWyy9BgdrGZQS8eiD/DzckNQQDZoNN KK5g== X-Gm-Message-State: AOAM530Txb8o2orSrHht9xOqF8J9zwgvSMqtdLKRRZoxmzlR270k3E5F Bt08Loa9jzmUBdJ3oWELknvoHo9gDCfbqGkuX31FGIPt X-Google-Smtp-Source: ABdhPJyrds/vxZYW3W9nKpsmeb35zfM0SXzTvvVNAfrYPuMMN3IgtZReK6X+D84S+/D42UctZU3K6vkNYdLp65vxRuY= X-Received: by 2002:a9d:6a44:: with SMTP id h4mr16592348otn.287.1590273535474; Sat, 23 May 2020 15:38:55 -0700 (PDT) In-Reply-To: <838shizk35.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::330; envelope-from=pipcet@gmail.com; helo=mail-ot1-x330.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: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, 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:251292 Archived-At: On Sat, May 23, 2020 at 4:34 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sat, 23 May 2020 15:13:38 +0000 > > Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org > > Because what the current layout code does by default is to break > > along any glyph boundary, and I don't see how that's broken in any > > way. > > The code assumes that breaking on some glyph leaves the buffer > iterator ('struct it') in a state that we can simply continue to the > next buffer position. Yes. I see no reason to change that. > But if you already picked up several characters > via look-ahead, that is not true, and you will have to return back > several character positions, in order to continue on the next screen > line. You're describing why look-ahead is difficult: a while ago, you appeared to be saying it wasn't. This confuses me. Obviously, when I say "look-ahead", I mean receiving the next display elements an iterator would produce if it were actually advanced, without advancing it. An easy, but potentially slow, way of doing that is to copy the iterator to a new one, advance that, retrieve the display elements, then throw away the copied iterator and return. > The whole convoluted logic of display_line (and a similar one > in move_it_in_display_line_to) is based on the assumption that this > line-wrap decisions are made as soon as a single glyph is produced; > that code will need to be rewritten if this assumption breaks. I see no reason to break that assumption. > And > since the code is already hairy, to say the least, I cannot even > imagine what it will look like after such rewriting. Good thing I'm not planning to do that, then. > This is just a small example of how deep are the current design > assumptions entrenched in the code. One I don't understand, because those fundamental design assumptions aren't something I'm willing to break at this point. > > > In short, I really don't see how this could ever work, except in a > > > very limited set of simple use cases. E.g., what do you do with > > > bidirectional text? ignore it? > > > > A bidi boundary is a hard boundary for HarfBuzz, and no shaping > > happens across it. Is that what you mean by "ignore it"? > > I don't mean the boundary, I meant the fact that clusters need to be > reordered. I see no fundamental problem there, certainly not of the "I don't see how this could ever work" variety. > > > I don't see how it could work in production while supporting all the > > > use cases we already do. > > > > It only comes in for use cases not handled otherwise, i.e. those where > > the iterator is at an IT_CHARACTER. All other use cases are > > unaffected, because they mean we're overriding the font decision > > anyway. > > I see no reason to add such patches just to handle some simple enough > use cases. If it's so simple to get ligatures and kerning right, please tell me how to do it. > If we want the shaper to handle all the text we display, Do we? A while back you said Lisp control over compositions was an important feature, and I'm inclined to think we shouldn't break the existing composition code. > we should go all the way and do it for any text, ASCII, non-ASCII, > symbols, emoji, everything. Are you suggesting I'm somehow limiting myself to ASCII? Let me assure you that's not the case. > The current codebase is already very > difficult to understand and modify; I agree with that. > you seem to suggest to make it > even more so, Well, yes, it's not going to be a free feature. The changes are comparatively tiny compared to what else has been done to xdisp.c. > and on top of that solve only a small part of the > underlying problem. Ligatures and kerning (right now, for LTR text). Is that a small problem because of the lack of RTL support?