Skip to content

Conversation

@yquemener
Copy link

So this ended up impacting more files than my previous PR proposal, but I feel in a lighter way as it just proposes an optional parsing at the beginning of on_receive_fields(...) functions. It adds an optional dependency to a mod that is basically one function, utfparse.parse(text), that I will probably need to use a lot until Irrlicht's UI is fixed.

If you don't like adding a dependency, I can just add the function in a file but it will need to be repeated in each mod that provides on_receive_fields(...) functions.

@pyrollo
Copy link
Owner

pyrollo commented Sep 10, 2019

Hi,

I did not find a proper way to test your PR. Can you provide a example of what to enter in formspec in order to display wanted chars ?

I tried a copy paste from google translate but it uses the "\u" form which is not parsed. Or actually behaves quite strangely: if I put "\u6e2c", signs displays "\u6e2c". But if I reopen the formspec, the "" is gone, only "u6e2c" is left.

@yquemener
Copy link
Author

Sorry about that. Here is a sample string:
日本語

It should display as 日本語

Another one:
ça c'est l'été!

Should show as
ça c'est l'été!

You can generate such string with that tool:
https://github.com/yquemener/utfparse/blob/master/tools/UnicodeConverter.pyw

In order to display Japanese characters correctly instead of the blank rectangle characters, you also need a Japanese font like this one: https://github.com/yquemener/font_jp_noto, and to select the appropriate font in the sign formspec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants