emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Entering emojis


From: Gregory Heytings
Subject: Re: Entering emojis
Date: Fri, 29 Oct 2021 10:32:03 +0000


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.


No, because Harfbuzz displays the fictitious joiner and deelimiter glyphs, and does not try to use the ligatures that the font provides.

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.


A picture is worth a thousand words.  I attach four files:

In 1.png you see what Harfbuzz displays with the previous HELLO entry. The three glyphs with a thick rectangle above and a crossed rectangle below are a fictitious glyph in the Aegyptus font for the codepoint hieroglyph vertical joiner, and the opening and closing parentheses are fictitious glyphs in the Aegyptus font for the codepoints hieroglyph begin and end segment.

In 2.png you see what I would expect Harfbuzz to do with the previous HELLO entry, if it knows that it cannot handle the joiner and segment delimiters or if it detects that the font does not provide enough information to handle them appropriately, and if the font has no ligatures: displaying the hieroglyphs one after the other. That's what I would expect to see with the Noto Hieroglyph font for example.

In 3.png you see what I would expect Harfbuzz to do with the previous HELLO entry, if it knows that it cannot handle the joiner and segment delimiters or if it detects that the font does not provide enough information to handle them appropriately, and if the font does have ligatures: displaying the hieroglyphs with the ligatures provided by the font. That's what I would expect to see with the Aegyptus font.

In 4.png you see what I would expect Harfbuzz to do with the previous HELLO entry, if it knows that it can handle the joiner and segment delimiters and if it detects that the font does provide enough information to handle them appropriately.

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.


Unless I misunderstand something, a text without joiners and delimiters would thus be displayed as 2.png, even if the underlying font provides ligatures with which it could be displayed as 3.png. And ZWNJ would be ignored. Which makes, as I said, the task of those who want to edit egyptian texts much harder, and unnecessarily so.

Here's a combined patch, with the comment you asked.

Thanks, installed on the release branch.


Thanks!

Attachment: 1.png
Description: PNG image

Attachment: 2.png
Description: PNG image

Attachment: 3.png
Description: PNG image

Attachment: 4.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]