A Question About Using Multiple Character Set Fonts Simultaneously

[LiwareTech]

A Question About Using Multiple Character Set Fonts Simultaneously

Hello, I'm a developer currently working on a music player. First of all, thank you for your contributions to U8g2lib and for taking the time to read my question amidst your busy schedule.

I am currently facing some issues, such as many song titles and lyrics extending far beyond the GB2312 character set, even including Japanese and Korean characters (in fact, while the u8g2_font_wqy13_t_gb2312 character set includes some Japanese kana, it still lacks Japanese kanji like "僕"). This results in missing characters and incomplete display when showing lyrics like "ハロー、セカイ 僕（ぼく）の声（こえ）はちゃんと届（とど）いてるかい".

I haven't yet found a suitable method to handle the display of such a diverse range of characters. I have a small suggestion: for instance, adding a font that supports Unicode (or a font file that supports the complete CJK character set would also work, since MCU Flash sizes are quite large nowadays—for example, my ESP32-S3 has an external 32MB Flash, which should be sufficient to store a CJK font set). Alternatively, it might be possible to use multiple font files simultaneously (which I refer to as pre-selected fonts) by adding an AddFont() function. Then, when using setFont(xxx), the pre-selected fonts could be cleared, and only the xxx font would be used.

If this method is difficult to implement, I apologize for taking up your time. If it is feasible, however, I would be delighted to see this potentially groundbreaking update in the near future.

Once again, thank you and thank you for your library, U8g2lib.h.It has been a tremendous help to me.

(This text was translated by AI. I apologize for any grammar errors that may have occurred.）

Love From China.

[olikraus]

My suggestion would to go ahead with a single complete font and see whether it fits into your micro controller.
The first step would be to find a suitable bitmap font (available as ttf or bdf), which includes all the desired glyphs.
Then second we could create a complete u8g2 font out of it.

[LiwareTech]

Thank you for your response. But the link you sent shows 404 Not Found. Do you have any other links?

Looking forward to your response

[RedGreenGeek]

The broken link is likely to this file
You can see the limited character set here

[LiwareTech]

Thank you for your reply!

I have tried using u8g2_font_wqy12_t_gb2312, but compared to the entire Chinese character system (simplified characters, traditional characters, Japanese kanji, Korean hanja, Vietnamese chữ Hán, etc.), these 6,000‑odd characters are still too few. In fact, to meet the needs of this product (since you cannot predict how users will use it, you also cannot guess which characters are absolutely necessary), it would be best to cover the vast majority of characters that might be used—for example, by using the complete CJK character set from Unicode (AI‑based calculation: about 90,000 Chinese characters require 1.8 MB; even with punctuation, English characters, Japanese kana, and Korean hangul added, it should not exceed 2 MB).

This is perfectly feasible within the 32 MB Flash. However, the current problems are: first, I personally do not yet have a good method to produce such a complete character set; second, reading such a large amount of data would take a long time. Therefore, to speed things up, the font library must be placed in PSRAM, or an index must be built in RAM at each startup. Both approaches would require modifying the library code to change the corresponding logic (this should be the case), which is beyond my ability to accomplish.

If you could offer a good solution or if someone could help me, I would be very grateful. If this idea can really be implemented, it could bring great convenience and benefits to China, Japan, Korea, and indeed all countries that use the Chinese character system.

Thank you again for your reply.

LiwareTech
Written on December 14, 2025

[LiwareTech]

Thank you for your reply!

I have tried using u8g2_font_wqy12_t_gb2312, but compared to the entire Chinese character system (simplified characters, traditional characters, Japanese kanji, Korean hanja, Vietnamese chữ Hán, etc.), these 6,000‑odd characters are still too few. In fact, to meet the needs of this product (since you cannot predict how users will use it, you also cannot guess which characters are absolutely necessary), it would be best to cover the vast majority of characters that might be used—for example, by using the complete CJK character set from Unicode (AI‑based calculation: about 90,000 Chinese characters require 1.8 MB; even with punctuation, English characters, Japanese kana, and Korean hangul added, it should not exceed 2 MB).

This is perfectly feasible within the 32 MB Flash. However, the current problems are: first, I personally do not yet have a good method to produce such a complete character set; second, reading such a large amount of data would take a long time. Therefore, to speed things up, the font library must be placed in PSRAM, or an index must be built in RAM at each startup. Both approaches would require modifying the library code to change the corresponding logic (this should be the case), which is beyond my ability to accomplish.

If you could offer a good solution or if someone could help me, I would be very grateful. If this idea can really be implemented, it could bring great convenience and benefits to China, Japan, Korea, and indeed all countries that use the Chinese character system.

Thank you again for your reply.

LiwareTech Written on December 14, 2025

But there is another approach: as I mentioned earlier, loading multiple character sets simultaneously, such as u8g2_font_wqy12_t_gb2312, u8g2_font_b12_t_japanese1, u8g2_font_b12_t_japanese2, u8g2_font_b12_t_japanese3, u8g2_font_unifont_t_korean1, u8g2_font_unifont_t_korean2...
This should also alleviate the problem to some extent, even though there will still be many characters that cannot be displayed. However, both this solution and the previous one require major modifications to the library's display functions. Compared to the previous method, this approach would obviously involve less work. I still want to thank you for your contributions to U8g2lib. Thank you to all developers like you who possess the spirit of selfless open-source contributions; it is people like you who have built such a vast open-source ecosystem. Thank you.

[olikraus]

reading such a large amount of data would take a long time

The only problem I see here, is this: U8g2 is probably not optimized to lookup in glyphs in a table of 90000 chars.
But I don't think this can be solved with relocation of the font data. For this a new font structure would be required (kind of a binary search or so).