Stroke recognition (again)

[sl08154711]

Had to revert the changes in FdroidSettings and made a mess. New pull request should fix everything you suggested.

[syt0r]

Hmm, I did some test, it works pretty good with straight lines but it's quite strict with characters like み、ひ、, kana with handakuten ( ﾟ ) like ぺ、and the stroke before the last from 級. Do you think it can be made more forgiving?

[sl08154711]

Got me! I didn't test hiragana with handakuten. It is a bit tricky but certainly far from impossible. Turns out the character ぺ has the following two strokes:

<path stroke="#000000" stroke-width="3" fill="none" d="M15,48.75c2.25,1.62,4.67,1.96,7-0.38c3.62-3.62,7.46-6.54,11.25-10.5c5.5-5.75,8.48-4.75,13.12-0.88c12.12,10.12,30.38,25.12,33.38,27.38c3,2.26,12.38,10.38,13.88,11.63"/>
<path stroke="#000000" stroke-width="3" fill="none" d="M73.63,36.75c-9.62,0-9.25-14.25,0-14.25c9.75,0,9.5,14.25,0,14.25"/>

Obviously, the first one is へ and the second one is the handakuten. Here we have an absolute move command followed by two Bézier curves. The first curve moves upwards, the second down again (two half circles). If you watch the stroke animation in the app you can see this, too. I couldn't get the algorithm to recognize the handakuten either but armed with that knowledge I tried again:

https://github.com/syt0r/Kanji-Dojo/assets/153142614/f31a2d3a-a384-4d9a-91ab-0a4d42af5144

If my handwriting passes a test, this test must be very forgiving.

As for 級: this is a very good example. Here the algorithm struggles to detect a correct stroke (second to last). I thought about it, tested it myself and found that I am a bit stupid. The algorithm tests if all segments (produced by approximateEvenly) of a stroke are in the correct position (give or take a few pixels) and then tests if the segments of a stroke are drawn in the correct direction but since all segments (start and end point of it) are already tested, the direction is implicitly tested, too. So the test for correct direction is basically redundant.

Second problem is path length: if the path drawn by the user does not have the same length as the correct stroke, it does not matter as long as the stroke is mostly straight but with too squiggly paths each segment has to be of correct length because otherwise the path is sampled at different positions. Maybe before or after a change in direction (as with the second to last stroke of 級). I have no solution to this, yet. I will think about it.

Lastly, how forgiving should the algorithm be? I mean, as a user I want to learn kanji and not just pass a test. So I would argue the algorithm should be you worst nightmare and not at all forgiving (except for the cases where the algorithm is just wrong as with 級). To demonstrate I made another video:

https://github.com/syt0r/Kanji-Dojo/assets/153142614/c963b9e6-7dfc-44a6-af69-f358050084b8

So, if a user is just starting to learn kanji they can use the relaxed, original algorithm and practice for a bit and when they want to improve their handwriting, they can use the alternative algorithm. That's also why I didn't want to replace your algorithm. Maybe you rename it to "hard mode" or something along these lines.

Anyway, I will change the algorithm to address the issue above as soon as I have an idea on how to fix it. Might be a few days.

[syt0r]

I was thinking that main goal of this feature was to deal with the issue of unrecognized strokes #75, but your algorithm feels stricter than the default one. I don't mind having multiple algorithms so we can leave this implementation.

Overall regarding strictness, when I was developing my algorithm I didn't want to force users to draw calligraphically correct strokes and focus more on remembering their general shape and position so I tried to make it quite forgiving to appeal more to general public and cause less frustration because there is a lot to learn