会長室のおもちゃ箱

日々気になったことを書き留めています。

一般社団法人文字情報技術促進協議会
会長
小林龍生

MJ戦記とほにゃらら戦記（書き始め）

2021年7月28日コメントはまだありません

先般(2021年7月9日)、協議会のメンバー限定で、文字情報基盤の信託譲渡、なかでも、MJ文字情報一覧表とMJ明朝についてのセミナーが開催された。講師は、IPAの元理事で、今は開志専門職大学で教鞭を執っておられる田代秀一さんと、当協議会の事務局長田丸健三郎さん。協議会の理事でもあるイワタの水野社長が、コーディネートの労をとってくださった。ぼくは最初に、会長として短い挨拶をしたのだが、話をしながら万感こみ上げてきた。いわば、「ああ、ぼくが手塩にかけて育ててきた文字情報基盤の成果物が、また、ぼくの手元に戻ってきた」という感慨。この感慨は、田代さんや田丸さんの話の間も、ずっと続いていた。お二人の話の話の端々から、文字情報基盤を開発していたころのさまざまな思い出が、ものすごくリアルにフラッシュバックしてくる。ほとんどが、結構大変だったけれど、今となってはいい思い出、の類。
田丸事務局長からは、このブログに一回は新し記事を投稿しろ、と厳命されている。「やる仕事があるのが、最大の老化防止策ですよ」と無茶苦茶なことも言う。まあ、その謂にも一理ある。そんなわけで、上梓してからもう10年以上経つ「ユニコード戦記」の後日譚を、時間軸では上梓前でも戦記に触れられていないこと共も含めて、少しずつ振り返っていきたいと思う。ボケ防止のためにもね。
「ユニコード戦記」の索引には、「汎用電子情報交換環境整備プログラム」という言葉は、1個所しか出てこない。233ページ。ちょっと長くなるけれど、話のとば口として、引用しておこう。

汎用電子情報交換環境整備プログラムとIVS

「ユニコード戦記」が発行されたのが2011年6月10日。畏友ヒデキが急逝したのが、2010年4月7日。ぼくにとっては、この汎用電子コレクションのIVD登録が、「ユニコード戦記」を擱筆する上で、とても大きな区切りとなった。次回は、この2010年から2011年ごろから、「ユニコード戦記」で書き漏らしたことどもを中心に、時を遡っていこう。
《事後的な注》
汎用電子プロジェクトには、「戦記」に登場する高田さんの他にも、今でも協議会かかわっている人たちがいる。副会長の山本さん (アドビ)が文字グリフ作業委員会の委員長として、加除の野島さん(当時は富士通)が副委員長として、係わっていた。まあ、狭い業界と言えば狭い業界なのだけれど、往時の事情を知る専門家が、身近にいることも、この協議会の大きな強みでもあるね。ぼくの（老化現象による）記憶違いも正してもらえるし。

ユニコードでIVSをめぐる議論が行われていたさなか、日本でも外字問題に決着をつけるべく大規模なプロジェクトが進行していた。汎用電子情報交換環境整備プログラム。このプログラムは、もともとは情報処理学会が主催していた文字コード委員会での議論を踏まえて、佐藤さんとぼくが戸籍実務や住民基本台帳実務で用いられている漢字の悉皆調査が必要なことを経済産業省に訴えたことが契機となったものだった。ぼくたちの働きかけが奏功して、2002年から情報処理学会、日本規格協会、国立国語研究所が共同受託する形で、この汎用電子情報交換環境整備プログラム(以下汎用電子プログラムと略す)が開始された。佐藤さんとぼくは、問題提起をした関係もあって当初は積極的にこのプログラムの推進に協力していたが、プログラムの具体的な運営方法についての他のステークホルダーたちとの考え方のちがいから、実際のプログラムには参加することにはならなかった。プログラムは予想以上に、否、佐藤さんやぼくが予想していたとおり、2008 年になって、当初予定された期間が過ぎても、目に見える形での成果が見えてこない。そのために、さらにフォローアップのための予算措置が講じられた。ぼくは、経済産業省の担当者からプログラムの成果を標準化プロセスにのせるための小委員会に参加することを要請された。汎用電子プログラムは当初、総務省が所轄する住民基本台帳ネットワークに用いられる文字集合(住基ネット統一文字)と、法務省が所轄する戸籍に使用される可能性のある文字集合(戸籍統一文字)を整理統合するところから始まり、のちに登記簿謄本に実際に使われている文字集合(登記統一文字)が加えられた。作業の多くは、当初は笹原宏之さん (プロジェクト途上で早稲田大学に異動)、のちにそれを引き継ぐ形で高田智和さんという国立国語研究所の気鋭の研究者が中心となって基礎調査研究を行い、それの基づいて具体的な平成明朝体のグリフを設計する作業が並行して行われた。ぼくが参画した標準化作業委員会は、それらの成果を可能な限り国際標準に反映させるという役割を持っていた。この一連の作業の結果、汎用電子プログラムの成果の一部は、日本から統合漢字への採録が提案され、拡張CおよびDの一部として標準化された。また、従来のUCSの統合規則では統合の対象となる字形について当初は互換漢字領域への提案として準備が進められたが、IRGやWG2におけるUSやUTCからの強い勧めもあり、最終的には互換漢字領域への提案を取り下げて、ユニコードに対してIVD登録することになった。そして、2010年12月14日、正式に登録が完了した。IVSについて、なによりも特筆すべきことは、 2009年になってマイクロソフトがWindows7に、アップルコンピュータがMac OS Xの最新版に、IVSの表示機能を盛り込んだことだ。アドビのAcrobat9への実装やマイクロソフトのWindows7への実装、Msc OS Xへの実装が市場に投入されたことで、IVSはやっと実用的な普及段階に突入した。ヒデキとぼくがVSのアイディアをUTCに提案してから、すでに12年の年月が流れていた。(p.233~)
拙著『ユニコード戦記』（東京電機大学出版局、2011年）

