[ENHANCEMENT] Prepare Chinese translation

[RunzeJustin]

A month ago I assembled a Prusa Mini clone printer for my sons, they like it very much. Thank you!

The only problem is that my sons are still young and doesn't understand English very well, so I'm going to do some Chinese translation for them and contribute to the community.

It's already working on my printer, but there's still a lot of work to be done to contribute to the community, mostly font-related issues:

1) Based on the current font struct, I can only create a font bitmaps that forces a fixed-width (monospace) in both ASCII and Unicode. As you can see, letters don't look good (I didn't change the footer font), should we keep the font description for each glyph such as width, height, offset, advance and so on?

2) GuiDefaults.hpp defines 5 font_t variables: FooterFont, Font, FontBig, FontMenuItems, FontMenuSpecial, but the code is still full of resource_font calls, shouldn't we use GuiDefaults:: instead of resource_font calls?

static font_t *FooterFont;
static font_t *Font;
static font_t *FontBig;
static font_t *FontMenuItems;
static font_t *FontMenuSpecial;

3) Defining multiple font bitmaps of different sizes is fine for ASCII, but it makes the firmware larger for CJK fonts, can we consider using only one size font? If so, then we need to adjust the screen layout. You decide.

4) Unicode Line Breaking Algorithm http://www.unicode.org/reports/tr14/

Any suggestions?

[JakoobCZ]

Hi, Justin, this is a great effort for the community! I'm sure there can be more members to benefit from this. I will try to get answers to your questions, but the developers are still extremely overloaded (covid, new printers, chips replacements). I suggest starting a thread on our forum.prusa3d.com, maybe there will be some community devs, who can help. Let me know I can pin your comment up, so it is visible 😉

[RunzeJustin]

Hi @JakoobCZ , thanks for your reply, I agree with your suggestion 😉

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[danopernis]

Hi @RunzeJustin and sorry for taking so long. I would love to see a Chinese translation from community. We have recently added support for Japanese, so some of your requests may already be resolved. But feel free to suggest what should be done to support Chinese as well.

[RunzeJustin]

@danopernis that's good news, and there is no difference in implementation between Chinese, Japanese, and Korean translations, so if the Japanese translation has been realized, then the Chinese & Korean translation is very simple.

Like katakana characters, Chinese characters are closer to square in shape too, 16×16 will work well on a 2.8-inch screen.

[michalrudolf]

Hello @RunzeJustin, great work! I think we can work our way to complete chinese translation, there are just some hurdles on the way. First of all, these are the fixed-size fonts we use in our printers:

MINI with smaller display 240x320 - Fonts in japanese build configuration also contain Katakana characters:
        font_regular_7x13 //Font::small
        font_regular_11x18 //Font::normal
        font_regular_9x16 //Font::special
Other printers with bigger display 480x320 - Fonts have all possible characters:
        font_regular_9x16 //Font::small
        font_bold_11x19 //Font::normal
        font_bold_13x22 //Font::big
        font_bold_30x53 //Font::large <-- only digits

We use statically initialized sizes wherever we can, avoiding runtime computation. In case of Japanese, because the font sizes are so small and number of Kanji characters is so vast, we went with 'Katakana only' and squeezed it in the rectangle space of the original font sizes. So every font bitmap contains every character, that is needed throughout the FW. This means that we can switch between any implemented language without change of text rectangles and layouts in GUI and we don't have to worry that much about cropped / truncated texts.

Katakana is a small set of simple characters and using font bitmaps is still advantageous. For CJK fonts this approach is, as you said, very costly. Do you know how many unique characters there are in chinese translation?

1) I would still prefer fixed sized font, than computing the text rectangle sizes in runtime. 2) Yes, ideally all resource_font calls would be replaced with GuiDefaults:: pointers. 3) If we need at least 16px width chars (as you recommended), that is bigger than the biggest font on MINI - that will take some effort in GUI layout impelementation anyway. Single font is probably the best approach since we want the characters to be as small as possible and still well readable - having smaller font is not possible and bigger fonts will take a lot of space in the memory. 4) This is an another challange awaiting. Right now we use character-based approach but I can see, it won't be enough for chinese.

We have a very talkative printers (there are many long texts and messages) and 240x320 is not much space. Is the 16x16 px the lowest we can go for it to be still well readable?