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 21:06:27 +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> 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="65674"; 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 23:07:51 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 1jbsPu-000Gzd-JW for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 23:07:50 +0200 Original-Received: from localhost ([::1]:59488 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbsPt-0007Ke-MN for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 17:07:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbsPD-0006So-Ai for emacs-devel@gnu.org; Thu, 21 May 2020 17:07:07 -0400 Original-Received: from mail-oo1-xc34.google.com ([2607:f8b0:4864:20::c34]:36811) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbsPB-00056k-Fx; Thu, 21 May 2020 17:07:06 -0400 Original-Received: by mail-oo1-xc34.google.com with SMTP id z6so1745153ooz.3; Thu, 21 May 2020 14:07:04 -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=5GeJg70Dt6yAfKA9VgIYw2b46LimkO/qnw5tVM6lcrM=; b=s3nt8a20po2BRhjVgejQi30fLc2mLhPCskwGMzwKzLiiQ+yRzl6NZCKI1/rP+KuAov LTVj8xlIjLGuSQAoDhmM4gx7AY+ms2fnDsjJZYebwvLJQvY7xeIjjo0Ez397pY0k3K8w RajZdkpXEl/Zyk2pKOsUcxyTHF4+2oVjZoZVlNyvGbLtfuV0yhdCLTKJ0JTppToeSf/X xn5GLLn4W4V3TB6DCt9tQQ7Qt66iTaoqAl4wiP4F+htSk2CiUV8Ii1yV5pAcnSB6jNvz WfXcvutG5xWPOOUkByvQovjjpYmlDwzhA7m3glJncNPeBW5ABRL0L9HOBj3qgdg1y+1q vcFA== 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=5GeJg70Dt6yAfKA9VgIYw2b46LimkO/qnw5tVM6lcrM=; b=FcXg77crAEGsQjWKS+/mhDMAtgTwZ8yzQ45mRjr/iJLpY2chGt4f3lDL9Kwb5VTEV8 cnMF5XfvdzV51C5z+jRg23KOGQTMsU6mCW+xK/yUoudbVAjK8rT7vtgrqy6IS41J5saa jObOnHZI4Ot/fxj7O5e6auzTtMbFf+3tXvgLiBDy4tAI67IAvBCOqyjfpsIGTEcUUhxa VDxiT6+SRy6OyI/70nklVGYP8fyZ037/GizSzB69IS29sqPQJ+umErUYPa+Euro+dKC7 lSdw8fvxP88A7yitqwlHyyVtXjBV6DiLOQnnWT405JqePlavZu/G6nfKETKddRXVDaZp l7yw== X-Gm-Message-State: AOAM530ohxvSmc/DN+iYxAtRSVuidbErIwMb/ebIpRKfN7/Mm3Qrl+yG NufPTcGkBykNIOCLClN+48l7Dctf44ACqY40r8QYM66j X-Google-Smtp-Source: ABdhPJynGyXEXNH+tOBwke5A5hWskP2J98Ti+7p3rsh6KrEW7401Km4EsgVyWhmJ/q9jfE4PrvjGFBJk1AqYvhs01Do= X-Received: by 2002:a4a:9704:: with SMTP id u4mr484890ooi.88.1590095223807; Thu, 21 May 2020 14:07:03 -0700 (PDT) In-Reply-To: <834ks95cmz.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::c34; envelope-from=pipcet@gmail.com; helo=mail-oo1-xc34.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:251185 Archived-At: On Thu, May 21, 2020 at 7:08 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Thu, 21 May 2020 16:26:13 +0000 > > Cc: cpitclaudel@gmail.com, alan@idiocy.org, emacs-devel@gnu.org > > > > On Thu, May 21, 2020 at 2:11 PM Eli Zaretskii wrote: > > No. I didn't touch the "static compositions" part at all, except for > > passing an extra NULL pointer to an API I'd extended. (At least, > > that's what I intended, for all the changes to be in the IT_CHARACTER > > part). > > I mean this part: > > @@ -30433,8 +30483,9 @@ gui_produce_glyphs (struct it *it) > else > { > get_char_face_and_encoding (it->f, ch, face_id, > - &char2b, false); > - pcm = get_per_char_metric (font, &char2b); > + &char2b, false, > + make_context (it)); > + pcm = get_per_char_metric (font, &char2b, make_context (it)); > } > > This calls make_context and passes it to these functions. This code > handles static compositions only. Oops, sorry. You're right, that change was harmless but unintended; the relevant change is @@ -29989,9 +30033,11 @@ gui_produce_glyphs (struct it *it) it->descent = FONT_DESCENT (font) - boff; } - if (get_char_glyph_code (it->char_to_display, font, &char2b)) + context = make_context (it); + if (get_char_glyph_code (it->char_to_display, font, &char2b, + context)) { - pcm = get_per_char_metric (font, &char2b); + pcm = get_per_char_metric (font, &char2b, context); if (pcm->width == 0 && pcm->rbearing == 0 && pcm->lbearing == 0) pcm = NULL; > > > The "modern" way of composing text in Emacs uses automatic > > > compositions, which are controlled by data in > > > composition-function-table. This is where we call the shaping > > > engine to produce the glyphs according to rules stored in the > > > font. I don't see in your patch any changes that affect ligatures > > > created by automatic compositions; did I miss something? > > > > I don't think so; I went for a third route, that of leaving all > > compositions handling to the shaper and doing none of it in Emacs > > itself. > > But automatic compositions do work by calling the shaper. Yes, that observation is correct. What I'm doing is still very different from the (semi-)automatic compositions composite.c does. > > Perhaps I can digress a little and describe what I think the > > interaction with the shaper should be like: > > > > Emacs: I'd like to display codepoint 'f' > > Harfbuzz: you'll have to tell me the codepoint before that > > Emacs: 'f' > > Harfbuzz: and the one after those two > > Emacs: 'i' > > Harfbuzz: and the one before all of those > > Emacs: That's too expensive for me to compute / it's the beginning of > > paragraph / a bidi boundary / an object without an assigned codepoint > > / ... > > Harfbuzz: okay, display it as the middle slice of the "ffi" glyph > > > > I.e., I'd like Harfbuzz to be asynchronous, and request more > > information, parsimoniously, about the context of the codepoint we're > > describing, rather than working in one go from "complete" information > > to an indefinitely-long line of glyphs. And deal well with us deciding > > it's too expensive to perform that much look-back/look-ahead. (Because > > in real life, ligatures depend on knowing some amount of the context, > > but not all of it, or people could never start writing.) > > That would prevent Emacs from controlling what is and what isn't > composed, leaving the shaper in charge. Well, yes and no: the shaper is in charge, and I see absolutely nothing wrong with that. You can tell the shaper not to perform ligatures (or perform only some of them), or kerning, if you want to. > We currently allow Lisp to > control that via composition-function-table, which provides a regexp > that text around a character must match in order for the matching > substring to be passed to the shaper. And you're suggesting that regexp be set to, say, ".+"? Because that's the only way I've found of getting it to do kerning. > We never call the shaper unless > composition-function-table tells us to do so. ...whereas I want to call it every time, which is why having composition-function-table in the loop seemed wasteful. > I'm not sure I understand what problems do you see with this design. I meant the redisplay engine in general, not the way automatic compositions work. (That's not to say I'm happy with automatic compositions, but that's a different subject).