From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Entering emojis Date: Fri, 29 Oct 2021 10:51:47 +0300 Message-ID: <83v91gqne4.fsf@gnu.org> References: <87cznths5j.fsf@gnus.org> <87tuh4f1ie.fsf@gnus.org> <0353A9DA-0041-4D71-8E1B-09FB07A5FD0F@acm.org> <87ilxialzw.fsf@igel.home> <831r46wj6r.fsf@gnu.org> <83fssmuxui.fsf@gnu.org> <83bl3aux6y.fsf@gnu.org> <835ytiuvm9.fsf@gnu.org> <834k91vgie.fsf@gnu.org> <8ff3b131c5fa370d9eaf@heytings.org> <83mtmttsxz.fsf@gnu.org> <8ff3b131c56b7b2d1d6f@heytings.org> <83bl39tqnl.fsf@gnu.org> <8ff3b131c531f5254799@heytings.org> <83a6ittp5r.fsf@gnu.org> <8ff3b131c53b9df49236@heytings.org> <834k91th5c.fsf@gnu.org> <8ff3b131c5fe09753ca0@heytings.org> <83mtmtru6l.fsf@gnu.org> <8ff3b131c57f741d04e5@heytings.org> <83lf2drqx6.fsf@gnu.org> <8ff3b131c550df7ca195@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10348"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mattiase@acm.org, raman@google.com, schwab@linux-m68k.org, stefankangas@gmail.com, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 29 09:53:19 2021 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 1mgMhT-0002Wt-1r for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Oct 2021 09:53:19 +0200 Original-Received: from localhost ([::1]:53418 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mgMhR-00077f-Vr for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Oct 2021 03:53:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46294) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgMgH-0005ZY-Mf for emacs-devel@gnu.org; Fri, 29 Oct 2021 03:52:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58644) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgMgF-0005lF-Uu; Fri, 29 Oct 2021 03:52:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rQF3jF5tKSynsAw45fdz++GGWh+PZpgGyUa+TFfmWLk=; b=GPh3FIvi+0ly mbmc6cZnQdjk0uBkZy47dyQWVdNHY0EchTZ4om3yguMbfE4fvwAAjGnL27ZzR+BjZljGtvpn/0+78 pqb8deLiavk6UL7ep7EyPGJMp8Tqcv7evRYFh4/JZ0p6oqs3NdigYPVB1cRPM0Pl1g1iVdkJI5ZA6 kpj1IQCs6J1RzBvSox3Ic3w1P1JAcnrAghjNAAKFz4e6butcYEPXg3xGnL1LFgTOen40NCXBhi614 yIE5O/Ak6oFVwQLQ/5Ztl3AwYR+BxCRoRn01VznQ7GA7kQxDZBtOKH2JS9HIVKbM2aSrEC/ru90F4 pzKWddFvo10QOiavg0kKhA==; Original-Received: from [87.69.77.57] (port=1896 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgMgE-0004Pr-QK; Fri, 29 Oct 2021 03:52:03 -0400 In-Reply-To: <8ff3b131c550df7ca195@heytings.org> (message from Gregory Heytings on Thu, 28 Oct 2021 21:10:41 +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:278172 Archived-At: > Date: Thu, 28 Oct 2021 21:10:41 +0000 > From: Gregory Heytings > cc: mattiase@acm.org, emacs-devel@gnu.org, schwab@linux-m68k.org, > stefankangas@gmail.com, raman@google.com > > > Yes, I know. But ligatures are not the only way of handling this. When > > a font produces a ligature, i.e. a precomposed glyph that should be > > displayed instead of several characters, it produces a single font > > glyph. The other way is to produce several font glyphs, each one with > > offsets relative to the base-line. Emacs supports both ways. However, > > for any of the two to work, both the shaping engine and the font should > > recognize the sequence, and the font should produce one or more glyphs > > with the offsets for that sequence. > > In this case, ISTM that the problem is not the font, but the shaping > engine. If Harfbuzz does not know how handle the joiners and segment > delimiters, it should behave as they did not exist, and use the font > ligatures (if the font does have ligatures) AFAICT, this is what happens here. > instead of displaying the fictitious glyph at that codepoint (at the > codepoint of the joiner or delimiter). I don't think I understand what fictitious glyph you allude to here. The joiners were displayed as thin spaces by the Emacs glyphless-char-display feature, because HarfBuzz+font didn't compose the sequence, and returned the separate font glyphs for each codepoint in the sequence. IOW, the composition failed, and therefore Emacs displayed each of these characters as it's supposed to do. > If it knows how to handle joiners and delimiters, it should ignore > the font ligatures and create the final glyph with the individual > glyphs in the font. This doesn't happen in general, only in some very specific cases, where the HarfBuzz developers decide to implement a fallback strategy of this kind. In the general case, HarfBuzz (and any other shaping engine) recognizes the sequence, and looks into the font tables for how to display that sequence; it then returns one or more font glyphs from the font information about that sequence. It only "ignores" the font glyphs when some reasonable fallback is required, which is generally avoided, because it's assumed that the font designers know better. > > I mean what the Unicode Standard says: it says that two hieroglyphs > > should be displayed "normally", i.e. as separate characters at the same > > vertical position, unless there's the vertical joiner between them, in > > which case one should be above the other. > > > > I understand. But what the standard says doesn't make sense I think, > because it means that it requires one to ignore font ligatures and instead > requires one to use joiners and segment delimiters. No, the joiners are supposed to tell the shaping engine and the font that we want the ligatures and not separate font glyphs. > > However, the composition rules I defined went with Unicode, and need to > > be fixed to support what the Aegyptus font does. Does the patch below > > help? > > > > It does! Thanks. > > Here's a combined patch, with the comment you asked. Thanks, installed on the release branch.