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

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

Thanks pere,

I looked around it again.

The function render_text_w() looks like to be called only from text/label tools,
and the process never go into the block "if (font->typ == FONT_TYPE_PANGO)" in it.

If it is correct, there is no need to do somethinge here currently.


On Tue, 15 Mar 2022 07:54:46 +0100, Pere Pujal i Carabantes wrote:
>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


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