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 Date: Mon, 18 May 2020 19:19: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> <83zha69xs2.fsf@gnu.org> <83367x9qeq.fsf@gnu.org> <83y2pp88lw.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="22791"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 18 21:21:09 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 1jalK1-0005oF-Di for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 21:21:09 +0200 Original-Received: from localhost ([::1]:54252 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jalK0-0003md-GE for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 15:21:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53294) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jalIt-0002RN-FW for emacs-devel@gnu.org; Mon, 18 May 2020 15:19:59 -0400 Original-Received: from mail-oo1-xc2f.google.com ([2607:f8b0:4864:20::c2f]:44833) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jalIs-00074R-Kd; Mon, 18 May 2020 15:19:59 -0400 Original-Received: by mail-oo1-xc2f.google.com with SMTP id p67so2294478ooa.11; Mon, 18 May 2020 12:19:57 -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=mzCUq5Y00yuqYGuCld+19AOVZM5dV4pvekIvfE0Vi64=; b=IJDLsuafsgaMeGFA7kDWbSlvs0M5Hw1NDpDhd+gtKVrYsoR1Du25JW1CM5Vk7Fa85k 0vTtLpXHML8TgT1V3SY3B0fBEP8zllwhps128qxCFs64si6OeVg3rcBmcegocC9ItuRs sMQ/I9oOmJ7dd7HR+AFzVuuPdN9Eoo4apdZoU3P6w1nn4WrjBZzyqjxRaQucedYQk4bW D0AhN4+cXD6VPU1Kj2kKYczCJ/XaGBdVwfELLMXkGQ3GaNMNtnEzPePA/KE4m0s32Nxp fLpAHdt7oksxPsK2B+tyGCWADAmIUGCM15c5fEzlhVyncHQAtKf+eRC6r2y8gNVpfl07 xMGQ== 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=mzCUq5Y00yuqYGuCld+19AOVZM5dV4pvekIvfE0Vi64=; b=OrBU9FAK70qBwig/0B5leBP8xcNMBRhXHNfxcMSDIIbtup2cQjUQzpzyLeNFksyVm3 GbqWUiol2LUUxvxzw9ozjLpp8yjeFpx175/k1Q9nWxN7rS7rZpYDQ7LzKSZ+dkzeaOiw 6EC9utfkqFNM9lHMsB7kHfgWO4+u/s+S+PFmR+dYPgD5nx+HRn45EiC6c9IjLImCdhy5 i11xMXvaDs7OjgAui+10w9lxAbYAYrjVypv9+tBDi3e6V2SMr83ygfp7o9p6zC4fBMXA opWO84P9Qabzh+m+2BsE6sqVQgWh4STEj2vDHq9YGpOzgEX30Bxvkl/beS7kE3i9Zwmr d7Vg== X-Gm-Message-State: AOAM533xTQILl5rXVMsDZJyFm9S68PMqzbDca0ST6b6ccgUTM2ydfHMY Yo+264YUQzQ6ARLSZ1ity7ry5hdIiIdZ+Ynb9XKpW9RT X-Google-Smtp-Source: ABdhPJymLyR8EhCuCWneWFF6pCaO/waFRYZowLdSUnJXo0GYbaGZigqhCDCA/ZpLCvYEYxZinKYQtgnglGKQF0LsgAY= X-Received: by 2002:a4a:9704:: with SMTP id u4mr3400165ooi.88.1589829596621; Mon, 18 May 2020 12:19:56 -0700 (PDT) In-Reply-To: <83y2pp88lw.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::c2f; envelope-from=pipcet@gmail.com; helo=mail-oo1-xc2f.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:250807 Archived-At: On Mon, May 18, 2020 at 5:18 PM Eli Zaretskii wrote: > > So, maybe we don't need very much info: all we need is a boolean which > > tells us whether the glyph should be treated atomically or not. > > When not treating it atomically, we would (somewhat arbitrarily) divide > > the glyph horizontally into N equal sized "subglyphs" and draw the > > cursor on the corresponding subglyph. > > That strikes me as not a very user-friendly UX. Especially if you > keep in mind that glyphs can be composed into a grapheme cluster using > 2D offsets, not just left-right one-dimensional offsets. So such clusters would be marked as atomic? I like Stefan's proposal, and maybe it's what LibreOffice actually does: at large font sizes, the horizontal division of "subglyphs" seems off. > An alternative which might be nicer is to "split" the composition: > display it as if a ZWNJ character was inserted at point. Thus, moving > forward one buffer position into the =EF=AC=83 would show f followed by a= thin bar > cursor followed by the =EF=AC=81; moving forward one more buffer position > would show =EF=AC=80 followed by a thin bar cursor followed by i. Etc. I tried something like that (with a variable-pitch font), and the effect is nauseating because the rest of the line shifts as the width of the word at point changes. What I tried was to use Harfbuzz to shape entire words when PT is not in them, then split them up into individual characters (the way it's done now) when PT enters them. Of course, people might still like it. > > If Harfbuzz could tell us more precisely how to divide the glyph into > > subglyphs, we could do a better job, of course. > > I don't think it's possible because AFAIK fonts don't store this > information. Well, they should! > It should be possible, of course, to have a private > database of such offsets, but I don't really see how it could work in > general. And this is where it gets back to "let's not hardcode the dependency on Harfbuzz and FreeType, because other backends might actually give us the information we need".