Some 200 kanji that need to be corrected

[Toshiro Mifune]

Hi, I've been working on a little project (http://igg.me/at/kanjiproject), based on the Kanji Stroke Order font (http://www.nihilist.org.uk) and I've come across a lot of mistakes in the stroke order/elements. I have corrected them and you can find them here: http://www.mediafire.com/download/td9sxuumlt2fqdk/modified_kanji.rar

Since the font and KanjiVG differ, and I have been working with the font data, there might be certain kanji that are correct in KanjiVG but still included in the link above (which I also forwarded to Tim Eyre, the author of the font), in which case just ignore them. There were a lot of cases, however, where the font was correct, but the KanjiVG data was incorrect. Those kanji are not included, unfortunately, because I did not note them down. Also not included are several other kanji that were incorrect, because I unfortunately lost track of all the modifications...

Hope it helps.

[ospalh]

I am not sure which  way these images are to be read.

Are they the wrong versions? How they should look?
And what are you using as standard what the “right” way should be?
I only looked at the first three in your list. What i have seen with those:
For 倦 and 僅, the version from your image is there as the x-Jinmei.svg variant.
For 儲, it appears that the 17-stroke version with a plain "者" at the right, without the extra dot (14 in the image) is a variant in some of the random fonts i have lying around:

 

[ospalh]

There is also a rather new version of the font out, 3.001, released 2014/03/18.
When looking at 兎, in my version of the font the numbers go up to 8. (7 in the image).

 

[Toshiro Mifune]

Oh, sorry for not making it clear. The images represent the correct stroke order.

The sources I used are:
http://kakijun.jp/
http://www.moj.go.jp/content/000058122.pdf
http://www.bunka.go.jp/kokugo_nihongo/joho/kakuki/22/pdf/jitaihyo.pdf
http://web.archive.org/web/20140201214928/http://itscj.ipsj.or.jp/ISO-IR/233.pdf
http://kosekimoji.moj.go.jp/kosekimojidb/mjko/PeopleTop/EXECUTE

The x-Jinmei variants should be swapped and made the default versions.

[ospalh]

Am Freitag, 23. Mai 2014 16:23:55 UTC+2 schrieb Toshiro Mifune:

Oh, sorry for not making it clear. The images represent the correct stroke order.

I guess i am in this over my head.
Maybe the differences are, or are similar to, those mentioned at GitHub, also mentioned in this thread.
So, perhaps we really should move the forms around.

I guess we could keep the old shapes as variants.

Anybody, any idea for the label/file names for the old shapes?

[Toshiro Mifune]

Yes, somebody should combine all these reports so you've got one list of kanji to work with, instead of scattered around threads/GitHub.

Maybe use x-Hyougai/x-Hyogai as a label.

[ospalh]

Am Freitag, 23. Mai 2014 17:02:41 UTC+2 schrieb Toshiro Mifune:

Maybe use x-Hyougai/x-Hyogai as a label.

if my Japanese-German dictionary is to be believed, maybe something like kyuu or kyuukanji as in   旧漢字. Afais the kanji per see are still listed, only the shape/writing style is out of date.

[Toshiro Mifune]

旧字体 and 新字体 are limited to some 300-400 kanji that were simplified after WWII. Assigning that label to other kanji would cause confusion.

[ospalh]

Am Freitag, 23. Mai 2014 17:18:45 UTC+2 schrieb Toshiro Mifune:

旧字体 and 新字体 are limited to some 300-400 kanji that were simplified after WWII. Assigning that label to other kanji would cause confusion.

 Ah. I see.

But, again, from what i understand 表外漢字 usually means that the kanji is not Jōyō, rather than referring to one specific variant of a listed kanji. Maybe simply furui 古い?

[Toshiro Mifune]

Yes, that's correct... But hyougai means "outside a table," and in this case outside the Jinmeiyou table. So one version uses the official Jinmeiyou shape, and the other falls outside the table, thus hyougai. Anyway, that's at least how I'd do the naming.

[Alexandre Courbot]

Thanks for providing the list. "Correct" and "incorrect" for kanji are
rather vague notions, since there are typically several variants for
complex kanji and I am not sure which one can be deemed the "official"
one. Maybe we should try to draft some rules first?

We definitely need an active linguist on this project... :/

