emacs-devel
[Top][All Lists]
Advanced

[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: Eli Zaretskii
Subject: Re: Unicode 13 Emoji ranges composed with wrong font on NS port
Date: Wed, 13 Oct 2021 15:58:19 +0300

> From: Robert Pluim <rpluim@gmail.com>
> Cc: alan@idiocy.org,  wyuenho@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 13 Oct 2021 11:35:22 +0200
> 
>     Eli> That's because VS-16 is already handled by other entries, including
>     Eli> its own?  Or how will VS-16 be handled if you remove it from that
>     Eli> range?
> 
> Digging deeper, we could actually remove the VS-16 entry completely,
> since itʼs then handled by composite.el:737 :
> 
>     (when unicode-category-table
>       (let ((elt `([,(purecopy "\\c.\\c^+") 1 compose-gstring-for-graphic]
>                    [nil 0 compose-gstring-for-graphic])))
> 
> although I think Iʼd prefer to be explicit about it.

Why do you prefer that?

>     Eli> And if the reason is that VS-16 is not about glyph variations, then
>     Eli> why not exempt VS-15 as well?  Or why we need that special entry for
>     Eli> VS-16 at all?
> 
> I donʼt know the history. I also donʼt know how common fonts which
> contain variant glyphs are. Iʼll have to run some experiments.

But VS-15 is not about variant glyphs, it's about requesting the "text
representation" of certain characters, including Emoji.  So it sounds
like the rule for compose-gstring-for-variation-glyph is not really
relevant for it, as well as for VS-16.  Right?

>     >> +;; We don't want variation selectors to be used to look up glyphs for 
> FE0F
> 
>     Eli> The comment should explain why.  Right now, the comment just says 
> what
>     Eli> the code does, but gives no reasons.
> 
> Iʼll fix that.

Thanks.



reply via email to

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