mirek wrote on Sun, 12 December 2021 17:41

The question now remains: When doing replacement, often some replacement font with black&white emoji glyph is closer in appearance than Color Emoji font. That results in mixing colored and B&W emojis. While technically probably more correct, should in case I am looking for emoji glyph always prioritize Noto Color Emoji (or maybe any color emoji font) over matching appearance of font?

Mirek

Hi,

Prioritizing color emoji would give the most consistent user experience on any desktop environment.

Best regards,

Tom

mirek wrote on Sun, 12 December 2021 17:41

The question now remains: When doing replacement, often some replacement font with black&white emoji glyph is closer in appearance than Color Emoji font. That results in mixing colored and B&W emojis. While technically probably more correct, should in case I am looking for emoji glyph always prioritize Noto Color Emoji (or maybe any color emoji font) over matching appearance of font?

Mirek

Hi,

Prioritizing color emoji would give the most consistent user experience on any desktop environment.

Best regards,

Tom

Tom1 wrote on Wed, 15 December 2021 08:29

mirek wrote on Sun, 12 December 2021 17:41

The question now remains: When doing replacement, often some replacement font with black&white emoji glyph is closer in appearance than Color Emoji font. That results in mixing colored and B&W emojis. While technically probably more correct, should in case I am looking for emoji glyph always prioritize Noto Color Emoji (or maybe any color emoji font) over matching appearance of font?

Mirek

Hi,

Prioritizing color emoji would give the most consistent user experience on any desktop environment.

Best regards,

Tom

I made U++ prioritize color emoji in Linux for now. Or most of them, it is not easy to decide which codepoints should prefer color; e.g. copyright sign is considered emoji, but I do not think it would be a good idea to prefer color font for it.

Also, please note that in Firefox there is a combined gender+skintone+profession in one image, whereas UWord shows a sequence of emojis to identify each property separately.

I am well aware of that, but it (unicode combining characters) is a task for another day....

Mirek

mirek wrote on Mon, 27 December 2021 09:33

I am well aware of that, but it (unicode combining characters) is a task for another day....

Mirek

Hi Mirek,

No worries. Another year is equally acceptable. (Just mentioned it as I came across it while testing.)

Another thing I found while testing is that on Linux Mint exporting a PDF from UWord using emoji-test.txt results in an empty file. Without emojis the PDF export works OK.

On Windows, exporting a PDF from UWord using emoji-test.txt results in a file with mostly weird symbols instead of the expected emojis shown on UWord.

(Just let me know if you wish me to stop testing here... )

Best regards,

Tom

Hi Mirek,

Thanks! I see the PDF from Windows is OK now.

It seems that the multi character issue is different in Windows compared to Linux:

263A FE0F                                              ; fully-qualified     # ☺️ E0.6 smiling face
263A                                                   ; unqualified         # ☺ E0.6 smiling face

On Windows I see an empty character (space) following a small BW smiling face for the fully-qualified version above. This is possibly caused by the FE0F -code, as similar behavior can be found in many places of the file (emoji-test.txt). However, on Linux there is just the smiling face without any additional spaces for both variants. Another place where this causes issues is the subgroup keycap:

# subgroup: keycap
0023 FE0F 20E3                                         ; fully-qualified     # #️⃣ E0.6 keycap: #
0023 20E3                                              ; unqualified         # #⃣ E0.6 keycap: #
002A FE0F 20E3                                         ; fully-qualified     # *️⃣ E2.0 keycap: *
002A 20E3                                              ; unqualified         # *⃣ E2.0 keycap: *
0030 FE0F 20E3                                         ; fully-qualified     # 0️⃣ E0.6 keycap: 0
0030 20E3                                              ; unqualified         # 0⃣ E0.6 keycap: 0
0031 FE0F 20E3                                         ; fully-qualified     # 1️⃣ E0.6 keycap: 1
0031 20E3                                              ; unqualified         # 1⃣ E0.6 keycap: 1
0032 FE0F 20E3                                         ; fully-qualified     # 2️⃣ E0.6 keycap: 2
0032 20E3                                              ; unqualified         # 2⃣ E0.6 keycap: 2

On Linux Mint all of the characters fall into their correct places pretty well. However, on Windows there are slight alignment issues with unqualified variants and fully-qualified variants are completely off having a space between the character and the keycap box.

BTW: Just noticed that you can actually copy and paste the above unicode sequences directly to the UWord for testing.

Best regards,

Tom

Another thing I found while testing is that on Linux Mint exporting a PDF from UWord using emoji-test.txt results in an empty file. Without emojis the PDF export works OK.