Eli Zaretskii さんはかきました: >> From: Mike FABIAN >> Cc: Robert Pluim , 39799@debbugs.gnu.org >> Date: Sat, 29 Feb 2020 09:01:37 +0100 >> >> > Emacs can only compose characters if the font supports all of the >> > codepoints that are being composed. So you need to choose a font that >> > supports these compositions. >> >> I think there are no fonts supporting both the emoji representations and >> text representations of emoji which have both. > > Sorry, I don't understand: what does "which have both" refer to? There are some emoji which have both emoji and text representations, for example: $ grep 24C2 emoji-variation-sequences.txt 24C2 FE0E ; text style; # (1.1) CIRCLED LATIN CAPITAL LETTER M 24C2 FE0F ; emoji style; # (1.1) CIRCLED LATIN CAPITAL LETTER M $ grep 24C2 emoji-data.txt 24C2 ; Emoji # E0.6 [1] (Ⓜ️) circled M 24C2 ; Extended_Pictographic# E0.6 [1] (Ⓜ️) circled M $ Other (most) emoji have only emoji representation, for example: $ grep 1F600 emoji-data.txt 1F600 ; Emoji # E1.0 [1] (😀) grinning face 1F600 ; Emoji_Presentation # E1.0 [1] (😀) grinning face 1F600 ; Extended_Pictographic# E1.0 [1] (😀) grinning face $ > Emacs doesn't create the text and emoji presentations, it just hands > the sequences to the font backend and asks the backend to provide the > font glyphs to display that sequence. The rest is between the font > backend and the font. And of course all this depends on > composition-function-table being set up to support these sequences. I think the specification in Unicode is quite vague on how this should be implemented. It doesn’t say anything about whether the fonts should do it or the application. If I understand it correctly, with the current implementation in Emacs, it would work if a font had glyphs for both variation selectors. I.e. if there was a font which had a colour glyph for 24C2 FE0F ; emoji style; # (1.1) CIRCLED LATIN CAPITAL LETTER M *and* a black and white glyph for 24C2 FE0E ; text style; # (1.1) CIRCLED LATIN CAPITAL LETTER M Then it would work in Emacs and 24C2 FE0F would display in colour and 24C2 FE0E in black and white. But there are no such fonts (yet??). Symbola doesn’t support the variation selectors at all, i.e. when using Symbola (set-fontset-font nil '(#x2460 . #x24FF) '("Symbola" . "iso10646-1") nil 'prepend) one gets the three variants Ⓜ U+24C2 Ⓜ︎ U+24C2 U+FE0E Ⓜ️ U+24C2 U+FE0F all in black and white and for the two variants which have the variation selectors one sees a narrow box in Emacs. When using “Noto Color Emoji” or “Joypixels”, one gets all three variants in colour, and a box is only shown for the line in the middle with the U+FE0E text style selector because neither “Noto Color Emoji” nor “Joypixels” seem to implement that one. The emoji style selector U+FE0F does not show a box though, if I understand you correctly that means that apparently both “Noto Color Emoji” and “Joypixels” implement the U+FE0F variation selector. If I paste these 3 lines into gedit (or anything else which uses pango for this) I see that different fonts are used. Can also be seen with pango-view --font="DejaVu Sans" ~/emoji-representation-test.txt (I attached the emoji-representation-test.txt file and how it is displayed by pango-view). I specified the DejaVu Sans font on the command line (which is used for the ASCII text in that screenshot. For the emoji, different fonts are used, on my system where I made that screenshot it happens to be the font “MS Gothic” for the emoji in the first two lines and “Noto Color Emoji” for the last line. So pango uses different fonts for a text representation emoji sequence than for emoji representation. The specification in Unicode does not seem to say that this is not allowed and that the font has to do it, it seems a bit vague there. -- Mike FABIAN 睡眠不足はいい仕事の敵だ。