[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unicode 13 Emoji ranges composed with wrong font on NS port
From: |
Robert Pluim |
Subject: |
Re: Unicode 13 Emoji ranges composed with wrong font on NS port |
Date: |
Wed, 13 Oct 2021 16:52:52 +0200 |
>>>>> On Wed, 13 Oct 2021 16:12:42 +0300, Eli Zaretskii <eliz@gnu.org> said:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Jimmy Yuen Ho Wong <wyuenho@gmail.com>, emacs-devel@gnu.org
>> Date: Wed, 13 Oct 2021 12:22:26 +0200
>>
>> Based on what I see here, itʼs the usual suspects: eg U+261D. Itʼs not
>> part of the emoji script in Emacs. The font_range change should cause
>>
>> U+261D U+FE0F
>>
>> to switch to emoji presentation, but it doesnʼt since thereʼs a
>> composition-function-table entry for U+261D, so the backwards looking
>> entry for U+FE0F never comes into play.
>>
>> Iʼm not sure how to fix this.
>>
>> - We canʼt add U+261D to the emoji script.
Eli> These composition-function-table entries for these characters
Eli> come from emoji-zwj.el, so we could simply add the above sequences to
Eli> that, by suitable change in emoji-zwj.awk, right? And then the
Eli> font_ranges trick should cause us select an Emoji font, right?
The triggering character would not be an emoji,so weʼd need to change
font_range. See below
Eli> But is it worth the trouble? IOW, do these characters have pretty
Eli> appearance when they are followed by VS-16?
They do. The difference is quite pronounced.
Eli> I wouldn't add the characters themselves to the 'emoji' script, as
Eli> that would have much wider consequences, not necessarily good ones.
Eli> For example, I don't think that these characters, when they aren't
Eli> followed by VS-16 or something Emoji-like, should be displayed using
Eli> the Emoji fonts.
So if I change emoji-zwj.awk to emit codepoint+U+FE0F rules for these
problematic codepoints which have Emoji_presentation = No, and change
font_range to try looking up the emoji font for them, all the
'codepoint+U+FE0F' from Jimmy's test file display as Emoji, and the
'codepoint+U+FE0E' display as text.
It would mean emitting rules in emoji-zwj.awk for, and checking in
font_range for, the following codepoints.
U+261D, U+26F9, U+270C, U+270D, U+2764, U+1F3CB, U+1F3CC, U+1F3F3,
U+1F3F4, U+1F441, U+1F574, U+1F575, U+1F590
As an added bonus, those U+1xxxx codepoints would no longer be part of the
'emoji' script.
>> - We could fix the backwards looking issue with
>> composition-function-table (I have no idea how complex that is)
Eli> I don't think it's complicated, and I already asked Kenichi Hand about
Eli> that, hopefully he will either agree with my conclusions or explain
Eli> where I'm wrong.
OK. Let's cross that bridge when we get to it.
Robert
--
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, (continued)
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Alan Third, 2021/10/12
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Robert Pluim, 2021/10/13
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Eli Zaretskii, 2021/10/12
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Jimmy Yuen Ho Wong, 2021/10/12
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Eli Zaretskii, 2021/10/12
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Robert Pluim, 2021/10/13
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Eli Zaretskii, 2021/10/13
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port,
Robert Pluim <=
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Eli Zaretskii, 2021/10/13
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Robert Pluim, 2021/10/14
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Eli Zaretskii, 2021/10/14
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Robert Pluim, 2021/10/18
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Eli Zaretskii, 2021/10/18
- Re: Unicode 13 Emoji ranges composed with wrong font on NS port, Robert Pluim, 2021/10/19