kanjivg
kanjivg copied to clipboard
KanjiVG
Stroke order of \u6500 攀 is a mess
The text numbers are in the right place, but any relation between the position of the numbers and the actual order of the strokes is largely random.
Out of 19 strokes, the first stroke that is in the correct order is 13. Everything before that looks like it went through a blender.
Anyway, here's my attempt to reconstruct the order of the strokes as they appear, relative to how they are supposed to be: 5 6 11 12 1 2 3 4 7 8 9 10 13 14 15 16 17 18 19
It looks like things first went wrong at 909dc32f523008b81fa242e31007e1b07f41d031, and then went downhill from there. It might be worthwhile to check other kanji in the same commit, to see if they suffered similar disasters.
Indication is that it is, as I am seeing a wrong order for 樊 \u6a0a as well
As far as I can tell the stroke order was a mess both before and after that commit.
@benkasminbullock I could tell it was a regression because the order appears correctly here: https://mojinavi.com/d/u6500
That commit is the first one to reorder the strokes, causing them to be out of order. Later commits farther reorder the strokes, making them more and more random.
Unfortunately, there's no tool for easily seeing the stroke order at a revision, as that requires messing with the CSS, or adding SMIL tags.
There is this: https://www.lemoda.net/kvg/06500.svg
I checked out the commit prior to that and looked at the stroke order with the above viewer, and it didn't look right. Anyway it should be easy enough to sort this out.
This should resolve the issues with 06500 and variants:
https://github.com/KanjiVG/kanjivg/commit/682d4d4ce34a15243c217dde3ec691bc764381a6
It's very much not. https://kakijun.jp/page/hant15200.html
Order should be X-X-tree-tree-big. Same for 礬
The groupings and types are OK anyway, I don't really have a reference for the stroke order at the moment. There are some issues with the groupings of 礬.
https://github.com/KanjiVG/kanjivg/commit/8a38cf28d835007de285a46bc523c64b157936f0 fixes the errors with the strokes in 0792c and also tidies up the upper right tree in the 06500 variants.
I'll hold off altering the stroke order of any characters from what was in KanjiVG originally until we get a better reference than the web sites, since those might also contain errors.
Incidentally could you try to write better bug reports than "been through a blender" or "is a mess", it's difficult to take action on that kind of bug report? Thanks.
I agree that an authoritative source on stroke orders is necessary, but I'm also unsure as to what that would be. JIS tables (which are already hard enough to obtain) generally only contain character images, and do not give stroke order guides. I have difficulty determining what, if any, authority determines what stroke order is "correct".
I have difficulty determining what, if any, authority determines what stroke order is "correct".
You're the person claiming the current stroke order is incorrect. Ulrich Apel has discussed what references he used to make the characters originally on the mailing list, and as far as possible I've copied that on to the references page on the documentation:
http://kanjivg.tagaini.net/ref.html
You could try asking again. I don't want to. At the moment it looks like we only have a reference for the 教育漢字 part.
The problem with copying from web sites is that web sites are sometimes wrong, and sometimes the different web sites just copy one from the other. When I found several discrepancies between KanjiVG and Kanjidic, I checked them using various websites and got some pushback from Jim Breen, who uses the JIS 漢字字典 as a reference. It was clear that some of the web sites seemed to be copying each other. Similarly there are some errors in Wiktionary which can only be from copying from other web sites. So if KanjiVG's original stroke order is based on a source or another we should try to find that. But it may be that the order with 木 as the first element is just a guess based on the left-to-right rule, in which case the XX first rule is probably better.
At the moment the stroke order of 06500.svg seems to be what was requested initially in this bug report, and the report has been left open due to a debate about 06a0a.svg.
We don't have a proper source for 06a0a.svg but it seems reasonable to make it consistent, so I've done that in 8380df2cc. Please reopen if not satisfied.