《事後的な注》

汎用電子プロジェクトには、「戦記」に登場する高田さんの他にも、今でも協議会かかわっている人たちがいる。副会長の山本さん (アドビ)が文字グリフ作業委員会の委員長として、加除の野島さん(当時は富士通)が副委員長として、係わっていた。まあ、狭い業界と言えば狭い業界なのだけれど、往時の事情を知る専門家が、身近にいることも、この協議会の大きな強みでもあるね。ぼくの（老化現象による）記憶違いも正してもらえるし。

MJ文字図形名とUCS符号位置との対応

2021年6月3日コメントはまだありません

久しく間が空いてしまいましたが。まあ、コロナ禍で、世間全般が半ば開店休業状態でもあるし。
とはいえ、ぼくはぼくなりに、コロナ蟄居状態をそれなりに楽しんでいる次第で。

その一つが、IPAから信託譲渡を受けた文字情報基盤の成果物に対する、Henry Chenさんからのコメント。文字情報一覧表のUCS符号位置との対応関係がおかしいのではないか、というコメントをいただいた。Henry Chenさんは、IRGで活発に活動している中国の専門家。ぼくは、最近のIRGには参加していないので、多分、直接の面識はないが、名前はよく耳にしている。Chenさんも文字情報基盤に注目してくれているのだ、と思うと悪い気はしない。押っ取り刀で、コメント内容を調べてみた。

問い合わせは二つ。いずれも、MJ文字図形名とUCS符号位置との対応関係に関するもの。
一つが、MJ054422が、現在は、U+2995Cになっているのだが、正しくはU+29946ではないか、というもの。
もう一つが、MJ046645が、現在は、U+26D1Fになってるのだが、正しくはU+26C5Dではないか、というもの。

調べてみると、どちらも戸籍統一文字に含まれており、大漢和辞典にも収載されている。この際だから、大漢和辞典の該当個所もクロップしておこう。

ご覧いただけば、一目瞭然だが、分はChenさんの方にある。
とはいえ、正すは正すにせよ、どうして、そして、いつどこで、このような誤りが紛れ込んだのかが分からないと、いかにも落ち着きが悪い。何よりも、2個見つかったということは、もっとある可能性が高い。これから、文字情報基盤事業成果物が、自治体などの実務システムに使われることがますます増えていくことが想定されるが、実装が増加する前に、正すべきは正しておきたい。

こうして、コロナ蟄居の間の、楽しい暇つぶしの調査が始まった。

調査の大筋は、二つに分かれる。
一つは、MJ文字図形とCJK符号位置の、それぞれどの部分が怪しいかを見極めること。
もう一つは、怪しい部分から、問題になりそうなMJ文字図形名とUCS符号位置の組を洗い出すこと。
MJの文字情報一覧表には、5万字近くの文字が収載されている。また、CJKの側は、今では、9万字ほどもある。
これらを、総当たりで調べるのは、いくら何でも気が遠くなる。何とか絞り込めないだろうか。

最初に頭に浮かんだのが、拡張Bが怪しい、ということだった。

ご存じの方も多いと思うが、UCSの漢字パートは、大きく、統合漢字(Unified Ideographs)と互換漢字(Compatibility Ideographs)に分けられる。さらに、それらに、拡張パートや補遺やらが加わって、今では、9万字余りの漢字に符号位置が与えられている。その中でも、拡張Bは規模も大きく、康煕字典の全ての文字を収載することが一つの大目標になっていたこともあって、一般にURO(Unified Repertoire and Ordering)と呼ばれている初版時からあるパートに次いで重要なパートと言えよう。しかし、今から振り返ると、規模が大きいせいもあって、どうも品質的にはイマイチではないかなあ、という疑念がぬぐいきれない。

