stroke-input
The mainland standard stroke order for characters such as 攀, 鐢, 燓 etc ls different to yours
the top component in characters such as 攀, 鐢, 燓 is written from left to right in the mainland standard, i.e. according to zdic etc. I.e. it starts with:
123434341234... Whereas you have the stroke order starting:
343412341234...
i.e. you are writing the central 爻 before the two trees.
This has come back to haunt me. It also affects 學覺..., 興釁..., 與舉..., etc., which are also currently recorded with centre-first sequences.
While it is a simple matter for 攀鐢... and 學覺..., it's complicated for 釁... and 與舉...:
-
For 釁 etc., the following alternatives are allowed for the top-middle:
-
112(HK, TW): ⿱一丅. The top middle is effectively ⿵冂〒. -
151(Kangxi): ⿱一コ. The top middle is a reduced (5-stroke) form of 同. -
1251(common): ⿱一口. The top middle is 同.
-
-
For 與, 舉, etc., the top-middle is leniently recorded as
1(5|25)(2|3):-
(5|25)to allow for ㇉ (in 1 stroke) or ㇑㇆ (2 strokes) -
(2|3)to allow for ㇑ (HK) or ㇓ (TW)
Actually now that I think about it, I should probably generalise this to
(15|51|125|251)(2|3). -
The question I asked myself at the time was, is it worth the hassle of allowing left-first in addition to centre-first given that the centre has variations? I decided the answer was no.
The centre having variations certainly complicates things.
However this is certainly the best input method I have come across for a mobile phone. I actually use it for inputting to my computer via kdeconnect as I find it easier than any of the ibus options. I am compiling an electronic dictionary that can easily interface with the AnkiDroid learning program and one of the attractions is the vast number of characters your method can access. Missing characters is a serious drawback of many other methods. Coming back to the left to right input option. I regularly attend a Mandarin conversation meeting. A number of teachers also attend. I would suggest they recommended your method to their pupils. However, since they teach to the mainland standard they might not be very enthusiastic if the left to right input is not catered for.
I will have a think about this. I was a professor of software engineering until I retired when I became seriously Ill 25 years ago. I haven't done much since the except write the odd shell script, but I might be able to help in some way.
Thanks for all the work you have put in.-- Sent with Tutanota, enjoy secure & ad-free emails.
6 Aug 2022, 5:52 am by @.***:
This has come back to haunt me. It also affects 學覺..., 興釁..., 與舉..., etc., which are also currently recorded with centre-first sequences. While it is a simple matter for 攀鐢... and 學覺..., it's complica DuckDuckGo> removed 1 tracker. More > →
This has come back to haunt me. It also affects 學覺..., 興釁..., 與舉..., etc., which are also currently recorded with centre-first sequences.
While it is a simple matter for 攀鐢... and 學覺..., it's complicated for 釁... and 與舉...:
For 釁 etc., the following alternatives are allowed for the top-middle:
112> (HK, TW): ⿱一丅. The top middle is effectively ⿵冂〒. 151> (Kangxi): ⿱一コ. The top middle is a reduced (5-stroke) form of 同. 1251> (common): ⿱一口. The top middle is 同.
For 與, 舉, etc., the top-middle is leniently recorded as > 1(5|25)(2|3)> :
(5|25)> to allow for ㇉ (in 1 stroke) or ㇑㇆ (2 strokes) (2|3)> to allow for ㇑ (HK) or ㇓ (TW)
Actually now that I think about it, I should probably generalise this to > (15|51|125|251)(2|3)> .
The question I asked myself at the time was, is it worth the hassle of allowing left-first in addition to centre-first given that the centre has variations? I decided the answer was no.
— Reply to this email directly, > view it on GitHub https://github.com/stroke-input/stroke-input-data/issues/7#issuecomment-1207146454> , or > unsubscribe https://github.com/notifications/unsubscribe-auth/AWED2CGQL3OWHI7RKTZLWZDVXXVQHANCNFSM55J237RA> . You are receiving this because you authored the thread.> Message ID: > <stroke-input/stroke-input-data/issues/7/1207146454> @> github> .> com>
Fixed by various commits merged in a8056eefab555a27c01bb9bb8a57e12be0bc7a42.