Complete Kanji Character Codes

[i-h8-github]

Hello,

First of all, thank you for this tremendous effort. I am absolutely blown away by the quality and volume of the work on display here.

I have determined that there are 1440 character codes which appear in kanjidic and which also appear in at least one entry in jmdict, but which do not appear in any language folder within this project. While that is already an impressively low number, I would like to help make it 0.

Strictly speaking, the number of character codes which do not appear in the Ja folders is 2633. 1193 of those codes can be found within the other folders. Perhaps duplicating those codes into the Ja folder (after some basic checking against form or stroke order differences) would be a good option.

For the remainder, I can help sort the missing codes into tiers of priority based on a few heuristics. If you are open to discussing the creation process with me a little more in-depth, I can even help contributing files myself. I imagine that many of these will be a matter of combining elements which already exist.

Looking forward to your reply, and thank you again for this wonderful project.

[parsimonhi]

Hello,

Thank you for your interest for animCJK.

It takes about 30 minutes on average to add a character. Of course, if the character is already in another folder (and is identical, which is the case for about two out of three characters), it's faster. But even in this case, it is quite difficult to add a new character in less than 15 minutes because of the various checks and updates that need to be done (stroke order, glyph, number of strokes, decomposition, translation, etc.). That is why adding several thousand characters will take time.

If you have a list of priority characters, post it here. It'll help me. I am currently working on two lists: the characters for the Kanken exam (about 3000 characters are missing) and the characters that are components of the characters already in animCJK. But I can work on your list as a priority (most of the characters you miss should also be in the list for the Kanken).

Note that I'm for a while in a country where it's not always easy to update github (sometimes it just doesn't work because a timeout occurs). Be patient.

[i-h8-github]

In the interest of avoiding duplicating work between us, we should coordinate which characters we are working on.

I can begin by going through the list of characters which are present in Zh but not in Ja and marking them as either identical, form-compatible/stroke-incompatible, or form-incompatible. In the cases where they are form-compatible and stroke-incompatible, I can rearrange the animations in the files to accommodate. I think the majority will be identical, as the stroke order rule differences between Japanese and Chinese are few, and the form differences tend to boil down to a few radicals.

If you give me a list of the characters you are working on, I can compile a diff between our working sets so that at least in the short term we can be as individually productive as possible.

[parsimonhi]

No, the differences in stroke order between Japanese and Chinese are not rare, and the differences in form are not limited to a few radicals. There are many characters present in Zh but not in Ja that are not identical in Chinese and Japanese (at least a third, maybe half of them). And this is the main reason why I have not already duplicated them for the moment.

And determining which character in Zh needs to be modified before being added to Ja is very (very) tricky.

But okay, if you want to do something to help, here’s a possible roadmap in the near future:

1. Select 100 characters that you think there are identical in both Zh and Ja (but not already in Ja) and post the list here,
2. I'll check the list. If there are no error (or not too many), i'll will update the repository of animCJK accordingly,
3. Then we'll redo 1) and 2) with other sets of 100 characters.

Please do not try to modify the characters when you think they are different in Chinese and Japanese for the moment (as I may have already done some of the work). May be later :-)

[parsimonhi]

Since this issue was posted, I added 500 characters to SvgsJa (+ some modifications on other characters). The list is documented in the readme (section "What is new?", 100 chars on the 2026/26/01 and 400 chars on the 2026/02/06).

