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

[Pere P. i C. <per...@gm...>]

Seems Pango is only used for the UI currently and not for Text and Label tools.
https://sourceforge.net/p/tuxpaint/bugs/232/

HTH
Pere

El 15 de març de 2022 4:58:15 CET, Shin-ichi TOYAMA <dol...@wm...> ha escrit:
>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...>
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel