Mirek,

Thanks for your great effort!

Best regards,

Tom

Hello Mirek,

I just did quick test with Emojies. It seems that most of it 90% are not rendered. Should it work like this at the moment? Example:


Platform: Linux/Manjaro - GTK. We could use https://openmoji.org/ emojies library.

Klugier

I've changed the line, and unfortunately nothing has changed.


It seems that the fallback list and the new font rendering routines have some issues. Because upp wchar32 update can definitely render emojis on Linux, as it can be seen from the screenshot in my previous message.
In my test case, it displays all the emojis correctly. The problem is I have to pass the emoji font as the active font. (in TheIDE's code editor, for example)

P.s I have recreated the fallback font list, using the FontMap2. Noto Color Emoji is correctly listed in it, but It doesn't take it into account (or maybe it does bot not scaling correctly, because I am getting a single pixel instead of a emoji. (This may also have to do the incorrect line height issue I have mentioned in my previous post.)


Best regards,
Obilvion

I think this is more likely related to color font rendering / handling.

Mirek

Hello!

I've found an error in displaying Cyrillic characters in latest U++ releases.
Here's a testcase:

#include <CtrlLib/CtrlLib.h>

using namespace Upp;

struct MyApp : TopWindow {
	void Paint(Draw& w) {
		ImagePainter ip(GetSize());
		ip.DrawRect(GetSize(), White());

		String s = "Абвгдежз";				// some cyrillic text
		ip.DrawText(10, 10, s);				// OK

		String s2 = ToCharset(CHARSET_WIN1251, s);
		ip.DrawText(10, 50, s2, CHARSET_WIN1251);	// draws rectangles instead of letters

		Image im = ip;
		w.DrawImage(0, 0, im);
	}
};

GUI_APP_MAIN
{
	MyApp().Run();
}

It works fine under U++ 15947.
Platform: Linux Mint.

Best regards.
Victor

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

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.