I am now working on the following set: 壤 壟 壯 壺 壹 壻 壼 壽 夂 夊 夐 夛 梦 夥 夬 夭 夲 夸 竒 奕 奐 奚 奘 奢 奠 奧 奬 奩 奸 妁 妝 佞 侫 妣 妲 姆 姜 妍 姙 姚 娥 娟 娑 娜 娉 娚 婀 婬 婉 娵 娶 婢 婪 媚 媼 媾 嫋 嫂 嫣 嫗 嫦 嫩 嫖 嫺 嫻 嬌 嬋 嬖 嬲 嫐 嬪 嬶 嬾 孃 孅 孀 孑 孕 孚 孛 孥 孰 孳 孵 學 斈 孺 宀 宦 宸 寃 寇 寉 寔 寐 寤 實 寢 寞 寥 寫 寰 寶 寳 尅 將 專 對 尓 尠 尢 尨 尹 屁 屆 屎 屓 屐 屏 孱 屬 屮 乢 屶 屹 岌 岑 岔 妛 岫 岻 岶 岼 岷 峅 岾 峇 峙 峩 峽 峺 峭 嶌 峪 崋 崕 崗 嵜 崟 崛 崑 崔 崢 崙 崘 嵌 嵒 嵎 嵋 嵬 嵳 嵶 嶇 嶄 嶂 嶢 嶝 嶬 嶮 嶽 嶐 嶷 巉 巍 巓 巒 巖 巛 巫 巵 帋 帚 帙 帑 帛 帶 帷 幄 幃 幀 幎 幗 幔 幟 幢 幤 幇 幵 并 庠 廂 廈 廐 廏 廖 廣 廝 廚 廛 廢 廡 廨 廩 廬 廱 廳 廰 廴 廸 廾 弃 弉 彝 彜 弑 弖 弩 弭 弸 彁 彈 彌 彎 彑 彖 彡 彭 彳 彷 徃 徂 彿 徊 徑 徇 從 徙 徘 徠 徨 徭 徼 忖 忻 忤 忸 忱 忝 悳 忿 怡 恠 怙 怐 怩 怱 怛 怫 怦 怏 怺 恚 恁 恪 恷 恟 恊 恆 恍 恃 恤 恂 恬 恫 恙 悁 悍 悃 悚 悄 悛 悖 悗 悒 悧 悋 惡 悸 惠 惓 悴 忰 悽 惆 悵 惘 慍 愕 愆 惶 惷 愀 惴 惺 愃 愡 惻 惱 愍 愎 慇 愾 愨 愧 慊 愿 愼 愬 愴 愽 慂 慳 慷 慘 慙 慚 慫 慴 慯 慥 慱 慟 慝 慓 慵 憙 憖 憇 憔 憚 憊 憑 憮 懌 懊 懷 懈 懃 懆 憺 懋 罹 懍 懦 懣 懺 懴 懿 懽 懼 懾 戀 戉 戍 戔 戛 戞 戡 截 戮 戰 戲 戳 扁 扎 扞 扣 扛 扠 扨 扼 抂 抉 抒 抖 拔 抃 抔 拗 拑 抻 拏 擔 拈 拜 拌 拊 拂 拇 抛 挌 拮 拱 挧 挂 挈 拯 拵 捐 挾 捍 搜 捏 掖 掎 掀 掫 捶 掣 掏 掟 掵 捫 捩 掾 揩 揀 揆 揣 揉 插 揶 揄 搖 搴 搆 搓 搦 搶 攝 搗 搨 搏 摧 摶 摎 攪 撕 撓 撩 撈 撼 據 擒 擅 擇 撻 擘 擂 擱 擧 舉 擡 擣 擯 攬 擶 擴 擲 攀 擽 攘 攜 攅 攤 攣 攫 攴 攵 攷

Hope it helps.

[i-h8-github]

Thank you, this information is helpful for what I'm doing.

I think you misread my previous message, but I also don't suppose you have any reason to trust my competency.

Assuming we consider KanjiVG a trustworthy source, I am cross-referencing my work against theirs, mostly because it is easy to integrate into a small annotation program I plan to build for this purpose. Do you have other (more) definitive sources to cross-reference?

And just to make completely sure that we are on the same page:

There are a number of characters in that list which to my eye can be moved as-is into the Ja folder, e.g. 巛, 彡, 并 just to pick out a few at a glance. Is there some reason you disagree that those characters' Chinese forms are both form- and stroke-compatible with their Japanese forms?

Whereas, e.g. 恙 is form-compatible with Chinese, but not stroke-compatible (specifically, strokes 4 and 5 are swapped in the Japanese order). Do you disagree?

[parsimonhi]

About my sources: i listed some of them in the readme of this project. KanjiVG is in this list and is a really good reference. But since animCJK is in kaisho style, there are sometimes some differences (especially for the glyphs). My other main source for Japanese is kakijun.jp (the site is not pretty, but the data seem accurate, they have numerous samples in kaisho style, and sometimes, they document when there is a trick somewhere).