それはさておき、康煕字典とともに、大漢和辞典は、規模の点でも信頼性の点でも、中国や台湾も含めた漢字圏内では非常に高く評価されている。余談ではあるが、台湾には大漢和辞典の海賊版が売られており、紀田順一郎さんなどは、「台湾の海賊版の方が紙質が悪い分、軽くて使いやすいぐらいですよ」とおっしゃっていたことを記憶している。
閑話休題。当然ながら、康煕字典は大漢和辞典編纂の折の基本典拠の一つだったわけで、収録字数もほぼ同規模になっている。
そして、日本の行政における人名用漢字使用（特に姓）の拠り所となっている戸籍統一文字は、法令に則ったこともあって、大漢和辞典を初めとする市販の大規模漢字辞典の見出し字を原則的にはすべて含んでいる。

というわけで、拡張Bを含むUCSが発行されたのが2001年で、汎用電子情報交換環境整備プログラムが開始されたのが2002年なので、汎用電子〜が開始された時点で、拡張Bはすでに国際規格として成立していたことになる。
汎用電子〜のプロジェクトメンバーが、戸籍統一文字に対応するUCSの符号位置を調査しようと試みたとき、その対象の多くが拡張Bに含まれていたことは、このような経緯から、ほぼ確実なことだった。ぼくが、「拡張Bが怪しい」と思ったのは、このような背景があったからに他ならない。（ま、急いで付け加えておくと、後から冷静に考えてみると、という条件付きではあるのだけれど。）

この辺りの事情を、汎用電子情報交換環境整備プログラムのころから一貫してこのプロジェクトの係わってこられた、国立国語研究所の高田智和さんに、メールで問い合わせてみた。何度かのやりとりがあったのだけれど、経緯を簡単にまとめると、だいたい以下のようなことだったようだ。

汎用電子情報交換環境整備プログラムから文字情報基盤整備事業に至る一連の活動は、戸籍統一文字と住基ネット文字という成立時期も策定方法も全く異なる二つの独立した文字集合を、UCSという国際的に認知された公的規格をピボットとして関連づける営為だった。
そこで、UCSとともに重要な役割を果たしたのが、大漢和辞典という民間で編纂された世界的にも評価が高かった漢字辞典だった。（※IRGで同文書局版の康煕字典がいわばバイブルとして用いられたこととを考え合わせると何だか興味深いなあ）
汎用電子情報交換環境整備プログラムの始めのころは、JIS X 0221解説のUCS（拡張Aまで）大漢和対応表が、ピボットとして用いられた。
※このJIS X 0221は、2001年に発行されたもので、ははは、ぼくも原案作成委員会の一員に名を連ねている。問題の対応表は、解説付表1というもの。
その後、汎用電子情報交換環境整備プログラムでは、UCS符号位置の範囲を拡張Bにまで拡張して、調査を行った。
文字情報基盤整備事業では、この汎用電子情報交換環境整備プログラム成果（拡張BまでのUCSとのマッピング）を前提として、UCSとのマッピングがないもののUCSへの追加提案がなされた。さらに、UCSで統合されるものについては、IVDへの登録がなされた。

そういうことか。この汎用電子情報交換環境整備プログラムにおける対象文字（戸籍統一文字と住基ネット文字の和集合）とUCS拡張B符号位置との対応関係調査でバグが紛れ込んだのだ。他の部分については、曲がりなりにもISO/IECやJISなどの公的規格に拠り所がある。
急いで付け加えておくが、その後の調査で、さらに20個所弱の疑問点が浮かび上がっているけれど、それでも対象となるペアの0.1%以下なのだ。関係者の間では常識となっているが、UCSそのものにも（特に拡張B）まだバグが残っていて、時々思い出したようにエラーレポートが報告される。ある程度以上の規模の文字集合間の対応関係にバグやバグとは言えないまでの見解の相違が含まれるのは、不可避なことなのだ。
どうも、問題は、現象面としてのバグにあるのではなく、文字情報一覧表に記載されているMJ文字図形名とUCS符号位置との対応関係の一部（というか半数以上）に、UCSやJISなどの公的規格に拠り所を持たないものがある、という点にあったのだ。

経緯を整理したおかげで、俄然視野が拓けた。問題の要は、UCSのJソースなのだ。と言っても、一般の方々には何のことだかチンプンカンプンに違いない。UCSに記載されている典拠情報（ぼくらの中ではCJKソースと言い習わしている。日本提案のものは、Jソース）について、ちょっと説明しておこう。

UCSの規格票をご覧になったことのある方々は、お気づきだと思うけれど。規格票のCJKパートには、例示字形の下に、何やら訳の分からないアルファベットと数字の組合せが記されている。先に挙げた、Henry Chenさんのコメントの例だと。

UCS2003とかGXX-1442.30とかTF-667Dとか。
これらは、関係者の中ではCJKソースといか典拠情報とか呼ばれていて、それぞれの国や地域からの提案の拠り所となる規格を示している。
もちろん、日本から提案した物には、一番最初がJで始まるおまじないが付いている。

