カテゴリを追加の最近のブログ記事

 前項で述べたように、学習辞書を作ってそれをe.Typistの作業ファイル上で走らせれば、ある程度までの修正は実現できる。
 しかし、この学習辞書はひとつのファイルごとに100組しか作れないし、そもそも単純置換だから効率が悪い。これを高性能テキストエディタでマクロを作れば大量の一括修正ができるし、タグ付き正規表現を使うことによってより効率よく修正ができる。たとえば前項の例で言えば、「間」を「問」や「聞」と読み違えることが多いので、これを「\([入期空時月中仲人年民林]\)[問聞]→\1間」という検索・置換のセットを作るだけで11×2=22通りの間違いパターンを一括修正できるわけだ。句読点間のアキなどを削除するには「(全角スペース)\([「『(]\)→\1」とか「\([」』)]\)(全角スペース)→\1」などのセットで処理できる。正規表現についてはここではくわしく説明しないが、こうした置換セットをいくつも束ねてファイルにしたものがマクロファイルと呼ばれるものであって、これらは読み間違いをさらに発見したらそのつど増補していけば、精度はどんどん上がっていくはずである。
 最終的にはさまざまな誤読があるので、マクロ処理だけですべて解決するわけではないが、こうした操作をあらかじめほどこしてしまえば、相当程度の修正ができるはずである。理論上は簡単だが、これは経験の集積がものをいうので、当面は99%の修正率をめざすことにして、以下に秀丸エディタを例にして作ったマクロを紹介しておこう。これはまったくの製作途上のものであるので、いまのところ精度はまだかなり低いものであることをお断りしておく。

//。のあとの改行を段落の終りと見なして次行の行頭にスペースを入れる(注:段落中に句点があり、カッコ類がくる場合も改行されてしまう欠点がある。)
replaceallfast "。\\n","。\n ",inselect,regular;

//ページの終りマークを削除する(注:e.Typistの場合、原稿のページ区切りに「[End of Page ......」という文字列が入るので削除するコマンド。)
replaceallfast "---------------------[End of Page \\f[0-9]+\\f\\]---------------------","",inselect,regular;

//不要な改行コードを一括削除する(注:原稿の一行ごとに強制改行が入るのを削除するコマンド。)
replaceallfast "\\n\\f[^ 「『]\\f","\\1",inselect,regular;

//単純置換
replaceallfast "!","!",inselect,regular;
replaceallfast "\\?","?",inselect,regular;
replaceallfast "\\(","(",inselect,regular;
replaceallfast "\\)",")",inselect,regular;
replaceallfast "...","......",inselect,regular;
replaceallfast "ぢ","ち★",inselect,regular;
replaceallfast "  "," ",inselect,regular;
replaceallfast "、、","、",inselect,regular;
replaceallfast "[・、]兄","え★",inselect,regular;
replaceallfast "完壁","完璧",inselect,regular;
replaceallfast "揚\\f[合所]\\f","場\\1",inselect,regular;
replaceallfast "\\f[あかだ]\\fつ\\f[たて]\\f","\\1っ\\3",inselect,regular;
replaceallfast "\\f[しち]\\fや\\f[なる]\\f","\\1ゃ\\3★",inselect,regular;
replaceallfast "\\f[入期空時月中仲人年民林]\\f聞","\\1間★",inselect,regular;
replaceallfast " \\f[「『(]\\f","\\1",inselect,regular;
replaceallfast "\\f[」』)]\\f ","\\1",inselect,regular;
replaceallfast "曲豆","豊",inselect,regular;
replaceallfast "[→「]\\f[人方]\\f ","一\\1",inselect,regular;
replaceallfast "1","ー★",inselect,regular;

 まず学習辞書であるが、これはよくある文字読み取りの間違いをパターン化して一括検索・置換するもので、リストのかたちで保存できるから、再利用が可能である。この辞書の中身を充実させていけばいいのである。まず「検索」メニューから「検索・置換」を選択すると「検索・置換」ダイアログが表示されるので、検索したい文字列と置換したい文字列をそれぞれ入力する。ダイアログの右下にある「リスト置換」をクリックすると「置換リスト」が表示され、「追加」ボタンをクリックするとリストに登録される。必要な追加があれば、この作業を繰り返し、最大100組までの登録が可能である。右下の「リスト変更」ボタンをクリックして「名前を付けて保存」を選び、適当なファイル名をつければ、デフォルトでは「マイドキュメント」フォルダの「medeadrive」内の「e.Typist User Data」フォルダに「*.lst」の形式で保存され、呼び出すことができるようになる。このファイルは実体はタブ区切りのテキストデータなので、簡単に作成することもできる。
 ちなみにわたしがかつて紀伊國屋NetLibrary用に『宮本常一著作集』をOCRで読み取りしたときに作った「miyamoto.lst」という学習辞書(一括処理ファイル)が見つかったので、ご参考までに提示しておこう。これは古い活字を読み取るときによく起こる読み違いを拾い出したもので、あまり一般性がないので、あくまでも一例にすぎないことをくれぐれもお断りしておく。

