« [弁理士試験]商標法案内(9) | トップページ | シフト補正ふたたび »

2007年4月23日 (月)

弁理屋ワークベンチ

ずーっと懸案にしている。エディタのプロジェクトがある。当初はもう、Rapid Development のつもりで、Real Basic などに手を出して作成していた。そこで、エディタとしての普通の機能としてなら完成していたのである。ただ特許明細書作成で使いたくなりそうな、段落番号付与や、符号表抽出のときには正規表現検索が使えた方がラクだ。一方で Real Basic で使える正規表現検索のライブラリなども見当たらず、それを開発するのも面倒だなぁ、と長いこと放り出していたのだ。
 正規表現検索、というのは、「あいう」があるところ、といって検索するのではなく、「ひらがなが2文字以上続いているところ」とか、そういう文字の種類で検索をするようなものだ。この目的のために「任意の平仮名に一致する文字」などが定義されていて、それを「正規表現(regular expression)」というのである。

▽ 普段使いのコンピュータが Mac なので、それで動くもの、といって探していたら、"Kojo" というのがある、と教えてくれた人がある。
 ※今回は、実務、といっても、Mac プログラムの話であります。

■ Kojo
 Kojo 自体は、スクリーンショットを見る限りなかなか有用そうだ。主な機能としては、符号表作成・補完、類似段落検索(英語だけなのかなぁ?)、図番一括変換、シンタックスカラーリング(英語だけなのかなぁ?)、アウトラインプロセッサなどが含まれている。完成度も高そうに思える。と、いうわけでダウンロードしてみたのだが、どういうわけか私の環境では思ったように動作しなかった。例えば符号表には、符号以外の部分が並んでしまう。

 このほか、色々な思いが重なって、ついに思い余るに至り、以前から手を出そうかどうしようか悩んできた、Xcode (MacOS X 標準の開発環境、OSに付属)に手を染めてしまった。

■ OgreKit の衝撃[Mac プログラムのはなし]
 実を言えば、X Code を用いて、Mac でスタンダードなAPI(Application Program Interface)群である cocoa を採用するのであれば、OgreKit が使える。この OgreKit は oniguruma(鬼車)という有名な正規表現ライブラリをベースとしたフレームワークである。自分のプログラムに、驚くほどカンタンに組み込むことができる(詳細は省くが基本的な機能を使うだけであれば、コードは1行どころか一文字も要らない)。
 なお、Apple は、一部のルーチンに、ICU(International Components for Unicode)を採用しているようなので、ほんらいならば ICU の regular expression ライブラリを利用するべきなのだろうが、すくなくとも現時点では、OgreKit の方が組み込み易いように思う。

 cocoa を使ってワープロを作るのはカンタンで、ウインドウにテキスト入力ビューを貼り付ければいい。この場合、このテキスト入力ビューとして、NSTextView というクラスを採用すると、文字入力、文字列保持、下線・太字その他の文字列装飾、コピー、ペースト、ドラッグドロップ、…など標準的なエディタインタフェースは完成してしまう。あとは保存や読出しを実装するだけになる。
 また、この NSTextView が抱えている NSTextStorage クラスには、書式つきのテキストデータがまるまる入っているのであった。と、すれば、NSTextStorage が保持してるテキストに対して正規表現ライブラリのルーチンを使った検索をかければ、符号表抜き出しができそうだ。

 ためしに OgreKit のサンプルである TextEdit サンプルを使ってみる。Document のクラスに符号表作成のためのインスタンス・メソッドを追加する。メニューから呼び出せるように、Edit.nib の first responder に、追加したメソッドと同名のアクションを追加し、符号表作成メニューから、このアクションへコネクションを張る。この nib に対する操作は、グラフィカルインタフェースで行うことになる。ほとんど、Rapid Application Development のノリ。

 インスタンス・メソッド内ではまず、正規表現検索クラスのインスタンスを作成する。

NSString *targetString =
[NSString stringWithUTF8String:"[^図^ ^【^】^、||^。||^¥¥n||^あ-ん||^a-z||^0-9^0-9]+[0-9]+"];
OGRegularExpression *regex =
[OGRegularExpression regularExpressionWithString:targetString];

 oniguruma の正規表現記述では、"[^図^ ^【^】^、||^。||^¥¥n||^あ-ん||^a-z||^0-9^0-9]+[0-9]+" は、『「図」でなく、「【」や「】」でも、句読点・改行でもなく、ひらがなでも半角英小文字・数字でもなく、全角数字でもないものが1つ以上続いていて、その後に全角数字が1字以上続くパターン』という意味である。これによって、

 制御部1 や、 記憶部M2などはまるごと検出されるが、
 第1の色補正部11 では、「色補正部11」だけが検出されることになる。
 また、「図23」等は検出されない。

 この条件が気に入らなければ調整するだけのことである。そして、OgreKit に含まれる、OGRegularExpression クラスを初期化しておく。
 次に、

    NSEnumerator  *matcher = [regex matchEnumeratorInString:[[self firstTextView] string]];

 とする。document クラスにおいて、インタンスのメソッドとして実装しているので、self  は、ドキュメントのインスタンスを指す。firstTextView で、その NSTextView を取り出し、string で文字列を抜き出す。その中で、指定したパターンに一致する文字列の配列を作成している。OGRegularExpression がかなり強力なクラスなので、これだけで、正規表現に一致する部分が取り出せる。さらに、

    NSCountedSet *anSet = [[NSCountedSet alloc] initWithCapacity:[[matcher allObjects] count]];
    NSString *matchstr = [NSString alloc];

    OGRegularExpressionMatch  *match;
    while ((match = [matcher nextObject]) != nil) {
        [anSet addObject:[match matchedString]];
    }

 として、作成した配列内の文字列を、順繰りにNSCountedSet のインスタンスに収めていく。このクラスはヒストグラムを作成するのに使えるクラスで、これで重複を排除した配列ができ上がる。最後に、

    NSArray *sorted_args = [[anSet allObjects] sortedArrayUsingSelector:@selector(compare:)];
    NSEnumerator *enm = [sorted_args objectEnumerator];

