Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » U++ community news and announcements » 32 bit wchar merged
Re: 32 bit wchar merged [message #57786 is a reply to message #57785] Wed, 15 December 2021 10:53 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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


A bit of issue is that Win32 does not support color emoji in GDI as of now. We would need to go Direct2D or something to do that. At least use Direct2D to extract those pictures.

(And yes, in general, I think it might be the time to move from GDI, but I do not want to do that now.)
Re: 32 bit wchar merged [message #57787 is a reply to message #57786] Wed, 15 December 2021 11:12 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Mirek,

OK, I understand. But please keep me posted if you decide to go ahead with Direct2D or any other GDI replacement option. The 2D graphics functionality and performance on Windows is critically important for me -- and has always been -- so I wish to participate already in early stages to ensure a smooth transition.

Best regards,

Tom
Re: 32 bit wchar merged [message #57883 is a reply to message #57785] Sun, 26 December 2021 20:12 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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.
Re: 32 bit wchar merged [message #57884 is a reply to message #57883] Sun, 26 December 2021 22:09 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
mirek wrote on Sun, 26 December 2021 21:12
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.

Yes, I see your point. It is indeed difficult to decide which way to go with each of them, but certainly (R) and (C) must be b/w.

This is not a perfectly clear pattern, but it seems that Firefox prioritizes b/w emojis for 16-bit codes and color emojis for higher codes. 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. Please open emoji-test.txt (https://unicode.org/Public/emoji/14.0/emoji-test.txt) in Firefox (and maybe Chromium too) to see how they render it. Then compare with UWord.

Best regards,

Tom

Edit: Added link to latest emoji-test.txt.

[Updated on: Sun, 26 December 2021 22:23]

Report message to a moderator

Re: 32 bit wchar merged [message #57890 is a reply to message #57884] Mon, 27 December 2021 08:33 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
[quote title=Tom1 wrote on Sun, 26 December 2021 22:09]mirek wrote on Sun, 26 December 2021 21:12
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
Re: 32 bit wchar merged [message #57930 is a reply to message #57890] Tue, 28 December 2021 15:48 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
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... Smile )

Best regards,

Tom
Re: 32 bit wchar merged [message #57959 is a reply to message #57930] Wed, 05 January 2022 09:33 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Tue, 28 December 2021 15:48
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... Smile )

Best regards,

Tom


Windows situation should be now fixed (with black emojis).

Outputing color emoji in Linux needs some more work...

Mirek
Re: 32 bit wchar merged [message #57964 is a reply to message #57959] Wed, 05 January 2022 11:42 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
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. Smile

Best regards,

Tom
Re: 32 bit wchar merged [message #57965 is a reply to message #57964] Wed, 05 January 2022 12:09 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Wed, 05 January 2022 11:42
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. Smile

Best regards,

Tom


Frankly, this is at the moment way beyond what I plan to implement. I think combining characters for normal texts and RTL handling has much higher priority.

(I am at crossroads there - sensible approach would be to embed harfbuzz but it seems quite heavyweight and possibly breaking too much of current CtrlLib).
Re: 32 bit wchar merged [message #58000 is a reply to message #57965] Wed, 12 January 2022 10:23 Go to previous messageGo to next message
coolman is currently offline  coolman
Messages: 114
Registered: April 2006
Location: Czech Republic
Experienced Member
Hi,

Have you checked this 32 bit wchar changes together with the sqlite plugin? I have some problems with that. It seems, that only one letter is read / inserted instead of string.

BR, Radek
Re: 32 bit wchar merged [message #58001 is a reply to message #58000] Wed, 12 January 2022 14:24 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Thanks, should be now fixed.

If you could test other engines, would be great.
Re: 32 bit wchar merged [message #58002 is a reply to message #58001] Wed, 12 January 2022 16:25 Go to previous messageGo to next message
coolman is currently offline  coolman
Messages: 114
Registered: April 2006
Location: Czech Republic
Experienced Member
Sqlite plugin now works (at least my problem disappeared). Thank you
Re: 32 bit wchar merged [message #58003 is a reply to message #57930] Thu, 13 January 2022 00:20 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Tue, 28 December 2021 15:48


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.


Hopefully finally fixed.

Mirek
Re: 32 bit wchar merged [message #58005 is a reply to message #58003] Thu, 13 January 2022 08:37 Go to previous message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi Mirek,

Thanks! It looks good now.

Best regards,

Tom
Previous Topic: Linux GlCtrl leaks problem fixed, new leaks related functions
Next Topic: Minor ide improvement when opening 'unknown' file
Goto Forum:
  


Current Time: Fri Mar 29 14:52:04 CET 2024

Total time taken to generate the page: 0.01828 seconds