> --
> --
> You received this message because you are subscribed to the "KanjiVG" group.
> For options and unsubscribing, visit this group at
> http://groups.google.com/group/kanjivg
> ---
> You received this message because you are subscribed to the Google Groups
> "KanjiVG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kanjivg+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[ospalh]

Am Sonntag, 25. Mai 2014 04:16:51 UTC+2 schrieb Alexandre Courbot:

 

(...) I am not sure which one can be deemed the "official"

one. Maybe we should try to draft some rules first?  

I guess the JISC is pretty much as official as it gets. And many of the kanji from the OP list are those were JIS 213:2000 says (Apendix A) that the printed form has changed

 

We definitely need an active linguist on this project... :/

 Yeah. Afais the standard applies mostly to typopgraphy. I would like to hear something about how far that standard is, say, applied in schools in Japan when teaching how to write those kanji.

[msk...@ansuz.sooke.bc.ca]

On Sun, 25 May 2014, ospalh wrote:
> I guess the JISC is pretty much as official as it gets. And many of the
> kanji from the OP list are those were JIS 213:2000 says (Apendix A) that the
> printed form has changed

Let me mention again that I think KanjiVG, or some successor project,
would greatly benefit from representing stroke order explicitly in XML
attributes instead of implicitly via the sequential order of tags within
the file. Then we could include more than one stroke order (for instance,
from different official sources when they conflict with each other) in a
single file, instead of having to record only one and agree on which one,
or separate two different stroke orders for the same character using
separate file names. Switching to attributes would also have other
benefits, such as cleaning up the representation of nesting structure in
characters like 園 where stroke order doesn't match nesting structure. I
wrote some code to support such a change and it's in my Github account,
though it's been years since I wrote that and I don't remember clearly
exactly how I meant it to be applied.

--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

[ospalh]

Am Sonntag, 25. Mai 2014 11:46:27 UTC+2 schrieb Matthew:

