調教モードに役立つ、GUIで編集できるボックスエディタを使うと、Tesseractが「文字グリフ」をどのように認識し「文字」へと変換しようとしているのかが、よく判る。ドキュメントページの「Overview」にある通り、ひと筆書きで辿れる輪郭形状が「ひとつのグリフ」と判定されがちである。
これは「i」「j」など一部の文字グリフしか「ひとつの文字なのにふたつ以上に分離したアウトライン」を持たない上に、隣り合う文字が喰いこんでいるような配列が行われ得るというラテンアルファベットを中心に設計されたOCRエンジン故の特性――と思っていいのだろう。
漢字のように扁と旁が左右に並ぶ文字を大量に含む用字系を常用する和文や中文においては致命的な誤判定を大量に招いてしまう。またカナやハングルのように分離した複数の線がひとつの文字グリフを構成するような文字種にとっても、好ましくない結果を招く。
7月17日付北上市ホームページ新着情報のテキストをアドビのSource Han Sans（日本語名「源ノ角ゴシック」（げんのかくごしっく））によってCJK表示させた画像を素材に、Tesseract-OCRの処理を見てみよう。
現代文で縦書きも多用するのはCJKのうち日本語だけであるそうだが、縦書きにおいては「上下型」の文字も誤認識される――例えば「責」なら「主貝」のようになる――ので、実に好ましくない。
こうした誤認識の問題に、unicharambigsに見られる下記のような変換定義で対処するのは資源の無駄と思える。
「不正」に見える文字は「柾」である
「イ尽」に見える文字は「侭」である
あらゆる木扁の文字、あらゆる人扁の文字、…を全て定義するのか？
通常は次のようにグリフ外形ギリギリに「ボックス」を定義するのだが――
――これを「活字の仮想ボディー領域」でボックス定義することで、複数の図形が合わさってひとつの文字を成しているということが理解されないものだろうか。
などと考えてみつつ、テッちゃんの思考のクセに何とか馴染もうと頑張っている。
あまりの手間に、調教される方じゃなくて調教してる方がドMなんじゃないかって気がしてきた。
