Mismatch for stroke count and stroke order for 餅「もち」 -- breaks kanjipad search?

[jmillikin]

「もち」 has two forms, one with 15 strokes and one with 14.

The dictionary entry for this kanji shows "strokes: 14", but has 15 stroke order pictures.

This seems to break Kanji recognition. Neither form can be found in Kanjipad.

[mvysny]

This is a well-known problem, unfortunately. The kanji 餅 is rendered differently with Japanese font than with Chinese font. The Japanese glyph differs from the Chinese glyph, yet they are mapped to the same unicode codepoint. The Japanese version has 14 strokes; the Chinese one has 15.

If you notice, Aedict correctly uses Japanese font to display the kanji itself (at the top of the first screenshot). Yet, to display the stroke order diagram, it uses the output of the KanjiVG project which apparently uses the Chinese glyph version.

Please feel free to inform the KanjiVG guys at http://kanjivg.tagaini.net/ to change their glyph from Chinese version to Japanese version.

Regarding the kanjipad not finding the kanji: that may actually be a limitation of the internal kanjipad: it may not have this kanji in its database at all. We're discussing this at #807 - please try the Kanjipad Extension or please try drawing the kanji at https://aedict-online.eu/#!kanji-search

[mvysny]

This page shows the correct Japanese glyph (as a picture, so it should be always correct): http://www.fileformat.info/info/unicode/char/9905/index.htm . On the other hand, my system's locale is set to EN/US and thus probably preferring Chinese characters, and thus this issue shows the Chinese character:

[mvysny]

No activity for a month, closing.