From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Newsgroups: gmane.emacs.help Subject: Re: Display of decomposed characters Date: Sun, 28 Feb 2021 19:10:57 +0100 Message-ID: <0077B374-A65D-412D-B1A5-4ADDD50D41A7@gmail.com> References: <83v9csplwq.fsf@gnu.org> <83wnx5n1zw.fsf@gnu.org> <831rea3ymg.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="676"; mail-complaints-to="usenet@ciao.gmane.io" Cc: help-gnu-emacs@gnu.org To: Eli Zaretskii Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 28 19:11:33 2021 Return-path: Envelope-to: geh-help-gnu-emacs@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 1lGQXV-00006p-9a for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 28 Feb 2021 19:11:33 +0100 Original-Received: from localhost ([::1]:58218 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGQXU-0004Ac-9s for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 28 Feb 2021 13:11:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50560) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGQX0-0004AV-TU for help-gnu-emacs@gnu.org; Sun, 28 Feb 2021 13:11:02 -0500 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:38039) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lGQWz-00049F-A4; Sun, 28 Feb 2021 13:11:02 -0500 Original-Received: by mail-wr1-x42a.google.com with SMTP id b3so13710736wrj.5; Sun, 28 Feb 2021 10:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PzDZ7HZ+V4ROGi8Qlp6Jydst7wcTWqdK+mg4VLf/eZw=; b=CSk24akgCPrFpLJZc+vf4Vi2/JlwBBUr9Sysrmac7WsCf45y/LR5CqJEW7Upcpg/UY 1mC9rnZ7z1BLKiocnMRY53dhCDpufTHGOGDg1zkiKbtdCR5yp00i1R2/mL0k8ECq8O0a 3nbIJ8RwNdat7HTNcgUfpI5YLPlNJNjnQFDSFpwej9kgH4cAItjPnx4EAxmoQf3Y1uJj /ySBjGtJ03syG+IJlDMAMDyIgbBDqTmPSUznOr1FuOC1KHsvB0cR08mi06MgOyaQCd5E 2QpjOb2SIAM6cnnD2xijvGJbcRHVZC6ZyrjQNnzAtQNxqQKidyHaVP4I4nLjzDmCgoMg lW8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PzDZ7HZ+V4ROGi8Qlp6Jydst7wcTWqdK+mg4VLf/eZw=; b=I83wJBzw9z3raJfuJIfxPuinC8TNHNKOUN7FIKgB/XsKsjKwBgbdI9F9u8QO4Wud3h 4v5/5wux+s9u/GVMBq428d4i2oEsZ978/e4KTeAwIDLupxrDMFiAfmDtw+khQPaaMzxe bRW56cg5opXHz+d4zYgT1KNBhxT1/OgccvmqLGnavVbHq4Ot4uZb0eIjL2ylJ3uGqvP1 52EghknjmmGdqzxc73LZxOC6yQT1fnq0uKOvGhsA1yuNvWHdA09rjGiLEGGHpKFheUqd r+2QeysgjtjccsfrKMDmzTEtFfeYw1btjN2+aGITKKeUqrgGNh3rohZtwXVvqt7lYNuI wjjA== X-Gm-Message-State: AOAM532WPs0oZv/QLF4wbh+yG205xL03HHgPb7Ko6ZDBfRtttNqBkm5h fcA+edjew5XsInrBvC2PvGeTbOJ22fd6iw== X-Google-Smtp-Source: ABdhPJx8MECbEGmxeiVisPjXvkU1US1mUYB95mC03Yx6CbSquNUva7lv5nUrDrzQf2CwYOn8Yf9vaQ== X-Received: by 2002:adf:f905:: with SMTP id b5mr12549291wrr.129.1614535858521; Sun, 28 Feb 2021 10:10:58 -0800 (PST) Original-Received: from philipps-mbp.fritz.box ([46.128.208.19]) by smtp.gmail.com with ESMTPSA id f126sm7782504wmf.17.2021.02.28.10.10.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Feb 2021 10:10:58 -0800 (PST) In-Reply-To: <831rea3ymg.fsf@gnu.org> X-Mailer: Apple Mail (2.3654.60.0.2.21) Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=p.stephani2@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:128317 Archived-At: > Am 24.01.2021 um 20:48 schrieb Eli Zaretskii : >=20 >> From: Philipp Stephani >> Date: Sun, 24 Jan 2021 19:58:18 +0100 >> Cc: help-gnu-emacs >>=20 >>> If the default font supports the diaeresis, that will happen >>> automatically. If not, then simply don't choose the default font = that >>> doesn't support accents. >>=20 >> The font will always support the composite variant (because it's part >> of Latin-1). >=20 > That is only relevant if Emacs decides to compose the characters. > Then, and only then, will it ask the text-shaping engine to produce > glyphs for the base character and the accent together, and then the > font could provide a single precomposed glyph for them. So in this case the decision to not compose the characters is incorrect = or happens too early? >=20 >> I guess fonts assume that applications will first try to normalize >> strings to avoid issues like this? >=20 > Normalizing strings before you know whether the font has the > precomposed glyphs makes no sense. Why? If the font doesn=E2=80=99t support a precomposed character, = wouldn=E2=80=99t the rendering engine automatically fall back to a = decomposed representation? (Serious question; I don=E2=80=99t know = whether Harfbuzz does that.) IOW, would normalizing strings to NFC = before sending them to the rendering engine ever break anything? >=20 > What the text-shaping folks tell us is that we should pass _all_ the > text through the text shaper, then the shaper will DTRT in every > case. But this would mean a thorough redesign and reimplementation of > how we do that in Emacs, and that is not easy if we want to keep the > current flexibility and customizability (which is why the character > composition code calls out to Lisp, and that makes sending all the > text that way tool expensive to be practical). Would it be possible to implement a more minimal change to fix the = problem at hand? >=20 >> Does it ever make sense to pick different fonts for a base character >> and its combining characters? >=20 > If the default font doesn't support the combining accent, what else > can you do? Most fonts don't have precomposed glyphs for every > arbitrary sequence of base character followed by several combining > accents. So sometimes you will have to compose the accents "by hand", > and that is not really possible if they come from different fonts. Which is why they shouldn=E2=80=99t come from different fonts. What if = Emacs ignored font lookup for combining characters and always picked the = font of the previous base character? >=20 >> Wouldn't that fundamentally prevent using combining characters? IIUC >> text rendering engines should be able to pick the right glyph if >> that didn't happen (assuming they can perform Unicode >> normalization). >=20 > Unicode normalization is only tangentially relevant here. >=20 Sure, but in this case it would fix them problem AFICS.