(...0 KanjiVG, (should) representing stroke order (...) in XML
attributes

Might be a good idea. See below.

Then we could include more than one stroke order (for instance,
from different official sources when they conflict with each other) in a
single file,

 That would be confusing. There are some kanji where there are differences only in the stroke order, and some where there are different shapes. (The OP was more about the latter.) When we encoded different stroke orders in one file for one kanji, we would have some kanji where you have several variants and only one file, and some kavji where you have variants and several files. Also, i think it is generally easier to handle variants by having different files. That you can see from the outside (just looking at a directory listing) whether there are variants.

 

 

(...) I wrote some code to support such a changeand it's in my Github account,
 

... I wrote some code like that, too, but it is used to colorize the strokes via CSS. In the past even through external CSS files.

Demo: colorized my way:

[Ben Bullock]

On 25 May 2014 18:47, <msk...@ansuz.sooke.bc.ca> wrote:

> Let me mention again that I think KanjiVG, or some successor project,
> would greatly benefit from representing stroke order explicitly in XML
> attributes instead of implicitly via the sequential order of tags within
> the file.

I second this.

> Then we could include more than one stroke order (for instance,
> from different official sources when they conflict with each other) in a
> single file, instead of having to record only one and agree on which one,
> or separate two different stroke orders for the same character using
> separate file names.

In my opinion this is excellent thinking.

[Alexandre Courbot]

On Sun, May 25, 2014 at 6:47 PM, <msk...@ansuz.sooke.bc.ca> wrote:
> On Sun, 25 May 2014, ospalh wrote:
>> I guess the JISC is pretty much as official as it gets. And many of the
>> kanji from the OP list are those were JIS 213:2000 says (Apendix A) that the
>> printed form has changed
>
> Let me mention again that I think KanjiVG, or some successor project,
> would greatly benefit from representing stroke order explicitly in XML
> attributes instead of implicitly via the sequential order of tags within
> the file.

The more it goes, the more I come to agree that this (or something
along its lines) is indeed the way to go, if only to remove a lot of
the duplicated data.

> Then we could include more than one stroke order (for instance,
> from different official sources when they conflict with each other) in a
> single file, instead of having to record only one and agree on which one,
> or separate two different stroke orders for the same character using
> separate file names.

The only issue I would have with having the stroke orders in the same
file is that some variants also have a slight difference in shape, and
recording this would require a new file. Unless we use extra
attributes and store them into the same file as well.

Or we could just abandon SVG as a source format and go with something
more appropriate to store all this data. This would require
appropriate tooling for editing (something that we need since a long
time anyway), and we could then output SVG from it.

> Switching to attributes would also have other
> benefits, such as cleaning up the representation of nesting structure in
> characters like 園 where stroke order doesn't match nesting structure.

As a matter of fact Tagaini does this for its internal kanji
representation. KanjiVG's internal representation just wasn't
convenient at all.

[msk...@ansuz.sooke.bc.ca]

On Mon, 26 May 2014, Alexandre Courbot wrote:
> > single file, instead of having to record only one and agree on which one,
> > or separate two different stroke orders for the same character using
> > separate file names.
>
> The only issue I would have with having the stroke orders in the same
> file is that some variants also have a slight difference in shape, and
> recording this would require a new file. Unless we use extra
> attributes and store them into the same file as well.

To be clear, from my point of view the main advantage of putting stroke
order in attributes is that it can clarify the nesting structure.
Multiple stroke orders in the same file isn't the main reason to use
attributes, and might not even be desirable; as you describe, there are
cases where it might cause problems. We could use attributes and still
keep different stroke orders in separate files if that seemed to be
better. But with attributes, multiple stroke orders in the same file
would at least become an option we could consider, which it isn't really
in the present system.

[Ben Bullock]

On 26 May 2014 10:15, <msk...@ansuz.sooke.bc.ca> wrote:

> To be clear, from my point of view the main advantage of putting stroke
> order in attributes is that it can clarify the nesting structure.
> Multiple stroke orders in the same file isn't the main reason to use
> attributes, and might not even be desirable; as you describe, there are
> cases where it might cause problems. We could use attributes and still
> keep different stroke orders in separate files if that seemed to be
> better. But with attributes, multiple stroke orders in the same file
> would at least become an option we could consider, which it isn't really
> in the present system.

Alternatively each stroke could have an ID number and the stroke
orders could be another XML element, like

<order id=kaisho>1 2</order>
<order id=monbusho>2 1</order>
<stroke id=1 ...
<stroke id=2 ...

[ospalh]

Am Montag, 26. Mai 2014 02:23:34 UTC+2 schrieb Alexandre Courbot:

(...)

The only issue I would have with having the stroke orders in the same

file is that some variants also have a slight difference in shape,(...)

"Some" is a bit of an understatement. For pretty much every 日 or 月 element we have a variant, called Kaisho as in 楷書, where the internal horizontal strokes don't touch the second stroke on the right.

A bit of counting:

• Plain kanji: 6615
• Kaisho and Jinmei variants (different shape): 4055
• Stroke order variants (with Hz, Vt or Md in the file name): 1030

Something that doesn't address the different shape variants isn't much of a solution, imo.

P.S. That counting was a piece of cake because every variant has its own file. It would have been much harder if they were somehow encoded inside the files.

[ospalh]

For something like 79 kanji, this should fix the issues.
I didn't actually use your list, but the JIS_X_0213 changes in the 2004 version. I think there is a big overlap.

[Toshiro Mifune]

>I think there is a big overlap.

Yes, there is. But my list is not limited to the JIS X 0213 changes, so it'd be worth checking up the other kanji as well.

[ospalh]

Am Dienstag, 3. Juni 2014 11:54:41 UTC+2 schrieb Toshiro Mifune:

[I]t'd be worth checking up the other kanji as well.

I just went through them. There are 79 kanji in your list that are not in the "changed in 2004" list.
For those marked "howzat" i really don't know what should be changed. For some of those KanjiVG is ahead of the font, for others, maybe ahead of the version of the font you had been using.
For some, i think the KanjiVG version is closer to the standard.
For others, it took me a while to get what you wanted changed, because it wasn't in the image. (Mostly 入 instead of 人 as an  element above others.)

[Toshiro Mifune]

For the "howzat" (what does that even mean, lol?), you are right, they were limited to the font or were something else, except for one. I went through your list and added comments where necessary (separated with a tab), removed the unnecessary kanji, and added 2 additional kanji. I forgot to change 人 to 入, yes, odd.

[ospalh]

Am Dienstag, 3. Juni 2014 22:38:37 UTC+2 schrieb Toshiro Mifune:

[...]"howzat"[,] what does that even mean[? ...]

I thought it was mildly funny.

I went through your list and added comments where necessary (separated with a tab),

Thanks. I will look at those later.

[Toshiro Mifune]

Actually disregard the former file, use this one.

[ospalh]

I guess we could really need the referee, i mean linguist Alexandre Courbot mentioned earlier in the thread.

The question is how to draw the elements that look like ヰ in one version and is drawn with three strokes in the other variant in a number of kanji.

For example 桀, there are at least dozens of kanji where this would apply.
The images show the two variants.
There are references to this kanji having ten and eleven strokes at different sources.

Ten strokes:

• Unihan
  
• Text at mahou.org
• Kanjilexikon (Stroke data shows eleven strokes, but that data has a common ancestor with KanjiVG, so that doesn't count for this argument, how KanjiVG should do it.)
  

Eleven strokes

• The JIS X 0213:2004 standard document mentioned earlier
• Fonts based on that like the IPA fonts.
  
• The image at mahou.org (?)
• Kakijun, this shows a handwritten eleven-stroke version.
• Searching for unicode character 6840 at kosekimoji

I guess the Right Thing would be to have both variants of these kanji. The real question is: which version should be standard version and which one almost invisible as a variant?

[ospalh]

P.S.
This is about the radical 舛 used as part of a kanji. That radical alone is drawn with six strokes, but apparently changed to a seven-stroke variant is some kanji. Or in some variants of some kanji.

[Toshiro Mifune]

There are 7 non-joyo and non-jinmei kanji with that radical:

桝 燐 桀 磔
蕣 鄰

Only the bottom two appear with the 6-stroke radical variant instead of 7 in fonts. But the stroke information for all of them in 漢字源 says 1 stroke less (i.e. using the 6-stroke radical variant).

So this is a weird case; the stroke order disagrees with the stroke count for some reason, and only two hyougai kanji use the 6-stroke shape. Why? What is the reasoning for this discrepancy?

[Toshiro Mifune]

Oops, I said 7 but listed only 6. 舛 is the 7th.

[ospalh]

I need a bit of aesthetic advice. I tried my hand at changing the 人 element to 入. I started with 喩, but to save work i would cut-and-paste the change to others.

My try looks like this, before and after:

So, keeping the general style of the font in mind, is that OK? If not, how exactly should the strokes 4 and 5 be changed? Longer? Shorter? Moved in some direction?

Maybe the end of stroke 5 should be straighter?

[ospalh]

Am Freitag, 6. Juni 2014 15:08:35 UTC+2 schrieb ospalh:

I need a bit of aesthetic advice. I tried my hand at changing the 人 element to 入. I started with 喩, but to save work i would cut-and-paste the change to others.

Or this way. A bit more extreme. with a corner in stroke 5.
This one was inspired by this file,  which is apparently publish by the Japanese "Agency for Cultural Affairs", which makes it is kind-of official‽ In the file this version is given in parentheses, so maybe go with my first try instead?

[ospalh]

Am Freitag, 6. Juni 2014 15:08:35 UTC+2 schrieb ospalh:

I need a bit of aesthetic advice.

Looking at other 入 elements in the font, the second try would look odd.

My third try, which is my favorite at the moment was inspired by KanjiVGs version of "込", similar to the first try, but i think it generally looks a bit better.

[ospalh]

I started using something like version 3. See the  jis-x-0213-2004-fixes feature branch at github. People that like other variants better are welcome to make those changes themselves…

[ospalh]

Am Dienstag, 24. Juni 2014 13:13:40 UTC+2 schrieb ospalh:

I started using something like version 3. See the  jis-x-0213-2004-fixes feature branch at github. People that like other variants better are welcome to make those changes themselves…

The changes to bring KanjiVG (mostly) up to JIS X 0213:2004 are done. Changes to single characters can be discussed at github

[ospalh]

Am Donnerstag, 3. Juli 2014 16:37:03 UTC+2 schrieb ospalh:

The changes to bring KanjiVG (mostly) up to JIS X 0213:2004 are done. Changes to single characters can be discussed at github

And the rest is up, too. To be discussed  at github, too.