へへへ。ぼくの名前の「龍」の例だと、左から4番目のJ0-4E36というのが、日本の原規格で、最初のUROが制定されたころから入っているJIS X -208起源ということが分かる。文字情報基盤整備事業の過程で日本から提案されたものもある。

これって、一部の業界人（文字コード屋）の間では有名な文字なんだけれど、これだけで「えだなし」と読む。「木」から枝をはらった文字だから「えだなし」。
こうして見てくると、文字情報一覧表に記載されているUCS符号位置の一定程度（調べてきたら2万字強）は、UCSの側に、MJを含む日本の規格（JIS規格だけではなく、ARIBなどの業界規格も含む）の情報が記載されていることが分かるだろう。

文字情報基盤の文字情報一覧表に記載されたMJ文字図形名とUCS符号位置との対応関係が、UCSの側に拠り所を持っているとは、すなわち、UCS符号表の該当位置に、Jソース（MJ文字図形名やJISだけではなく業界標準も含む）が記載されている、ということに他ならない。今回のChenさんからのコメントに即して考えてみよう。
Chenさんコメントの分は、誰がどう見ても、Chenさんの方にある。これって、明確なバグだから直さなくっちゃ、と思う。
しかし、文字情報一覧表も、MJ明朝も、すでに様々なところで実装されて用いられている。該当する文字がどこかで使われている可能性はゼロではない。とすると、例の後方互換性の問題が出てくる。あるフォントの特定の符号位置の表示字形を恣意的に変更すると、どこでどのような不具合が生じるか、ちょっと予測がつかない、というか、どこまで行っても予測不可能な不具合が生じる可能性が残る。この厄介な問題のおかげで、UCSでは、一度決めた文字名や例示字形は原則的に変更を行わない。やむを得ず変更する場合も、可能な限り既存の情報を残した上で、新しい符号位置や例示字形を追加し、変更情報は規格本文に明記する。
この伝で行くと、文字情報一覧表の情報は、更新履歴を明記した上で変更し、MJ明朝は、既存のUCS符号位置から該当MJ文字図形への対応を残したまま、新たな（正しい）UCS符号位置から該当MJ文字図形への対応を追加することになるだろう。
しかし、というか、それでも、というか。
オープンな環境で使われることが前提となっている文字情報一覧表やMJ明朝フォントの情報を、発足間もない弱小一般社団法人が、そうやすやすと変更してしまって良いものだろうか。

どうやら、当面の結論にたどり着いたようだ。
文字情報技術促進協議会としてなすべきこと。

MJ文字図形のうち、対応するUCS符号位置にJソースの記載がないものについて、再調査して、さらなるバグの低減を図る
その上で、しかるべきルートで、UCSへの該当MJ文字図形名の追加を提案する。

ああ、やっとスッキリした。
再調査の具体的なやりかたについては、技術的な話も含めて、いずれ。

音訓索引

2020年12月1日コメントはまだありません

ちょっと書き込みの間が空いてしまって。

その間に、従来独立行政法人情報処理推進機構が担ってきた文字情報基盤事業資産の当協議会への信託譲渡契約も無事完了し、プレスリリースも出すことが出来た。まあ、煩瑣な手続きの大半は、田丸健三郎さんを初めとする事務局におんぶにだっこだったので、ぼくは余り偉そうなことは言えないが。

まあ、その間も、コロナ蟄居状態は続いているわけで、ぼく的には、相変わらずPythonでちょこちょことプログラムを書いて、過ごしている。ここのところ、集中してやってきたのが、大字源の音訓索引の電子化。最終的には、以前自炊しておいたページイメージへのジャンプを、と考えて作業を始めたのだけれど、意外と厄介でね。いろいろなレベルで問題が次々に出て来て、退屈する暇が無くって。

そもそも、漢字の音訓そのものが、結構厄介な代物なのだ。その位置づけというか。

例えば、JIS X 0213にも音訓情報が記載されているが、附属書6（規定）には、「m)音・訓（参考）辞書・辞書に見られる代表的な音を片仮名で示し、訓を平仮名で示す。この欄は、参考であって規定の一部ではない。」との記載。だれが、代表的な音・訓を選んだのだろうね。ぼくの記憶では、常用漢字については、国語審議会（当時）が示した音訓表の情報がそのまま転記されていたように思うけれど、どうだったかしらね。

文字情報基盤の文字情報一覧表に記載されている音訓情報も、じつは、よくわからない。基本的には、文字情報基盤事業の前身だった汎用電子情報交換環境整備プログラムの報告書がベースになっていることは間違いないのだけれど。

