Embed and use Noto for displaying Japanese characters

[Gnurou]

Relying on system fonts creates in an inconsistent experience for many users: some have Chinese variants of the characters displayed, others have ugly fonts, some finally have no Japanese font installed at all.

Embed the Noto font into the binary and use it for all Japanese characters. Remove the setting allowing to set a custom font. This way all users will have the same experience and characters will always be displayed as they should.

[rainbyte]

If fonts are included, then it would be useful to have at least some variants, eg. a Kai font could be used as alternative to see how characters should look when using a fudepen to write them.

There is a list of font types here. Of course, maybe not all of them are needed to study.

[Gnurou]

I feel like the study of variants could be an extra feature (i.e. "See variants for this Kanji"). For this we could actually use the KanjiVG data, which is rather complete in that regard. We are not using these at all at the moment. Feel free to open a new issue to track this.

We could even fude-handwriting animations using KanjiVG, since we have the strokes layout and their type. This would be a fun project, but not one I am willing to undertake for now. ;)

This issue is more about how kanji/kana should look like for regular search and study. I'd like to have something standard, consistent, and good-looking in order to not confuse beginners with non-standard kanji (or worse, squares all over the place). In other words, everybody should see the same thing, and it should be the accepted character variant for standard Japanese. Noto perfectly fits the bill here.

[Gnurou]

Btw, thanks for the link - I have learned a few things while reading it!

[rainbyte]

I didn't know KanjiVG had this kind of information. I will read a bit about that before opening an issue.

Thanks for the information :)

[Arfrever]

Noto fonts are likely to be already installed as system fonts (at least on decent GNU/Linux systems).

Noto fonts are huge. In newest version of Noto, Noto*CJKjp*.otf files have total size 318 MiB:

-rw-r----- 1 root root 17M 2015-06-15  NotoSansCJKjp-Black.otf
-rw-r----- 1 root root 17M 2015-06-15  NotoSansCJKjp-Bold.otf
-rw-r----- 1 root root 16M 2015-06-15  NotoSansCJKjp-DemiLight.otf
-rw-r----- 1 root root 16M 2015-06-15  NotoSansCJKjp-Light.otf
-rw-r----- 1 root root 16M 2015-06-15  NotoSansCJKjp-Medium.otf
-rw-r----- 1 root root 16M 2015-06-15  NotoSansCJKjp-Regular.otf
-rw-r----- 1 root root 15M 2015-06-15  NotoSansCJKjp-Thin.otf
-rw-r----- 1 root root 17M 2015-06-15  NotoSansMonoCJKjp-Bold.otf
-rw-r----- 1 root root 16M 2015-06-15  NotoSansMonoCJKjp-Regular.otf
-rw-r----- 1 root root 22M 2017-09-20  NotoSerifCJKjp-Black.otf
-rw-r----- 1 root root 24M 2017-09-20  NotoSerifCJKjp-Bold.otf
-rw-r----- 1 root root 21M 2017-09-20  NotoSerifCJKjp-ExtraLight.otf
-rw-r----- 1 root root 23M 2017-09-20  NotoSerifCJKjp-Light.otf
-rw-r----- 1 root root 23M 2017-09-20  NotoSerifCJKjp-Medium.otf
-rw-r----- 1 root root 23M 2017-09-20  NotoSerifCJKjp-Regular.otf
-rw-r----- 1 root root 23M 2017-09-20  NotoSerifCJKjp-SemiBold.otf

Embedding Noto fonts would significantly increase size of Tagaini Jisho tarball.

I suggest that Noto fonts not be embedded, but instead be highly recommended to be installed. If Noto fonts are missing, then Tagaini Jisho could display a warning at startup.

Setting allowing to set custom font could be preserved, so that user can choose between e.g. different variants of Noto fonts (e.g. sans-serif versus serif, bold versus light).

[Gnurou]

For our use we only need the NotoSansJP Regular font: https://github.com/googlei18n/noto-cjk/raw/master/NotoSansJP-Regular.otf

A mere 4MB that is enough to cover all our needs. Perfect display even on systems without any Japanese font.

Another option would be to check the availability of Noto at runtime and propose to download it if it is missing, but given my inconsistent activity on this project these last years I'd rather go for the least-hassle path towards a quite overdue new release.

[Golutazem]

'displayed as they should' should be the users typefaces and the ones set up in the program. This is feature change would be more detrimental than beneficial. Another problem is that it creates more duplicate files or more effort on the part of packagers to remove duplicates.

Providing users a list of good looking free typefaces could be good though.

[rainbyte]

Maybe checking if some font is available, and displaying a warning otherwise, would be enough for a good user experience.

The warning msg could recommend some good looking font or refer the user to system documentation (e.g. Arch wiki)

[Golutazem]

If the typeface specified by the user (possibly configured at the level of the desktop environment) is unavailable, then yes, it would be good to display a warning rather than silently using a fallback typeface. Also if TagainiJisho attempts to display a glyph which does not exist in the user's typeface, it would be beneficial to issue a warning.

From the Documentation for the QFont class:

If a chosen font does not include all the characters that need to be displayed, QFont will try to find the characters in the nearest equivalent fonts. When a QPainter draws a character from a font the QFont will report whether or not it has the character; if it does not, QPainter will draw an unfilled square.

If the documentation is accurate, Qt does support notification of the application (TagainiJisho) in case of these problems.