Japanese text rendering in web browser

[oimaasi]

This is an issue I ran into at the very beginning of installation. Yaft is compiled with the default milkjf font. Japanese texts are displayed correctly in the terminal itself. However, if I open a text-based web browser (in my case, Links), both Kanji and Hiragana are not rendered correctly. See the middle of the right pane. Left pane is the terminal for comparison. It seems that double width fonts are not handled correctly?

The same with wqy-unibit.

More confusingly is the fact that even in the same webpage, SOME of the Japanese texts are rendered correctly. See here

BTW, what browser does developer use or would he recommend? I have been struggling to find a suitable web browser for a long long time, especially for non-graphical environment.

[oimaasi]

Not directly related to the issue, but maybe here is the proper context to note the complicated topic of Kanji support. Just for people who may come cross this topic in the feature.

Here again is the rendering result of the default milkjf font. With a native Japanese font, Japanese text rendering is as expected much better than Wqy. Kanji and Hiragana/Katagana now harmonize with each other very well. It even seem to support most of the typical Chinese Kanji, both simplified and traditional, although probably not complete. But its limitation becomes obvious when dealing with Cantonese.

Here as comparison, the Wqy-Unibit font rendering the same text. Something is not totally alright with the Japanese text (???), but I am not an expert in judging this topic. But it seems that the font baseline is not set correctly?

We may merge a native Japanese font with a Chinese one, so that each can cover its own native range. However, as far as I know, Japanese Kanji share some common subset with both simplified and traditional Chinese Kanji. Do these characters also share the same unicode (probably yes?)? If so, the final result would always look weird and kind of annoying, because a few individual characters are subtly different.

One feasible solution would be using a true Pan-CJK font which covers all the existing Kanji in the world, like Hanazono Mincho and Noto Sans CJK. However, those fonts only exist in ttf/otf format, and as pointed out by @uobikiemukot in another thread, it's not trivial, if not impossible, to obtain a satisfactory bitmap font from a direct true type conversion.

I know this is a niche use case and most people won't ever need that. But if anybody happen to see this thread and have an idea, please say. Thanks.

[uobikiemukot]

1. text rendering glitch in Links
   (Maybe) Japanese character sets are not treated as double width in Links. Please check rendering in other browser like w3m (w3m is my favorite browser).

2. Japanese text in Wqy-Unibit
   baseline is not correct (BDF font problem) or bug of yaft's mkfont_bdf. Some Chinese Kanji and Jananese Kanji share the same unicode codepoints (see wikipedia). I'm not sure what glyph you feels strange about...

Essential solution to use ttf/otf fonts, is to support freetype rendering. fbterm and mlterm-fb has the functionality. Especially mlterm supports various multi-language features (for example bultin input method module for ibus, uim, scim etc...)

[hackerb9]

I would guess it is a double-width / half-width problem in Links. What happens when you use a bi-width font? I don't read Japanese, but text looks good to me in w3m using the font "b24" from efont-unicode-bdf.