音訓情報については、どうも気持ちの収まりが付かないので、何かの機会に、文化審議会国語分科会で常用漢字表の改定をとりまとめられた元筑波大学教授で図書館長も務められた林典史さんや、国立国語研究所の高田智和さん、それに、そのころ新字源の編集に携わっていたKADOKAWAの坂倉基さんなんかに、「音訓情報ってどうなのよ」みたいなことを、聞いてみたことがある。答えは、異口同音に「音訓情報はねえ」といった曖昧なもの。ああ、専門家でも音訓情報には難儀しているのだとわかって、変に気持ちが落ち着いた。

今回、大型市販辞書の音訓索引を電子化しようと思い立ったのも、このあたりの曖昧さに、ぼくなりの決着をつけたいと思ったから。大型辞書に記載されている音訓情報は、全部でこれだけです、と断言したかったわけ。

ところがどっこい、ことは、そう簡単なものではありませんでした。

音訓索引の構造

他の辞書も似たり寄ったりだが、大字源の音訓索引も、要素としては、読み情報、対応する漢字のイメージ、その漢字が掲載されているページ数からなっている。一部、検字番号を直接示しているものもあるが、多くは、掲載ページ。これが、電子化の際の、第一のやっかいごと。該当する見出し文字の記述に直接ジャンプすることが出来ない。

漠然とだけれど、ぼくが構想している電子化漢字辞典は、iPadなどのタブレットPC上で閲覧できるものにしたいと思っている。そうなると、辞典の全ページを一画面に表示するのはちょっとキツい。ズームアップを使えばいい、という考えもあるが、使いやすいとは言えないだろう。

そこで、考えているのが、各ページを分割して、カラムごとに表示する、という方法。タブレットの画面を横にすれば、なんとか1段分を可読表示できそうだし、空きスペースを検索窓やナビゲーションボタンに使うこともできそう。

ところが、現在の音訓索引のページ情報からは、対応ページのどの段に該当漢字があるかが分からない。これが第一の問題。この問題の解決は、データの整備がある程度進んで、アプリケーションの構造とUIを考えるまで先送りすることにして、データ整備の作業に入ることにした。

OCR作業の問題

次の、というか、最大の問題が、読み情報とページ情報のテキスト化。というか、電子化とはそういうことだよね。該当漢字のイメージは、画像情報をそのまま切り出せばいいので、多くを考える必要はない（とはいえ、実際には、デジタル画像のゴミがいろいろなところで悪さをしてくれるのだが、それはまた別の話）。

手順としては、1ページ分の画像情報を段ごとに分割し（大字源の音訓索引は10段）、それをさらに1行毎（【】付の大見出しは2行取り）に分割した上で、読みの画像、対応漢字の画像、対応ページの画像に切り分けて、OCRにかければいい。

と思っていたぼくがバカだった。手元のパナソニック製のOCRもPythonから使えるTesseractのOCRも、索引情報には、仮名文字にも漢数字にも、驚くほど無力なのだ。急いで、付け加えておくが、一般の新聞記事や小説などは、それは見事にテキスト情報化してくれるのだが、なぜか、仮名文字だけ、とか、漢数字だけ、とかは苦手なようで、日本語指定しておいても、よけいな漢字や記号に置き換えてしまうことが多すぎるわけ。TwsseractのOCRをカスタマイズすることも考えたけれど、何だかめんどくさそうだし、そもそも、ディープラーニングでトレイニングするためのサンプルデータの準備を考えただけで気が遠くなる。

で、実際には、以前、IRGの新レパートリーとUCSの既存の符号位置に存在する文字との重複をチェックするために作った仮称なんちゃってOCRを流用することにした。

もともとのなんちゃってOCRは、画像として似ている漢字をラフに拾い出してきて、細かなチェックは人力（eye ball check）で行い、という方針で作ったもの。

pythonのnumpyを活用して、画像情報をarrayに置き換え、array間のコサイン近似値を比べる、というだけのもの。とはいえ、これはこれで、地ベタを這うような、IRGのレビュー作業には大いに役立ったが。

今回は、音訓情報でも、平仮名片仮名だけだし、ページ情報に至っては、漢数字10文字だけなので、文字の切り出しさえうまくいけば、ことは簡単なはずだった。

ところが。この、文字の切り出し作業に、おもわぬ伏兵が潜んでいて、大苦戦を強いられることになる。

最初に手を付けたのは、角川書店の「大字源」。1992年2月2月10日初版発行。ぼくの手元には、3月10日の再版と自炊した1993年1月10日の第3版がある。実際の作業に使ったのは、この自炊した第3版。この大字源は、まえがきにもあるように、活版活字で組まれている。というか、かの諸橋大漢和でさえ、ごく初期のものとはいえ、写真写植で制作されたものだし、大字源の印刷もあきらかにオフセットなので、活版活字で組まれていたなんて、考えてもみなかった。

しかし、この《活版活字で組んだ》ところに、思わぬ落とし穴が潜んでいた。すなわち。

大字源の音訓索引は、本文に掲載されている音訓情報を、五十音順に並べて、対応する掲載ページ数を記載する形式になっている。

