Re: [Tuxpaint-devel] Font scoring method

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

My current conclusion is not to add Japanese characters to the ASCII strings for scoring, and to give up showing the fonts supporting Japanese characters on top.

If I add more than two Japanese characters, for example, to 'Oo', this will disable scoring for the fonts which does not support Japanese characters based on case distinction. And this will be the same for any other category such as line-llike, circle-like and so on.

This is not the result I want to see.

I just wanted to see the locale fonts on top, and leave the other scoring as they are.


On Sun, 18 Dec 2022 14:24:36 +0900, Shin-ichi TOYAMA wrote:
>Thank you again!
>
>I noticed that there is a quite bad side effect in "ABC...xyz" approach 
>that it overly score the fonts which render the string correctly if the 
>string is not translated.
>
>Then, I reverted dirwalk.c. Sorry for the mess.
>
>By the way, I have not still understand well why the evaluation string 
>are separated to some categories like 'cases', 'line-like' and so on.
>
>Because of this, as pere pointed out, just adding Japanese characters to 
>just one category may not push it on top, therfore, I suppose that I 
>have to add them to multiple categories, if I want to see them on top.
>
>In addition, I still feel a little unconfortable that there is no 
>suitable existing category for Hiragana and Katakana, although I know it 
>does not matter where to put them.
>
>However, I will do what I have to do in the existing method so far.
>
>Thanks.
>
>
>On Sat, 17 Dec 2022 21:39:53 -0500, Albert Cahalan wrote:
>>> I understand adding locale characters to the existing criteria works.
>>>
>>> However, I am a little at a loss where to put them, because;
>>>
>>>  * Japanese has no upper/lower cases distinction.
>>>  * No common/special Japanese panctuations is used in Tux Paint.
>>>  * Numbers are not different to those in ASCII.
>>>  * It has no line-like/circle-like characters.
>>>
>>> In addition, I think it would be reasonable to give high priority to the
>>> fonts supporting locale specific characters.
>>>
>>> I've pushed the change already, and would like to keep it if this has no
>>> side effect.
>>
>>I would prefer the original design. It is not beneficial to have
>>a second string that is redundant. This only makes the code
>>more confusing for translators to use.
>>
>>In the original design, the only flaw I can see is that the
>>intended usage was not documented very well.
>>
>>The entire reason to have the string be translated with gettext was
>>to support languages like Japanese. It was meant for you to use.
>>If there are now two strings, why would the original one need to be
>>translated at all? This does not make sense.
>>
>>It doesn't matter that Japanese lacks uppercase/lowercase,
>>has no line-like or circle-like characters, or shares numbers
>>with ASCII. You should simply add Japanese characters.
>>Leave the ASCII characters too, if it is at all reasonable for
>>a Japanese person to use them.
>>
>>So to summarize proper usage:
>>
>>Add characters that matter, choosing a few that are most likely
>>to be missing or indistinct. Remove any characters that have
>>no value at all. Most likely, you add characters but do not remove
>>any characters.
>>
>>My suggestion for Japanese specifically:
>>
>>Leave the ASCII. Add two katakana, two hirigana, and two kanji.
>>Add the Yen symbol. Maybe add the Yuan symbol, in case there
>>are fonts that unify them. If there exists a pair of characters that
>>appear distinct in a good Japanese font but might be identical or
>>missing in a Chinese or Korean font, be sure to add them.
>>
>>It is highly likely that multiple translators have make mistakes.
>>Nearly all translations should retain the ASCII, adding a few
>>new characters.
>>
>>For example, German should add:  ẞßβÖö€
>>That prefers fonts that distinguish lowercase eszett
>>from beta (a Greek letter) and uppercase eszett.
>>
>>
>>_______________________________________________
>>Tuxpaint-devel mailing list
>>Tux...@li...
>>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>
>


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