Stroke order of 娩 is suspicious

[SlugFiller]

The diagonal line (stroke 8) appears ahead of the box close (stroke 9). Compare with 挽兔俛, where the order is the opposite

[benkasminbullock]

It looks like you're referring to kanji/05a29-Jinmei.svg? The non-variant forms of those characters have the same stroke order, and the diagonal line in 娩 is stroke 9. I don't know why the Jinmei version has a different stroke order.

[SlugFiller]

Ah, seems like it was fixed in ecf9eb0. The "Latest" release doesn't contain this fix, only the pre-release.

I should probably pull directly from master, but it's more convenient for me to use the merged XML file than the full directory.

[benkasminbullock]

Ah, seems like it was fixed in ecf9eb0. The "Latest" release doesn't contain this fix, only the pre-release.

I should probably pull directly from master, but it's more convenient for me to use the merged XML file than the full directory.

The latest release is six years old so unfortunately it is out of date. If you have downloaded the pre-release, could you check it and see if it is basically OK, i.e. no files are badly formatted, for whatever purpose you're using it for? If someone checks it is OK, it makes it much easier to be sure it is OK to release as the full thing. Thanks.

[benkasminbullock]

If you have nothing else to say, I'll close this issue, since it is fixed already and it's also a duplicate of issue #155.

[SlugFiller]

If you have downloaded the pre-release, could you check it and see if it is basically OK, i.e. no files are badly formatted, for whatever purpose you're using it for?

Can't speak about the whole release, but other than not containing 2a261e2 the merged file in the pre-release WorksForMe(TM)

P.S. If the problem also existed in the Jinmei version and wasn't fixed there, it's probably worth fixing there too. I don't care as much because I don't use the variants.

P.P.S. Since the "mismatched kanji" were merged with main, it's probably worth ensuring they are all corrected before making a release, to avoid having broken data in release.

[benkasminbullock]

If you have downloaded the pre-release, could you check it and see if it is basically OK, i.e. no files are badly formatted, for whatever purpose you're using it for?

Can't speak about the whole release, but other than not containing 2a261e2 the merged file in the pre-release WorksForMe(TM)

Thanks for letting me know.

P.S. If the problem also existed in the Jinmei version and wasn't fixed there, it's probably worth fixing there too. I don't care as much because I don't use the variants.

Yes, my guess is that the Jinmei version stroke order is incorrect. It's possible that the different stroke order was intentional, but unlikely. Usually "Jinmei" signifies a visually distinct form, and the different stroke order is indicated with suffixes like VtLst.

P.P.S. Since the "mismatched kanji" were merged with main, it's probably worth ensuring they are all corrected before making a release, to avoid having broken data in release.

I disagree with you. There has always been a lot of broken data in all the releases of KanjiVG. The data has been broken in multiple ways since its inception. If you want to go back to the mailing list archives from thirteen or so years ago, you'll find a quite strong complaint from me about the merge of the old SVG and XML directories, which was the origin of having the mismatched characters in the kanji_mismatch directory. Basically this format change was done without fixing the underlying errors, a lot of which seem to have been errors of omission. Kanji which didn't have correct groups but placeholder files got the groups from the placeholder files forced onto them. Then on top of that, over the thirteen or so years since the merge, lots of people made corrections of individual files over the brokenness which was caused by the XML/SVG merge, and nobody got around to doing anything about the files from kanji_mismatch.

Despite this it has been able to be put to use over the past fourteen years, essentially because people are only using the old "SVG" data, the individual stroke paths, from the non-variant files, and as far as I know nobody is using the group/radical/stroke type information in the files, or the variant files. I assume that because I haven't seen any evidence of people using it in the list of projects, and if anyone tried to use the group or radical or stroke type information, they would have run into quite a lot of "broken data", and the issue list on this repository would reflect that.

If we block releases until all the "broken data" is fixed, we may never make a release for several years. In my opinion we are better off publishing data with some of the errors fixed and some of the people's problems solved, and then trying to fix the rest of it incrementally, rather than attempting to make a perfect release, and leaving the easy-to-use distribution files in a state of disarray, such that the same bugs get reported over and over again. This actually is not the first duplicate bug report related to the distribution files.

Anyway, I'd like to reiterate that I really do appreciate your feedback, but I have to disagree with you about the final point.