ぼくがやろうとしたのは、この音訓索引を1項目ずつ（すなわち1行ずつ）切り出し、さらに音訓情報（平仮名もしくは片仮名）とページ数（漢数字）とに切り分けて、それぞれ何らかのOCRにかければいいだろう、とったものだった。

ところがところが、これがとんでもなく面倒なことに相成った。切り出しまでは、まあ、適当な作業で、そこそこうまくいくのだが、以外や以外、OCRがね。試してみたOCRは、Panasonicの読み取り革命Ver.15と、Python3で動く、TessorOCR。それぞれ、一般の日本語文書（特に横書き）のデータの処理に関しては、結構優秀な結果を出してくれる。それが、音訓情報の平仮名や漢字、ページ数の漢数字になると、なぜか全然使い物にならない。よけいな漢字が混じったり、記号類と間違えたり。そもそも一文字一文字の切り出しがうまく処理できないようなのだ。

しかたがないので、市販の（Tessorocrはオープンソースだけれど）OCRを使うのは諦めて、どうせ字母数が限定されているのだからと、先に触れた2次元ヒストグラムのコサイン類似を用いた手製の簡易OCRで処理することにした。

ところがところがところが。何しろ、手製の簡易版なので、文字列からの一文字一文字の切り出しなどという気の利いた機能は持っていない。文字列のままでヒストグラムを取るか、事前に一文字ずつ切り出す作業をしなければならない。この一文字ずつの切り出し、それも漢数字の切り出しに、とんでもなく苦労する仕儀と相成った。

なんと、各段のページ数の漢数字の位置がそろっていないのだ。見た目では分からない。しかし、スキャン情報を子細に調べてみると、微妙に揺れている。というか、最初は、一行ずつ切り分けて、バウンディングボックスでクロップしたら、漢数字って、特に一、二、三で、高さが違うのね。4桁の場合だと、1の桁と1000の桁では、文字列の高さが全然違うの。4桁を切り分ける処理に途方に暮れて、だったら各段の版面の一番下から段全体を対象に追っかけていけば、うまく切り出せるだろうと思ったら、豈図らんや、この段内の版面がそろっていないことが判明した、という次第。だって、活版なんだもの、致し方ないよなあ。

結局、だいたいのところを段ごとに処理し、エラーになった行を、別に取り出して、一、二、三の文字毎の例外処理を施す、という方法に切り換えた。

音訓情報のテキスト化は、、、、、今のところ、ギブアップ。。

新潮社の「日本語漢字辞典」は、絶対に電算組版で処理しているに違いないので、こっちの方を先にやろうっと。

文字情報基盤事業の資産（1）

2020年5月24日 1件のコメント

ようやく、IPAとの信託譲渡契約が締結段階に入った。そろそろ、軸局から手続き終了の知らせた入るころ。
コロナウィルス騒ぎで、自宅にいる時間が少し（以前からそれなりに閑だったけれど）増えたこともあり、ここのところ、IPAから信託譲渡される文字情報基盤事業の成果物（以下、MJ資産）について、主にPythonで簡単なプログラムを書いて、いろいろ調べている。それこそ、時の経つのを忘れるぐらい、面白い。
MJ資産の主軸は、あくまでも、すでに公開されているMJ文字情報一覧表とIPAmj明朝にあることは言うまでもないけれど。
当初からこの事業に係わってきた身としては、一覧表成立に至るまでのさまざまな中間成果物に、魅力とある種の愛着を覚えるわけだ。中でも、市販の大型漢字辞典関係の情報は、多くの好事家にとっても、垂涎物だろうと思う。
MJ事業で対象とした辞書は、以下の5点。
大漢和辞典（大修館書店）
新大字典（講談社）
大字源（角川書店）
日本語漢字辞典（新潮社）
大漢語林（大修館書店）
大漢和辞典は別格としても、日本を代表する大型辞典が網羅されている。
MJ事業で調査した情報は、大きく3つに分類出来る。
なによりも、MJ文字図形名と各辞書の検字番号との対応表。
次に、各辞書の検字番号と掲載ページの対応表。
そして、各辞書に記載されている見出し文字間の関係。
MJ文字図形名と検字番号の対応関係は、一覧表に掲載されている。
見出し文字間の関係は、MJ文字図形とJIS X 0213の縮退マップを開発する際に、大いに役立った。
問題は、検字番号と掲載ページの対応表。
以前、大修館書店の担当者と情報交換を行った際、この対応表は、絶対に公開しないでもらいたい、と強く言われた。この対応表があると、ページイメージベースであれば、電子辞書が簡単に開発出来てしまう。
実際、ぼく自身は、上記の辞書すべてを私費で購入したうえで自炊し、ページごとのPNGファイルに分解してあるので、それこそ、Pythonから簡単に呼び出すことができるようになっている。
辞書系の電子書籍の核心がインデックスにあるということが、自分の体感からも大修館書店担当者の謂からも、よくわかる。
ともあれ、この検字番号とページとの対応表は、死蔵するにはあまりにも惜しい情報だ。何とか、版元の利益を毀損しない形で、世に出すことは出来ないものか。

