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.