で、順番にソートすればいい。この前に、もう一度 Regex を使って、数字部分を、文字列の先頭に移動しておけば(制御部1 → 1制御部)、ここでのソートをうまく使って番号順に並べ替えることもできると思う(できました)。

 というわけで、ここから適当に書式を揃えて出力させると、符号表ができあがった。まだノイズが多いが、ある程度の役には立ちそうだ。

■ 段落番号付与[「弁理」屋ツールのはなし]
 以下、段落番号削除ツールまで実装したので、あとは段落番号を付与するツールと、図番号の調整ツールくらいが必要だ。むろん、符号表ツールについては後でもうちょっと手を加える必要があると思うが。
 段落番号のつけかたは、事務所によっても方針が違うので、一般向けにリリースする場合は注意が必要だ。一般的には、段落の直前に付ければいいだけのことだが、事務所(またはクライアント)によっては、2行未満の段落には番号をつけない、とか、「なお」書きの段落には番号をつけない、といった要望をしているところもある。従って、「ここには付けるな」マークを打ってもらい、そのマークがある段落を避ける処理や、付けようとしている段落の長さを見る処理などを実装しないといけない。ただ今回は頒布の予定がないから、自分で使うだけなので(Mac 版だしね)、こんな気遣いは要らない。自分で使いやすいようにやればいいだけだ。
 この段落番号付与については、現在実装中である。以前作成したワードマクロをベースにしているので、実装はカンタンかな、と思ったのだが、いざ始めてみると事情の相違があって、あまり単純ではなかった。

■その他の処理
 図番号の割り込みナビゲーション(所定見出しへのジャンプ)、請求項分析ツール(引用関係抽出)など、昔書いたエディタで実装していた(あるいはしかけてた)ものは盛り込むとして、あと便利なツールにはどんなものがあるかなぁと。リバージョンツールを入れてみようかなどと考えているが、あまり大規模になると疲れるしなぁ…。前回保存版との diff くらいは簡単だろうから、そのくらいは実装するか…。

□プログラミング本:わりと基本から書いてあるのですが、チュートリアル的で分かりやすいかと。プログラム言語の習得のためには、一度はその言語で書いてみろ、ってのは、bwk の言葉だったように思いますが、これは至言ですな。

|

« [弁理士試験]商標法案内(9) | トップページ | シフト補正ふたたび »

コメント

大ネコです。
すでにntakei先生ならご存知とは思いますが、
段落番号付与だけでしたら、Word用のmacroがvectorにフリーウエアとして登録されています。
新人研修(前期)の宿題を自宅でやる際にお世話になりました。
(職場の出願用端末には、自動付与機能が入っているため)

このフリーソフトの機能は いたって簡単で、段落記号【】と四桁の数字が入っている箇所を見つけてリナンバリングしてくれるというものです。
・禁則処理
・挿入箇所の自動抽出
との機能は、あいにく含まれておりません。
==大ネコ

投稿: 大ネコ | 2007年4月23日 (月) 06時31分

大ネコ様

 いつもありがとうございます。
 「ここに入れる」という指定が入っているパターンですね。私も、最初に入所した事務所では、【00】という形だけ打っておいて後から検索するパターンを使っておりました。
 これだと好きな場所に入れられるので、好みの体裁になるのですが、「うっかり漏れ」などが発生しないとも限りません(むろん、漏れても大概は平気なわけですが、多少体裁が悪いですし、補正が面倒になったりします)。
 それで挿入個所を決めてくれるものを作りました(私も verctor に登録すればいいのかなぁ)。

 挿入個所抽出は、基本的には「。+改行+全角スペース1個」の場所を見つけて、改行の直後につける戦略でいいはずなのですが、項目名(【背景技術】など)の処理がちょっとだけ困難です。【数1】に対しては、直前に段落番号がつくほうがいいと思うのですが、ひな形では、【背景技術】などの場合は後につけることになっています。「【】」の場合、と一括してできないので少々面倒です。

 もっとも、今後、三極方式統一という話もありますので、現状にあまり集中してもムダなのかも知れませんが。

投稿: ntakei | 2007年4月23日 (月) 07時55分

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 弁理屋ワークベンチ:

« [弁理士試験]商標法案内(9) | トップページ | シフト補正ふたたび »