一方、各辞書を自炊した目的の一つに、各見出し文字の切り出しがあった。こちらの方も、Pythonを使って、いろいろ悪戦苦闘してなしとげたのだけれど、今調べているのは、MJ文字図形との対応関係が取られていない見出し字について。
戸籍法だったか戸籍法施行規則だったかに、戸籍に記載してよい文字の条件に、「市販の辞書に記載されていること」という条項があったように思う。だとすると、MJ文字と対応関係の取れない見出し文字が、将来、戸籍統一文字に追加され、MJ文字一覧表やIPAmj明朝でも対応を迫られることがないとは言えない。
実際、最近も《ささ》という字が、日本語漢字辞典に掲載されていることを根拠に、戸籍統一文字に追加されたという事態もあったことだし。

以下、辞書関係のデータの中身を、すこしずつ見ていこう。

まずは、それぞれの辞書の総文字数。ぼくは、OED(Oxford English Dictionary)を気取って、それぞれの辞書に3文字のアブリビエーションを充てて使っている。

大字源:DGJ
大漢語林:DKR
大漢和:DKW
日本語漢字辞典:NKJ
新大字典:SDJ

DJG:12300
DKR:13938
DKW:51110
NKJ:15375
SDJ:21094

対応するMJMJ文字図形名を持たない見出し字の数は、下記の通り。

戸籍統一文字に追加するための要件の一つが市販の漢字辞典に記載されていること、だとすると、これらの文字は、潜在的に将来戸籍統一文字に加えられる可能性がある、ということになる。とは言え、字体弁別の尺度は、これまた辞書によっても異なる。辞書に別見出しとして掲げられているからといって、無条件に（戸籍統一文字の尺度で）別字体だとは断言出来まい。このあたりは、今後の漢字行政上の大きな論点になりそうな。

DJG:41
DKR:41
DKW:1610
NKJ:620
SDJ:491

活字箱と漢字の使用頻度（2）

2020年5月19日 2件のコメント

漢字使用頻度の続き。
前回触れた、凸版印刷の頻度調査資料、じつは、ぼくも一部持っている。正確に言うと、持っていた。書架の資料の増殖に耐えきれずに、自炊してしまったので。
以前ジャストシステムに勤めていたころ、ちょうど、千年紀の変わりめあたりの表外漢字字体表策定の折、浮川和宣社長が当時の国語審議会の委員を委嘱され、浮川社長を補佐するために、国語審議会の審議を継続的に傍聴していた。それと相前後して、当時文化庁国語課の専門官だった淺松絢子さんや氏原基余司さんの知遇を得た。まあ、その役得で、国語課が、委員会審議のために準備したさまざまな資料集を分けていただいた。その中の一冊。
それにしても、ぼくが管見しただけでも、凄まじく貴重な労作がそろっている。中でも、小宮山博史さんが明治以降の活字見本帳を切り貼りした字形集など、垂涎物。
いずれにしても、常用漢字表が、これらものすごい資料に立脚して策定されているということは忘れてはならないだろうな。
で、この凸版の資料を（自炊してしまっていたことを失念して）書架で探し回っていたら、「JIS X 0213:2004運用の検証」という平成21年9月発行の国立国語研究所の研究成果報告書が目に留まった。
研究リーダーだった高田智和さんに頂戴したものだけれど、その時は、あまり詳しく見ることなく書架に眠ったままになっていた。灯台下暗し。改めて眺めてみると、これがものすごく面白いの。

この高田さんらの研究報告「JIS X 0213:2–4運用の検証」は、下記からPDF版をダウンロードすることが出来る。
https://pj.ninjal.ac.jp/corpus_center/bccwj/doc/report/JC-D-09-01.pdf
検証のために用いられた資料は、『現代日本語書き言葉コーパス』の一部。
ちょっと面白うなあ、と思うのが、国語審議会（今は文化審議会国語分科会）のための凸版データとの相違。
凸版のデータは、凸版が扱った商業出版物のデータを元にしているのに対し、高田さんの調査は、国研のコーパスという優れて正規化されたデータを元にしている。いま、不用意にと言うか、なにげなくと言うか、「正規化」という言葉を遣ったけれど、もしかしたら、ここが大問題なのだな。
先に進めなくなってしまったか。活字箱問題に逆戻り。
先に、活版時代の文選工の前に置かれた活字箱には、ほぼ4千種の活字が収められていた、と書いた。
文選工は、著者の原稿を目の前において、活字箱から活字を一本一本ピンセットで拾い上げて、手元の箱に収めていく。悪筆の高名な作家に、専属の文選工がいて、担当編集者も読めない原稿から正確に活字を拾っていった、といった伝説もある。このような印刷工場の現場の知が、活版時代のゆたかな出版文化を支えていたことに間違いはないのだが。
この現場の営為と表裏をなすものとして、校閲ないしは校正と呼ばれる、編集者側の営為があった。編集者時代のぼくは、ザル校で有名だったので、あまり偉そうなことは言えないけれど。