EDIT: there is also another site kakijun.com. According to me, it is less accurate than kakijun.jp, but much prettier.

I do not doubt about your competences. But after more than 10 years on this project, I am still discovering some errors in animCJK. So I am well-placed to know that this is a difficult matter. And it is really tricky when we consider the hyōgai kanjis, because some components of these characters have not always the same shape as in jōyō or jinmeiyō kanjis (roughly, the jōyō kanjis were transformed in a certain way, the jinmeiyō in another way, and the hyōgai kanjis often keep the shape (hook, attached or not attached, etc.) of the old Chinese). As a result, as soon as the character has some complexity, this requires some checks that are not easy to complete because the sources are somewhat imprecise (or do not say the same thing) when the character is rare.

For instance, in Japanese in kaisho style, does the 6th stroke of 花 overflow the 7th stroke in the following characters: 埖硴錵椛婲㳸𠵅㬸蒊糀誮𩸽. The correct (or at least a decent) answer is really not easy to find (for me). In Chinese, it always overflow. In Japanese, for common characters, it does not. And for rare characters in Japanese, ..., it seems it depends of the direction of the wind.

And for the stroke order, they are also numerous differences.

Some examples among the very common characters that are different in ja and zhHans (s means stroke order, g means glyph, d means "depends of the sources"): 出(s)右(s)玉(s)王(s)生(s)田(s)男(s)町(s)空(g, curved 4th and 5th strokes)耳(s)花(g, no overflow of the 6th over the 7th)青(s)今(d)北(sg, no overflow of the 4th over the 5th)国(s) 少 (g, hook on the 1st) 思(s)才(g, 3rd overflows the 2nd) etc.

Of course, you are right: many characters from svgsZhHans can be used in svgsJa as is (around 70% of them). But once again, it can be tricky to know what they are, even when they have not many strokes.

Anyway, I am interested by a list of these identical characters: if i have the list (or part of the list), I can more quickly add them to animCJK.

And I am interested by your priority list (EDIT: especially those that are identical in ja and zhHans).

Not that i use several scripts to automate the generation of the characters and the update of the different parts of animCJK (including the indexes, the decomposition and the meaning of the characters). It is not enough to simply duplicate the svgs from svgsZhHans and copy them into svgsJa.

[i-h8-github]

Here is a sample set of my character compatibility annotations. These annotations don't take very long to do, and now that I have the scripts, &c. in place to create and expand the annotations, I can pretty easily do somewhere around this many (76 specifically in this case, because why not) a day for the foreseeable future. Are there any issues you see with this output?

Compatible:
佞
勒
壹
夥
奕
奸
妁
妍
妣
娟
娥
婉
婢
婪
媚
嫣
嫦
嫩
嬖
孀
孑
孳
孺
宸
寞
屎
屬
屹
峙
嵌
巉
帑
帙
幄
幔
庠
弑
弩
彭
彷
徊
徙

Require one stroke order swap:
奘: strokes 1 & 2
姆: strokes 7 & 8
姜: strokes 4 & 5
孕: strokes 1 & 2
寐: strokes 4 & 5
寤: strokes 4 & 5
對: strokes 9 & 10
岫: strokes 6 & 7
帷: strokes 8 & 9
徨: strokes 10 & 11

Radical stroke order/count differences:
娜: ⻏
娶: 耳
婀: ⻏
弭: 耳

Require more significant stroke order revision:
媾: strokes 4–8
學: strokes 1–8
崛: strokes 7–9

Radical form differences:
嵬: 鬼
巍: 鬼
廨: 角

Miscellaneous:
奚: second stroke is toward left vs. right, but otherwise identical
奠: top two strokes should be 八, but otherwise identical
奢: missing 8th stroke for Japanese form
娑: missing hook in 沙
孵: swap strokes 6 & 7, form of 9
宦: strokes 5–10, Chinese stroke 9 requires separation into two strokes 4 and 10 in Japanese
寥: form of 5, 6, 8, 9
寨: stroke 4–8, form of 11–14木
岌: Chinese stroke 6 needs to be two strokes in Japanese, form of stroke 7 connects to stroke 4
峭: stroke 5, 6 outward instead of inward
幢: compatible as present, but actually, the stroke order for 里 is wrong in Chinese
彝: compatible, may desire hook on bottom of stroke 13
徘: stroke 7 should penetrate stroke 4
徭: form of 4–7(⺤)

