ちょっと書き込みの間が空いてしまって。
その間に、従来独立行政法人情報処理推進機構が担ってきた文字情報基盤事業資産の当協議会への信託譲渡契約も無事完了し、プレスリリースも出すことが出来た。まあ、煩瑣な手続きの大半は、田丸健三郎さんを初めとする事務局におんぶにだっこだったので、ぼくは余り偉そうなことは言えないが。
まあ、その間も、コロナ蟄居状態は続いているわけで、ぼく的には、相変わらず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桁を切り分ける処理に途方に暮れて、だったら各段の版面の一番下から段全体を対象に追っかけていけば、うまく切り出せるだろうと思ったら、豈図らんや、この段内の版面がそろっていないことが判明した、という次第。だって、活版なんだもの、致し方ないよなあ。
結局、だいたいのところを段ごとに処理し、エラーになった行を、別に取り出して、一、二、三の文字毎の例外処理を施す、という方法に切り換えた。
音訓情報のテキスト化は、、、、、今のところ、ギブアップ。。
新潮社の「日本語漢字辞典」は、絶対に電算組版で処理しているに違いないので、こっちの方を先にやろうっと。