高田さんらの研究報告書に戻って。

この報告書で、一番、印象的だったのは、表5のJIS X 0213:2004による符号化（延べ字数）。

第1水準から第4水準別に、非漢字も含めて、用いられた符号位置の累積頻度が非漢字も含めた表なので、漢字だけに絞って、それも、全資料の分だけ、換算してみると。

第1水準：99.478%
第2水準：0.459%
第3水準：0.061%
第4水準：0.004%

前回書いたように、JIS X 0208の第1水準の漢字総数は、2965字。これだけの字数で、一般的な日本語文書の99%以上が表記かのうなわけ。JIS X 0208が発行されたのは1978年。漢字選択は林大氏を中心にすすめられたと聞くが、今になってもこの選択がいかに適切だったか、ということが分かる。

まあ、JIX X 0208は、その後の、1983年の改正の折に行った非互換な字体変更や、符号位置の入れ替えが、その後に禍根を残すことになるけれど、それはまた別の物語。

林大氏らの、原案作成委員会の方々が、当時はまだまだ現役として稼働していた活版の活字箱を覗いていた姿を想像するだけで、何だかわくわくしてくる。

世紀をまたいだ2020年現在でも、たとえば、飯田橋の印刷博物館を訪れると、活字箱を用いた活版印刷の姿が動態保存されているのを見ることが出来る。

ChiseプロジェクトのIDS

2020年5月7日コメントはまだありません

コロナウィルス騒ぎで、ほぼ自宅蟄居状態なのをいいことに、文字情報基盤の成果物をいろいろいじくっている。最終的には、6万字ほどもあるMJ文字図形から一文字を対話的に探し出せるプログラムのプロトタイプを作りたいなあ、などと。
漢和辞典などでは、音訓索引を使うか、部首画数順で調べる、というのが常套だし、UCSのCJKもパート毎には、（原則的には）康煕字典の部首画数順に並んでいるので、部首画数というのが基本になる。
とはいえ、なにしろ、6万字もあると、生産性の高い部首（たとえば、氵とか木とか艹とか魚など）では、同一画数に百字以上も、ずらーとならんだりする。さらに、画数がくせ者で、IRGの議論でも、ちょっと複雑な字になると、なかなか一意には決まらない。
そんなこともあり、数年前から新しい文字セットの提案に当たっては、漢字を要素の構造で表現するIDS(Ideographic Description Sequence)を必ず添付することになっている。
まあ、このIDSもなかなか一意には定めにくいので、なんだかなあ、というところもあるのだが、ないよりはずっとありがたい。
IDSに関しては、世界的に見ても、京都大学の守岡さんChiseプロジェクトのものが最も充実していて、データとしてもきれいに書かれているように思う。
で、閑だし、久々に、というか、自分自身の目と手では、多分初めて、ChiseのIDSを調べてみた。
驚いたことに、そして、大変ありがたいことに、いつのまにか、拡張FまでのUCSすべてにIDSが付いている。それに、UCSに含まれない字形構成要素を用いる場合も、XMLなどで標準的に用いられている外部実体宣言（&と;で囲んだ文字列）の書式を用いていてくれているので、はなはだ扱いやすい。
というわけで、ChiseのGitHubから、全データをダウンロードして、いろいろ眺めている。
眺めていて気付いたのだが、なんと、MJ文字図形名やAJ1のいわゆるCID番号が構成要素として、結構な数、埋め込まれている。
おっ、守岡さん、なかなかやるねえ。
とはいえ、ぼくのゴールは、漢字の構造を正確かつ厳密に記述することではなく、あくまでも、漢字を探すことなので、構成要素の細かな差異に拘泥する必要はない。むしろ、疑わしきは捕捉、という感じで、字形が似た字は、適度に拾い上げられた方が、都合がいい。それに、検索の際に、知らない字や入力の面倒な字を、検索画面に入力することもないだろうし。
そんなわけで、ChiseのIDSデータを、ぼくなりに、少し加工して、いろいろ調べている。
まず、やったことは、MJ文字図形名やAJ1のCID名を、UCSの符号位置に置き換えること。その際、IVSは無視して、全部、UCSのベースキャラクターに置き換えた。MJやAJ1以外の外部実体宣言で書かれた要素も、えいやで、〓（ゲタ）に置き換えた。
で、いろいろ試していることの報告は、明日にでも。

MJ文字図形名	MJグリフイメージ	UCS（現）	UCS（Henry提案）
MJ054422
MJ046645