Re: [Tuxpaint-devel] conversion from wchar to utfstream

[Shin-ichi T. <dol...@wm...>]

Hi!

As far as I tested,  I did not come upon any issue with label stuff on
windows and linux.

However, what I felt strange  was that the program never went thorough
the block in "if (font->typ == FONT_TYPE_PANGO){...}" even I tried all
the font loaded. Here, I've enabled both 'Load System Fonts' and 'Load
All Locale Fonts'.

Therefore, unfortunately I can not say "There is no problem!" so far.

I sould figure out what case that block will be executed in, and test
if such conversion block can be replaced with mbstowcs() actually.

I will appreciate any help from you all.

Thanks.


On Wed, 9 Mar 2022 00:21:28 -0800, Bill Kendrick wrote:
>On Wed, Mar 09, 2022 at 01:13:23AM +0100, Pere Pujal i Carabantes wrote:
>> El dg. 06 de 03 de 2022 a les 22:40 +0900, en/na Shin-ichi TOYAMA va escriure:
>> > Hi!
>> > 
>> > I have been thinking it is strange that there are some amount of specific code to convert wide charcter strings to utf-8 strings in render_text_w() from line 1665 to 1740.
>> > 
>> > -----------------------------------------------------------------
>> > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */
>> > 
>> > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1));
>> > utfstr = (char *)malloc(utfstr_max);
>> > memset(utfstr, 0, utfstr_max);
>> > 
>> >   < ... many lines ... >
>> > 
>> > utfstr[j] = '\0';
>> > -----------------------------------------------------------------
>> > 
>> > Here, we need to use '#ifdef WIN32' to cope with the difference in length of wchar_t between windows and other platforms.
>> > 
>> > I looked here again, then I have become confident that we can replace all this block with wcstombs() which became safe also on windows by defining it as a native conversion function WideCharToMultiByte().
>> > 
>> > -----------------------------------------------------------------
>> > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */
>> > 
>> > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1));
>> > utfstr = (char *)malloc(utfstr_max);
>> > 
>> > wcstombs(utfstr, str, utfstr_max);
>> > -----------------------------------------------------------------
>> > 
>> > How do you think of it?
>> > 
>> 
>> Looks much more clear, I don't know why that code was needed but seems wcstombs() currently does the same thing
>> Note that I've just tested your approach in Linux.
>> 
>> My 2 cents
>> Pere
>
>Thanks, you two!  This stuff is a bit outside my expertise
>(and I'm also very busy with some big changes at my day job,
>so my brain is pretty fried by the evening, when I can spend
>any time on Tux Paint :-D )... so I appreciate your efforts.
>
>It would be good, of course, to make sure changes work as
>expected.  Alas, we don't have any kind of unit testing
>in Tux Paint, so it would have to be manual.
>
>So perhaps we can put together a list of things to test,
>and the process to test each.  For example, say:
>
>Test 1
> * Create 1 label using basic ASCII
> * Save image
> * Load image
> * Confirm label is correct
>
>Test 2
> * Create 1 label using multibyte characters
> * Save image
> * Load image
> * Confirm label is correct
>
>Test 3
> * Create 1 label using ASCII
> * Edit label using ASCII
> * Save image
> * Load image
> * Confirm label is correct
>
>...and so on.
>
>I suppose if it were to be put into a big matrix, the things
>I'm concerned about are:
>
> * does it work properly in ASCII? with multibyte? mixed?
> * does it work properly with one label? multiple labels?
> * does it work properly after editing a label?
>
>And we'd want to ensure it works on our currently-supported platforms:
>
> * Linux
> * Windows
> * macoS
> * Android
> * Haiku
>
>Of course, I welcome any other ideas (or alternatives) here!
>
>Thanks!
>


-- 
Shin-ichi TOYAMA <dol...@wm...>