[parsimonhi]

Good job, nearly perfect!

However:

• for 奘, strokes 1-2 are inverted (you know the rules because you didn't miss it on other characters such as 寐).
• for 幢, it seems that in simplified Chinese (zhHans), the stroke order of 里 component is as in Japanese (including traditional characters when there are used in a document where the lang code is zhHans). This is in traditional Chinese (zhHant, as in Taiwan), that the stroke order is different.
• for 孵, there is a stroke order difference, but there is also a difference on the glyph of the top right component (Japanese version of 爫 as in 奚).
• for 宦, there is a stroke order difference, but the number of strokes is also changing (the 9th stroke of the simplified Chinese version is split in 2).
• for 寨, the bottom component 朩 should be replaced by 木. In many kanjis, 朩 is replaced by 木 in Japanese, even if in kaisho style, 朩 is still widely used.
• for 彝, interesting suggestion! in nearly all characters (but not all), there is a hook at the end of the vertical stroke of the 糸 component in kaisho style in both Japanese and Chinese (but never a hook in kyoka style in Japanese). So when the hook is not present in kaisho style, in my opinion it should be the same in Japanese and Chinese (it's probably just a matter of having enough space to draw this hook or not). I prefer not to add this hook in order to keep the ja kaisho version and the zhHans kaishu version consistent, even if some authors add a hook in kaisho style for 彝 in Japanese ... and in Chinese. That being said, this is a good point to mention this hook, and maybe I will change my mind in the future.

I added your list + some other characters and some modifications on previously added characters (see What's new section in the Readme).

Ready to provide another list? :-)

[i-h8-github]

奘: My mistake, indeed.
幢: My note on the Chinese stroke order for 里 is the way I was taught, and certain sources do seem to agree with me, but I'll defer.
孵: I actually did note that in my annotations, but the script to expand my annotations into more regular English was imperfect; if you read the latest edit of that post, you'll see my note agreeing with you.
宦: Another bug in my annotation expansion script; I actually noted the same things you did. Fixed now in previous post.
寨: That was my first instinct as well, and I did actually note that in my original annotations (same bug as regarding 宦, fixed now), but, for example, https://kakijun.jp/page/sait14200.html seems to suggest that it is more common in the 朩 form outside of printed scripts. I'll defer to you on matters of style, which seem like tough calls much of the time.

[i-h8-github]

I also created a script to automate the conversion of characters which require a single stroke swap. Below is a sample of one of the files created in this way:

姆:

<!--
AnimCJK 2016-2025 Copyright FM-SH - https://github.com/parsimonhi/animCJK
Derived from:
    MakeMeAHanzi project - https://github.com/skishore/makemeahanzi
    Arphic PL KaitiM GB font
    Arphic PL KaitiM Big5 font
You can redistribute and/or modify this file under the terms of the Arphic Public License
as published by Arphic Technology Co., Ltd.
You should have received a copy of this license along with this file.
If not, see https://ftp.gnu.org/non-gnu/chinese-fonts-truetype/LICENSE.
-->
<svg id="z22982" class="acjk" viewBox="0 0 1024 1024" xmlns="http://www.w3.org/2000/svg">
<style>
<![CDATA[
@keyframes zk {
	to {
		stroke-dashoffset:0;
	}
}
svg.acjk path[clip-path] {
	--t:0.8s;
	animation:zk var(--t) linear forwards var(--d);
	stroke-dasharray:3337;
	stroke-dashoffset:3339;
	stroke-width:128;
	stroke-linecap:round;
	fill:none;
	stroke:#000;
}
svg.acjk path[id] {fill:#ccc;}
]]>
</style>
<path id="z22982d1" d="M293 703Q324 728 366 770Q381 783 390 785Q399 785 404 774Q411 764 405 734Q399 701 324 662C299 649 299 649 287 642Q262 629 232 614Q213 604 215 586Q242 514 267 440C276 413 276 413 280 400Q302 327 322 254Q332 209 352 186Q365 165 358 153Q345 135 302 107Q283 95 267 102Q254 109 264 125Q289 168 234 408C227 437 227 437 223 452Q216 474 211 498Q196 547 173 585Q163 607 183 623Q226 647 262 677C283 694 283 694 293 703Z"/>
<path id="z22982d2" d="M262 677Q190 749 109 794Q96 801 107 805Q182 812 288 709Q289 705 293 703C307 693 315 677 324 662Q373 578 387 522Q414 420 428 401Q438 385 424 376Q385 342 361 348Q348 351 353 364Q357 374 359 385C360 405 360 405 360 415C360 416 360 416 360 416Q351 542 287 642C270 665 270 665 262 677Z"/>
<path id="z22982d3" d="M359 385Q320 392 280 400C249 405 249 405 234 408Q173 415 110 426Q89 430 56 425Q43 425 41 434Q37 446 45 455Q64 473 93 495Q102 499 114 493Q172 460 223 452C252 444 252 444 267 440Q312 428 360 415C370 413 369 383 359 385Z"/>
<path id="z22982d4" d="M574 204Q559 191 538 182Q519 175 516 184Q512 193 519 201Q538 229 537 263Q530 359 513 448C508 474 508 474 505 487Q483 595 452 641Q409 689 424 710Q428 717 439 726Q455 739 475 722Q532 685 720 703Q732 703 744 706C781 711 781 711 800 714Q849 721 898 738Q914 745 926 740Q938 736 933 722Q927 704 909 691Q896 676 871 676Q852 676 807 672C771 669 771 669 753 667Q662 663 517 669Q496 670 503 646Q525 567 544 480C549 455 549 455 551 443Q570 346 583 239C585 227 584 211 574 204Z"/>
<path id="z22982d5" d="M831 407Q835 263 848 234Q861 212 850 204Q843 192 787 158Q772 146 709 171Q636 192 574 204C562 206 571 239 583 239Q601 240 627 231Q745 198 763 211Q776 218 778 247Q779 340 777 416C776 442 776 442 776 455Q770 576 753 667C747 693 747 693 744 706Q722 808 690 833Q684 834 593 801Q580 798 584 810Q587 819 604 830Q656 875 682 910Q710 938 728 919Q768 868 800 714C805 686 805 686 807 672Q819 603 829 455C830 423 830 423 831 407Z"/>
<path id="z22982d6" d="M615 311Q657 383 677 388Q690 391 699 375Q703 362 697 342Q690 326 670 313Q639 291 624 286Q617 283 613 294Q610 301 615 311Z"/>
<path id="z22982d7" d="M612 560Q625 579 638 603Q648 618 663 621Q673 622 681 611Q688 598 686 568Q685 553 663 538Q611 507 596 509Q592 512 590 524Q591 536 612 560Z"/>
<path id="z22982d8" d="M829 455Q869 454 914 454Q971 457 978 447Q982 437 969 424Q917 385 860 402Q845 403 831 407C795 413 795 413 777 416Q734 420 681 428Q618 435 551 443C526 446 526 446 513 448Q471 451 427 456Q408 457 422 473Q435 486 451 491Q460 492 505 487C531 482 531 482 544 480Q596 470 656 464Q707 457 776 455C811 455 811 455 829 455Z"/>
<defs>
	<clipPath id="z22982c1"><use href="#z22982d1"/></clipPath>
	<clipPath id="z22982c2"><use href="#z22982d2"/></clipPath>
	<clipPath id="z22982c3"><use href="#z22982d3"/></clipPath>
	<clipPath id="z22982c4"><use href="#z22982d4"/></clipPath>
	<clipPath id="z22982c5"><use href="#z22982d5"/></clipPath>
	<clipPath id="z22982c6"><use href="#z22982d6"/></clipPath>
	<clipPath id="z22982c7"><use href="#z22982d7"/></clipPath>
	<clipPath id="z22982c8"><use href="#z22982d8"/></clipPath>
</defs>
<path style="--d:1s;" pathLength="3333" clip-path="url(#z22982c1)" d="M269 104L316 164L193 598L356 718L393 779"/>
<path style="--d:2s;" pathLength="3333" clip-path="url(#z22982c2)" d="M359 354L394 402L317 632L243 723L110 798"/>
<path style="--d:3s;" pathLength="3333" clip-path="url(#z22982c3)" d="M48 434L105 461L357 403"/>
<path style="--d:4s;" pathLength="3333" clip-path="url(#z22982c4)" d="M523 188L556 227L554 304L463 685L483 700L595 681L767 688L928 730"/>
<path style="--d:5s;" pathLength="3333" clip-path="url(#z22982c5)" d="M581 208L769 182L814 221L788 619L745 808L700 879L589 809"/>
<path style="--d:6s;" pathLength="3333" clip-path="url(#z22982c6)" d="M620 291L692 377"/>
<path style="--d:7s;" pathLength="3333" clip-path="url(#z22982c7)" d="M599 518L653 568L667 616"/>
<path style="--d:8s;" pathLength="3333" clip-path="url(#z22982c8)" d="M425 464L974 434"/>
</svg>

If that looks right to you, then I am also in the process of revising my annotation strategy to be able to automatically convert characters with more than one stroke order difference but which are otherwise form-compatible (e.g. the "Require more significant stroke order revision" heading above). Then we'll really be cooking with gas, at least as far as the SVG side of things goes.

The truth is, I do have more annotations to share today as well (along with a collection of ready-to-go SVGs), but I feel like collaborating via posts in this thread is going to get out of hand pretty quickly. Do you think we should establish a master file of all of these characters, their annotations, and the stati of the completeness of their various components (i.e. SVG, dictionary, &c.) somewhere? A SQLite DB, maybe? Or a TSV? (My vote would be for SQLite).

[parsimonhi]

1. About 寨

You cannot rely on kakijun.jp for hyogai kanji in general because it doesn't use the kaisho style for the animation. You can rely on kakijun.jp for joyo kanji and jinmeyo kanjis if you look at the bottom of the page. For these kanjis, there is on the bottom of the page a picture with different styles including the kaisho style.

Note also that there is not an only one kaisho style shape in general for a given character. There are many variations.

For 寨, anyway, you can't trust anyone! :-)

moji.tekkai.com shows 寨 with a 朩, kanji.jitenon.jp shows it with a 木 (with a hook on the vertical stroke?!?), kakijun.jp does not show it in kaisho style, kakijun.com shows it with a 木. Since nearly all other characters are usually shown with a 木 in Japanese, I also choose to use 木 for 寨.

For the usage of 朩 versus 木, the only notable exception in kaisho seems to be 茶, shown with a 朩 everywhere (but in the kyokasho of 茶 it is not a pure 木).

2. Format to share data

To share the data to indicate which strokes should be exchanged, I suggest a comma-separated text file (one line per character). The reference can be Chinese (no swap to do), and for other languages, one can simply indicate the new position of the strokes.

For instance, for 姆 in Japanese, the line will be in the text file:
姆,1,2,3,4,5,6,8,7

Simple to decode, simple to post in a comment, simple to address any kind of swap!

And later, if you want to add data to specify a glyph change, one can easily replace the number by a stroke, or add a reference character (in the same lang, not Chinese) after the number. The later requires to establish a list of reference characters to address any glyph change (one reference character per kind of glyph change).

For instance, for 奚 in Japanese:

1. using strokes
   奚,1,㇀,3,㇔,5,6,7,8,9,10
2. using a reference character, 爫 (providing ​爫 is the Japanese form of the component, that is ㇀㇀㇔㇔):
   奚,1​爫,2​爫,3​爫,4​爫,5,6,7,8,9,10

Note: 爫 is "unified". It means that if the font is a simplified Chinese one and the lang code is zhHans, you will see ㇀㇔㇔㇀ on your screen, and if the font is a Japanese one and the lang code is ja, you will see ㇀㇀㇔㇔ on your screen.

For 宦 in Japanese:

1. using strokes
   宦,1,2,3,㇑,4,5,6,7,8,​㇐
2. using a reference character, 臣 (providing 臣 is the Japanese form of the component, i.e. 7 strokes ㇑㇐㇑㇕㇐㇑㇐)
   宦,1,2,3,1臣,2臣,3臣,4臣,5臣,6臣,​7臣

In SQLite, what is exactly your suggestion?

[i-h8-github]

What I meant was, I have a list of all characters which are not in svgsJa, but which are in one of the svgsHan* directories. In order for us to keep track of compatibility annotations, which characters have been fully processed, &c. as sort of a master working set, I suggest sharing this list between us somehow, and I personally think a SQLite DB would be the best, since it's portable, self-contained, and easy to browse/edit on any platform.

My proposed schema is:

table: characters
character_id => (integer, NOT NULL) the decimal value of the character as used in animCJK
literal => (text, NOT NULL) the character literal, for easy searching
file => (text), the specific file being annotated for Japanese, relative to the animCJK-master directory
annotation => (text), the annotation for the file vs a potential Japanese counterpart in shorthand
… => see note below
complete => (boolean, NOT NULL, false), whether the character is currently part of the animCJK Ja collection, regardless of whether every character in this DB has been addressed

Additionally, I propose columns for whichever other elements besides the SVGs is necessary for the character to be considered complete (represented by …).

This will help us avoid duplicate work, and give us one place to make sure we agree on all of the annotations before/during batch processing.

My annotations are straightforward:

/c/: compatible, i.e. no work to be done on the SVG.

/^s(?<set_1>(\d{1,2},?)+)<>(?<set_2>(\d{1,2},?)+)$/: means only stroke swaps are required to make the SVG Japanese-compatible. For example, my annotation for 奘 is s1<>2 (swap strokes 1 & 2); 學 is s1,2,3,4,5,6,7,8<>5,6,7,8,1,2,3,4 (remap the strokes on the left from the Chinese file to the order on the right for Japanese). I have a script which automatically processes files with this annotation into new SVGs for Japanese.

/*/: miscellaneous, i.e. anything not explicitly matching the above. Comments separated by ; but otherwise maintains the conventions above for brevity. s is stroke, <> means swap, f is form of. The annotation for 娜 is s⻏, meaning the stroke composition of⻏ requires attention, despite the form being identical; 寥 is f5,6,8,9, calling attention to the forms of the listed strokes; 寨 is s5,6,7<>7,5,6; f11-14木, indicating a stroke remap and a note on the forms of strokes 11–14. You get the picture. More general comments can exist, obviously, but that's the shorthand.

Using this shorthand, I can annotate characters rather quickly, and batch process annotated characters which are form-compatible using a script to parse these annotations. I reckon I will have comfortably annotated the entire list of 989 kanji present in a svgsHan* folder (as of when I last ran the analysis a few days ago, and the foundation for my working set) in a matter of weeks.

[i-h8-github]

Never mind, I'm already more than halfway through these; I'll be done in a matter of days. Probably better to just wait and give them all to you at once, then you can organize them however you want.

[parsimonhi]

I had never used SQLite and I just took a look to see how to install it. Just trying to understand what is needed for this installation "somewhere" is a nightmare.

I may sound a bit harsh, but this is absolutely not a solution for simply sharing data because it requires everyone involved to have SQLite available (if I understood correctly).

Of course, if you use SQLite frequently, it's easy. But that's not my case, it's not the case of the people I work with, and it's not the case for most people.

We shouldn't have to install a complex setup just to use a single data file once in our life.

[i-h8-github]

Unless you need dev headers (you don't), this should be all you need: https://sqlitebrowser.org/dl/

I guarantee that you and everyone you know have used SQLite countless times; you just weren't aware of it. It's a portable library that many, many applications embed directly into their software (like the app linked above). SQLite database files end in .db.

You don't have to know any SQL to be able to put that app to good use; Treat it as a super-spreadsheet.

I'm fine with good old text, by the way — it's just that you run up against limitations with that pretty quickly when there's a lot to keep track of or to search through or sort, especially if data is changing all the time. Since I'm basically dumping a bunch of info on you at once, it's less necessary than if we were going to have a lot of back and forth.