=一 一二
劇軽 剽軽
:: ......
食ぺ 食べ
手ぱな 手ばな
むつかし むづかし
たぺ たべ
・:・ ......
ぺき べき
人聞 人間
 「
、 「 、「
、 一 、一
。 一 。一
。。
=ハ 一六
曲豆
、 『 、『
。 ( 。(
。 『 。『
胴子 舸子
仲問 仲間
一一
成皿
一っ 一つ
』 ( 』(
入月 八月
民聞 民間
祈疇 祈祷
村入 村人
仲聞 仲間
民問 民間
'
 『
飢謹 飢饉
まア まァ
ゃア ゃァ
はア はァ
なア なァ
一べん 一ぺん
豆殴 豆酘
庖瘡 疱瘡
年聞 年間
)

 左側が検索文字列、右側が置換文字列である。ご覧いただけばすぐわかるように、句読点やカッコ類の問題や単純な読み違え(たとえば「人間」を「人聞」とするなど)、さらにひとつの文字を分解して読んでしまう例(「豊」を「曲豆」と読むなど)があり、なかなかおもしろいが、笑ってもいられない。こういう間違いを集めておいて一括処理すれば、かなり手間が省けるのである。何パターンもリストを作っておいて使い分けるのもひとつの方法だろう。

 最近の著者の原稿はほとんどデータによるものが多くなったことはこれまでも何度も書いてきたが、とはいえ、書いた時期が古かったり、データ保存ができていなかったり、その他いろいろな事情があって、印刷されたものがあってもデータがない場合もけっこうあるのも事実である。本や雑誌などからデータを復元する必要があることもめずらしくないのである。
 こうした場合、以前だったら原稿をわざわざ入力し直すことが普通だったが、最近は市販されているOCRソフト(Optical Character Recognition:光学文字認識)も性能が良くなってきて、かなりの精度でテキストを取り出すことができるようになってきた。そこで今回は、こうした原稿からテキストデータを作成する方法を紹介しておきたい。この方法を使うことによって効率よくデータを取り出すことができるので、きわめて実用的だからである。
 まず、わたしが使っているOCRソフトはメディアドライブ社のe.Typistという市販ソフトである。ほかにはエプソン社の「読んde!!ココ」とかパナソニックの「読取革命」とかがあるが、最新情報では「読んde!!ココ」は開発終了したようである。以前、いろいろ使い勝手を比較してみたことがあるが、すくなくとも出版編集用にはこのe.Typistがいちばんいいのではないかという結論に達して導入した経緯がある。したがって、ここで紹介するのはこのソフトを使ったものであることをあらかじめことわっておきたい。もっとも、これもいろいろ問題がないわけではないので、不具合を一括処理するような後処理が必要で、言ってみれば、この後処理のテクニックがほんとうに使い物になるかどうかの目安となるのではないかと思う。
 以下に簡単に操作方法を書いておく。
 まずは読み取りたいページをスキャンして「jpeg」形式または「TIFF(Tagged Image File Format)」形式でファイル保存する。通常は「jpeg」形式で十分である。つぎにe.Typistを起動して「ファイル」メニューから「画像ファイルを開く」を選択し、読み込まれた画像ファイルの必要な文字部分をマウスで範囲選択する。つぎに「文字認識」をクリックすると、元の画像が左側に、読み取られた文字データが右側に現われる。さらに「ファイル」メニューから「OCR作業ファイルの保存」を選ぶと適当なファイル名をつけて保存できるし、同じように「テキスト─名前を付けて保存」を選択し適当なファイル名を付けてテキストを保存することができる。通常はこれを加工すればいいのだが、その前にOCR作業ファイルで画面を見ながら修正をすることもできる。作業ファイルの右側(読み取り側)で間違った文字を選択すると、それの変換候補の文字群が出てくるので、そこをクリックすれば変換できる。候補になければ入力すればいいのである。
 OCRソフトは文字を画像データとして判読するので、OCRならではの誤読がたくさん出てしまうのは避けがたい。これをひとつひとつ処理していくのでは、はなはだ非効率なので、一括処理をする方法を鍛えなければならない。それをOCR作業ファイル上で「学習辞書」を作って処理する方法と、テキストデータ上でマクロなどを作って一括処理する方法と、おおきく言って2種類ある。つぎにそれを説明しよう。

 前項の1―(3)―(iv)丸付き数字を修正するでも述べたことと同じように、時計数字をむやみに使いたがるひとがいる。これも機種依存文字種の代表的なもので、Macintoshのエディタでは文字化けしてしまう。これらは1を示す「I」、5を示す「V」、10を示す「X」、50を示す「L」、100を示す「C」とそれらの半角文字を合成したものから成り立っている。日本語の縦組みを念頭にテキスト処理をするには、これらの基本数字は時計数字として割り当てられたコードを使わずに、全角のアルファベットに置き換えて使うほうがいい。これら以外の端数は横幅が長くなるので半角のアルファベットを使って組み合わせるが、そのままでは縦組みのなかで横倒しになってしまうので、これを縦にするというタグ付けが必要である。わたしはこれらの端数を【】ではさむことにしている。こうしておけば、印刷所との約束でこれを縦組み表示に組み替えてもらうことができる。そのさい【】が脱落させられるのはもちろんである。
 このテキスト処理を秀丸マクロで一括処理するようにしたのが、わたしの「時計数字の修正マクロ.mac」である。このマクロファイルは、前項同様、未來社ホームページの「アーカイヴ」の「秀丸マクロ集」ページ(http://www.miraisha.co.jp/mirai/archive/HIDEMARUmacro.html)で確認することができる(ダウンロードも可)ので参照をお奨めする。

 著者のなかにはいわゆる丸付き数字(①②③......)を使うひとがいる。これは機種依存文字とされてきたものであって、テキストファイルとしては互換性のないものであり、Macintoshのエディタでは文字化けしてしまう。それに通常この丸付き数字は1~20しか用意されていないからそれ以上必要な場合には使えない。ともかくこれらをどうしても表示したいひとのために、テキスト処理をしておかなければならない。ここでは①を○1、②を○2......(○+半角算用数字)と置き換えればよい。
 このテキスト処理を秀丸マクロで一括処理するようにしたのが、わたしの「丸付き数字の修正.mac」である。このマクロファイルは未來社ホームページの「アーカイヴ」の「秀丸マクロ集」ページ(http://www.miraisha.co.jp/mirai/archive/HIDEMARUmacro.html)で確認することができる(ダウンロードも可)ので参照をお奨めする。

 翻訳書や研究書などには外国語表記のあるものが多い。英語以外のものはコンピュータの世界ではローカル言語とされるので、それらの言語の特殊文字は通常は互換性がない。ワープロなどでは環境設定をすればなんとか表記できるものもあるが、そうしたデータをテキストファイル化するととたんに消えてしまう。この場合、すべて消えてしまうわけでもないことが多く、それに近い文字に置き換えられるのがふつうだ。フランス語のアクサン(アクセント記号)やドイツ語のウムラウトはふつうのアルファベットにアクセント記号が付されているのが外れてしまうだけである。
 ともあれ、頻度の高い特殊文字だけでもテキスト化して、印刷所で変換してもらうようにするしかない。これらの表記はワープロ上で検索して置換するのが手っ取り早い。
 わたしが一般的に使用している特殊文字のテキスト指定は以下のようなものである。これ以外のものは必要に応じて設定する。
(フランス語)
 アクサンテギュー(文字の上部に右上から左下にかけて斜めの線が入るもの)→e+'/a+'/o+'/y+'/E+'など(l'、s'などの子音との組合せのときは通常のアポストロフィとして使用)
 アクサングラーヴ(文字の上部に左上から右下にかけて斜めの線が入るもの)→a`/e`
 アクサンシルコンフレックス(文字の上部に「^」があるもの)→a^/i^/u^/e^/o^
 cセディーユ(Cまたはcの下部にヒゲが付く)→C&/c&
 リガチャー(合字)→o+e/a+e/O+E/A+E
 ギュメ(小さい引用符)→【<<】......【>>】で指定。
(ドイツ語)
 ウムラウト(文字の上部にトレマが付く)→a``/i``/u``/e``/o``/A``/O``など
 エスツェット(大文字のBを崩したもの)→B&
 ドイツ語特有の引用符(始まりが下付右よりの「"」、終りが上付き左よりの「"」)→【"】......【"】で指定。
(その他)
 ギリシャ語、ラテン語長音文字→e ̄/i ̄など
 上付き文字:<SUP>......</SUP>ではさむ。
 下付き文字:<SUB>......</SUB>ではさむ。
 半角ダブルクウォート「"」および半角シングルクウォート「'」→開き用に「"」と「'」に、閉じ用に「/"」と「/'」で指定。なお、ここでこれらはすべて半角なので、欧文と同じように開きの「"」および「'」の前には半角スペースを、閉じの「"」および「'」の後ろにも半角スペースを入れる必要がある。ただし前後に全角の句読点、カッコ類がある場合はこの限りでない。必要なアキはすでにこれらの文字に含まれているからである。

 世の中にはワープロソフトが入力ソフトの究極のツールだと思いこんでいるひとが多い。テキストエディタなどは存在も知らないか、知っていてもワープロより制限の多い、低級なツールだと思っているひとがほとんどではないか。たしかにWindowsに付属している「メモ帳」などをテキストエディタだと思っていれば、たいしたソフトではないと勘違いすることもありうるだろう。またテキストエディタはネット上でダウンロードして使えるシェアウェアまたはフリーウェアが一般的なので、市販ソフトに比べて安価(または無料)なので質もそれだけ落ちるとシロウトは考えがちである。
 ところがどっこい、いわゆる高機能エディタと呼ばれる多くのテキストエディタは、ワープロのような印刷機能や修飾機能に必要以上に力を入れているツールよりもテキスト入力とテキスト編集に特化したプロ用のツールなのであり、ワープロなどではろくに装備もされていない、テキスト処理に必要な「(タグ付き)正規表現」に完全に対応できるものが多いのである。これが使えないと、編集処理などには使い物にならない。ワープロがせいぜい中間発表レベルの印刷用ソフトと言われるゆえんなのである。
 ここではなぜかデファクト・スタンダードと思われているMicrosoft Wordのもつ大きな欠陥についてとくに注意しておこう。そのうちのひとつにルビの問題がある。そもそもルビ処理というのはワープロソフトそれぞれのローカルな機能であり、アプリケーションの外ではまったく通用しないルールにもとづいている。端的に言えば、Wordでできたデータをテキストファイル化しようとすると、ルビの文字はおろか親文字ごと消失してしまうというとんでもない不出来なソフトなのだ。無理もない、ルビなどという概念を知らないアメリカ人が作っているソフトだからであろうか。たとえば、Word上で「パソコンは英語という言語帝国主義【インペリアリズム】の支配する世界であって、日本語のような限定された【ローカルな】言語は二次的な言語と見なされる」という文章があるとしよう(【】内はルビ)。これをWordからテキストファイル化すると、「パソコンは英語という言語の支配する世界であって、日本語のような言語は二次的な言語と見なされる」となってしまって帝国主義【インペリアリズム】、限定された【ローカルな】というニュアンスが全部とんでしまう。もっとひどい例は「ランボーは『見者【ヴォワイヤン】』である」とか、同じくランボーの「絶対的に現代的【モデルヌ】でなければならない」といった有名なフレーズは「ランボーは『』である」「絶対的にでなければならない」というふうになんのことだかわからなくなってしまう。
 そこでどう対応するか。この場合には、テキスト保存するまえに、Word上でファイルの画面修正をおこなうか、Wordファイルを印刷しておいて、テキスト保存したデータにルビ文字を再入力するしかない。この作業は自動化するわけにはいかないので、ここは我慢してもらうしかないのである。
 ルビ指定は印刷所との約束でどうやってもいいが、印刷所の編集機で自動処理できるようにするためにはタグ付けが必要である。
 わたしの指定方式は、_^親文字【ルビ文字】^_というのが基本である。なお、親文字とルビ文字は原則的に1対2であるが、この比率ですべてのルビが振られているわけではない。親文字に対してルビ文字が長い場合(外国語にルビを振るような場合によくある。たとえば、英語:イングリッシュ、など)もあれば、逆に親文字に対してルビ文字が短い場合(たとえば、場合:ケース、など)、さらに言えば、日本語のふりがなが親文字と微妙にずれてしまう場合などもあり、ルビ問題はたんにWordの不備の問題だけでない、日本語の技術処理上の大きな問題である。
 くわしくはこの問題を論じた『出版のためのテキスト実践技法/総集篇』「II-6 ルビのふりかたを正確に指定する」を参照していただきたいが、要は、ルビ付き文字をいかに合理的かつきれいに見せるか、という問題なのである。日本語においては重要な課題なので、的確な対処が望まれる。

 つぎに編集者が確認すべきことは当面の本がどういう構成になっているかを大枠において確認することである。原稿がかならずしもきちんとした階層構造の同一性をもっているとは限らないからである。つまり、全体がどういう章立てでできているのか、部立てを必要とするのか、章のなかに見出し類(中見出し、小見出し、節、項など)があるのか。それらの関係が本全体にわたって同じレヴェルでできているのかを確認することである。
 というのは、往々にして個人の論文集のような場合、それぞれの論文の性格上、あるいは最初の発表媒体等によって、さらには論文の書かれた時期やそのときの考え方によって、かなり不統一になっているのが通常であり、著者がそのことに自覚的でない場合(これはかなり多い)、本来同じ水準にあるべき見出し類のレヴェルが異なってしまっていることが多いからである。すなわち、ある論文には小見出しになっているのに別の論文ではそれが節や項になっているとか、長い論文なのに小見出しひとつなくて読みづらい、といった具合である。
 書かれたときのスタイルを尊重してそのまま掲出するという方法もないではないが、そこまで初出を遵守する必然性のないものも多いのではないか。それならば、一冊の論文集として、きちんとした方針を立てて構成を修正していくほうがいいだろう。
 これは複数の著者による論集の場合にもありうることである。執筆時期が重なるにもかかわらず、個人差というものがあって、それぞれのスタイルを尊重しながら全体でなんらかの統一性を与えるという方針が必要だろう。参考文献をつけるとか、注をほどこすさいに一定の限定をしないと著しくバランスを損なうことが生じうる。
 いずれにせよ、これらは形式的な(外形的な)問題であるが、当然ながら、形式は内容に関連性があるので、その点は著者(たち)と事前にしっかり打合せをする必要がある。
 こうした原稿の階層構造は目次として目に見えるかたちで実現するが、目次(コンテンツ)とはまさにその本の設計図あるいは概略であり、まさしく本のコンテンツ(内容、内実)を要約したものなのである。

このアーカイブについて

このページには、過去に書かれたブログ記事のうちカテゴリを追加カテゴリに属しているものが含まれています。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。