プルーフリーディング用ドキュメント作成方法、プログラム、メディア及び情報処理装置
【課題】 ローカライズ版プルーフリーディング用ドキュメントの作成方法において、ソフトウェアローカリゼーション開発者の作業効率を向上させる。
【解決手段】 ＧＵＩ画面のスクリーンショットとＵＩ部品属性情報の自動取得及びこれらのデータを用いてプルーフリードドキュメントを自動的に作成する。
【解決手段】 ＧＵＩ画面のスクリーンショットとＵＩ部品属性情報の自動取得及びこれらのデータを用いてプルーフリードドキュメントを自動的に作成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置、ＧＵＩプログラムの画面制御方法及びプログラム、ＵＩ部品の属性情報の取得方法及びプログラム。特に、前記方法で取得したＵＩスクリーンショットとＵＩ部品の属性情報を用いて、プルーフリーディングドキュメト作成の効率化に関する好適な技術に関する。
【背景技術】
【０００２】
コンピュータシステムは数多くの言語で存在している。多数のソフトウェアアプリケーションおよびオペレーティングシステムは、第１の言語で作成され、次いで、他の言語に移植される。これを、アプリケーションおよびオペレーティングシステムのローカライゼーションと呼ぶことがある。通常のローカライゼーション手法として２つやり方が存在する。
【０００３】
1. ソースプログラムのリソースファイル中の第１言語の文字列を抽出し、ローカル言語に翻訳した後、第１言語の文字列と差し替えて、ソースプログラムを再ビルド（コンパイル、リンク）することによって、ローカライズ版実行モジュールを生成する手法である。
【０００４】
2. 第１言語の実行モジュールから第１言語の文字列を抽出し、ローカル言語に翻訳した後、直接実行モジュール中の第１言語文字列と差し替え、再ビルドしない手法である。
【０００５】
前記何れの手法においても、翻訳作業は言語専門の翻訳者が担当し、ローカライズ版実行モジュールの作成作業は、専門のソフトエンジニアが担当するような形の共同作業が多い。このようなプロセスで作成されたローカライズ版の翻訳品質は翻訳担当者のレベルと経験に大きく依存しており、場合によって、翻訳精度は翻訳者の製品に関する知識にも関わる。また、熟練の翻訳者でも、文字列を翻訳する際、特定の文字列はＵＩ上の用語なのか、メッセージ用語なのか、コンテキストヘルプ用語なのか、それとも非表示用語なのかを知らないケースが多いので、翻訳用語の一貫性を保てない問題が少なくない。一方、ソフトエンジニアがローカル言語の知識がないので、翻訳の品質をチェックすることができない。よって、高品質のローカライズ版ソフトウェアを作成するために、対象のローカル言語知識及び製品知識を両方持つ第三者によるプルーフリード（翻訳用語チェック）が必要となる。プルーフリードを実施する場合、プルーフリーダー（翻訳用語チェックを行う人）がソフトウェア開発環境を持っていないため、彼らのためにプルーフリード用ドキュメントを準備しなければいけない。通常プルーフリード用ドキュメントは以下のような構成となっている。
【０００６】
1. 第１言語とローカル言語の該当プログラムの画面スクリーンショット
2. 前記画面上すべてＵＩ部品に表示している用語の一覧
3. プルーフリーダーが読みやすい形で前記スクリーンショットとＵＩ用語一覧を所定のフォーマットでまとめられ、プルーフリード結果やコメントの記入欄が用意されている
プルーフリード用ドキュメントの一例として、図１を参照ください。
【０００７】
図１のようなドキュメントを作成するには、従来以下のような手法が主に使われていた。
【０００８】
1. 第一言語ＯＳ環境で、第一言語で作られたプログラムを起動し、ＧＵＩ画面の切り替え操作で所定の画面を表示させ、ユーティリティを利用し、画面のスクリーンショットをクリップボードから取得した後、プルーフリードドキュメント内所定の位置に貼り付ける。
【０００９】
2. 次に、第一言語ＯＳ環境でステップ１の画面上のＵＩ用語を一々ドキュメントに手入力するか、プログラムソースコードのリソースファイル等からコピーし、プルーフリードドキュメント内所定の位置に貼り付ける。
【００１０】
3. 次に、ステップ１と同様な方法を用いて第二言語ＯＳ環境で、画面のスクリーンショットを取得し、プルーフリードドキュメント内第一言語スクリーンショットの右側に貼り付ける。
【００１１】
4. 次に、ステップ２と同様な方法を用いて第二言語ＯＳ環境で、手入力するかプログラムソースコードのリソースファイル等からコピーしてプルーフリードドキュメント内第一言語用語の右側に貼り付ける。
【００１２】
このようなプルーフリーディングドキュメント作成方法には、以下のような問題がある。
【００１３】
1. ２つ以上のＯＳ環境においての手作業が多く、時間がかかる。
【００１４】
2. ＵＩ用語を手入力する場合、不慣れな開発者にとって、キーボード操作が難しいので、タイピングミスが発生しやすい。
【００１５】
3. 図１に示されているように、ＵＩ用語一覧表の第一言語用語と第二言語用語が一対一の関係を持っているが、第二言語の意味が分らない開発者にとっては位置ズレ等編集ミスが発生しやすい。
【００１６】
そこで、ドキュメント作成の効率を向上させるために、所定操作手順に従いプログラムを起動し、自動的に特定のＧＵＩ画面を表示させることが実現できれば、スクリーンショット取得するための画面操作は速くなるはず。ソフトウェア規模が大きく、大量のＧＵＩ画面を有する場合、特に有効と考えられる。
【００１７】
文献１〜文献３に記載の操作マクロ生成装置では、利用者がシステムに対して操作を順に入力し、この一連の操作を記録することで、操作マクロを作成できる。利用者が行った操作から操作マクロを生成することにより、利用者がよく行う操作の手順を、操作マクロで実行することが可能となり、操作の効率が向上してきた。
【００１８】
また、ＧＵＩを有するシステムの動作の正常さを検査する装置として、ソフトウェア製品が市販されている。市販ソフトウェア製品のＧＵＩ検査装置では、利用者の入力操作に対するシステムの動作を検査するために、利用者の入力操作を自動化するためのスクリプトを記述する。また、入力操作を記録してスクリプトを作成することもできる。さらに、記録したスクリプトを編集することもできる。このようなスクリプトを用いて利用者の入力操作を自動的に実行させ、システムの動作結果を記録することで、異常な動作を検出することが可能となっている。
【特許文献１】特開平6-348481号公報
【特許文献２】特開平6-274329号公報
【特許文献３】特開平5-173741号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
しかし、文献１〜文献３に記載されている自動化操作装置の何れも、特定ＵＩ画面のスクリーンショットを取得できなかった。また、ＧＵＩ検査ツールはＵＩ部品の動作を検証し、ＵＩの問題とバッグを発見することが主目的なので、このようなシステムで自動生成されたスクリプトはローカル言語に依存し、複数言語を対応できないのが一般的である。更に、ＵＩ部品レベルまで詳細な属性情報（ＩＤや文字列等）をスクリプトに記述しないと、後ほどチェック動作ができなくなるので、スクリプト文法は煩雑、スクリプトライン数が長く、手入力の作成編集は大変難しい。なお、プルーフリードドキュメントを作成する場合、ＵＩ部品を一々記述せず、特定ダイアログ画面を開く手順だけをスクリプトに記載すれば、プログラム実行時すべてのＵＩ部品属性情報を自動的に取得することはできなかった。
【００２０】
本発明の目的は、複雑なスクリプトを用いず、画面開く手順だけを記載する簡単なスクリプトを使用し、自動操作で指定画面を開き、画面スクリーンショットを取得し、また該当画面上すべてのＵＩ部品の属性情報を取得できる。最終的に、前記取得した情報で、プルーフリード用ドキュメントを所定のフォーマットで自動的に生成できることである。
【課題を解決するための手段】
【００２１】
本発明の目的はローカライズしたアプリケーションの翻訳品質をチェックするために、第一言語の画面スクリーンショット及びリソース情報と、一対となるローカル言語の画面スクリーンショット及びリソース情報を自動的に取得し、マージしてプルーフリード（用語チェック）用資料を自動的に生成できることである。
【００２２】
なお、本発明のポイントは下記の通りである。
【００２３】
所定のダイアログＵＩを開く手順を記述するＵＩ操作手順記述手段を有する。
【００２４】
前記ＵＩ操作手順記述手段はＯＳの言語に依存しないことが特徴である。つまり、一旦作成したＵＩ手順記述をローカライズする必要がなく、どの言語のＯＳ環境でも実行できることが特徴である。
【００２５】
前記ＵＩ操作手順記述を複数ＯＳ間で共有できるＵＩ操作手順共有手段を有する。
【００２６】
前記ＵＩ操作手順記述に従い、所定のＵＩ画面を開き、画面のスクリーンショットを取得し、イメージファイルに保存する画面スクリーンショット取得手段を有する。
【００２７】
前記ＵＩ操作手順記述に従い表示させたＵＩ画面上に配置されているすべてのＵＩ部品（通常コントロールと呼ばれている）の表示可能な文字列及びホットキー等リソース情報を取得できるリソース情報取得手段を有する。
【００２８】
前記複数ＯＳ環境で取得できた画面スクリーンショット及びリソース情報を一か所に集め、ドキュメント上に配置し、所定フォーマットのドキュメントを自動的に生成できるドキュメント生成手段を有する。
【発明の効果】
【００２９】
ＧＵＩ画面のスクリーンショットとＵＩ部品属性情報の自動取得及びこれらのデータを用いてプルーフリードドキュメントを自動的に作成することで、ソフトウェアローカリゼーション開発者の作業効率を著しく向上させることができる。
【発明を実施するための最良の形態】
【００３０】
次に、本発明の詳細を実施例の記述に従って説明する。
【実施例１】
【００３１】
サーバＰＣの役割を果たすＳｅｒｖｅｒ−１及びクライアントＰＣの役割を果たすＣｌｉｅｎｔ−Ａ、Ｃｌｉｅｎｔ−Ｂ、Ｃｌｉｅｎｔ−ＣがローカルエリアネットワークＬＡＮ−１により接続され、相互的に通信可能な状態にある。なお、ＧＵＩを有するシステムソフトウェアはプリンタドライバとする。プリンタドライバ開発のプロセスとして、先ず英語版がビルドされ、市場リリース可能な一定レベルの品質に達した後、英語版をベースに日本語や韓国語等ローカル言語版をビルドしていく。また、本実施例のプリンタドライバのアーキテクチャ（内部モジュール構成）は機能モジュールとリソースモジュールを分離し、ＵＩ部品関連用語やメッセージ等ローカライズ必要なリソース情報（文字列、アイコン、ビットマップ、ホットキー、マウスカーソル等）をリソース専用ＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋ Ｌｉｂｒａｒｙ）に配置する。なお、ローカライズ手法は発明背景のところで紹介したバイナリローカライズを採用し、完成後のすべてのローカル言語版とベースの英語版と同様なバイナリコードを使用し、ＵＩ関連リソースだけ違うような構造となることで、すべて言語のプリンタドライバは同様に振舞い、機能差がないメリットを得られる。更に、このような手法で作成されたローカル言語版ＵＩ部品の識別ＩＤはベースの英語版と変わらないメリットも得られる。本発明により開示された技術を使用することで、ドライバ開発者はローカル言語がわからなくても、図１で示すようプルーフリードドキュメントを自動的に作成することができる。自動作成されたプルーフリードドキュメントを 用語チェック部門担当者に送付して、プリンタドライバがインストールされていない環境でも、ドライバＵＩ用語のチェックを行うことが可能になる。
【００３２】
さて、図２で示した各ＰＣのソフトウェア環境を簡単に紹介する。
【００３３】
● Ｓｅｒｖｅｒ−１
日本語版Ｗｉｎｄｏｗｓ（登録商標）を搭載し、画面スクリーンショットやＵＩ部品の属性情報（以降、便宜上リソース情報と呼ぶ）を取得する際に必要なダイアログ開く手順（以降、便宜上スクリプトと呼ぶ）をＳｅｒｖｅｒ−１のハードディスク上に格納し、各クライアントＰＣからアクセスできるように共有している。また、各クライアントＰＣ上で取得したリソース情報をＬＡＮ−１経由で本ＰＣのリソースＤＢに保存される。また、リソースＤＢに格納された情報に基づき、所定のフォーマットに従って、プルーフリードドキュメントを自動生成する手段を有するプログラムも本ＰＣ上の記憶装置に格納される。また、Ｓｅｒｖｅｒ−１に搭載するＯＳ言語は日本語版に限らず、プルーフリードドキュメント作成者にとって使いやすい言語であれば、ローカル言語でも良い。また、プルーフリードドキュメント自動生成プログラムの使用言語に制限がない。
【００３４】
● Ｃｌｉｅｎｔ−Ａ
英語版Ｗｉｎｄｏｗｓ（登録商標）及び英語版プリンタドライバを搭載する。更に、プリンタドライバＵＩのリソース情報を取得する手段を有するプログラムも本ＰＣ上の記憶装置に格納されている。また、リソース情報取得プログラムの表示用言語として、本実施例においては英語版を使用するが、他のローカル言語版でも良い。
【００３５】
● Ｃｌｉｅｎｔ−Ｂ
日本語版Ｗｉｎｄｏｗｓ（登録商標）及び日本語版プリンタドライバを搭載する。また、日本語版プリンタドライバは英語版プリンタドライバをベースにバイナリローカライズ手法でローカライズされたバージョンとする。更に、プリンタドライバＵＩのリソース情報を取得する手段を有するプログラムも本ＰＣ上の記憶装置に格納されている。また、リソース情報取得プログラムの表示用言語として、本実施例においては日本語版を使用するが、他のローカル言語版でも良い。
【００３６】
● Ｃｌｉｅｎｔ−Ｃ
韓国語版Ｗｉｎｄｏｗｓ（登録商標）及び韓国語版プリンタドライバを搭載する。また、韓国語版プリンタドライバは英語版プリンタドライバをベースにバイナリローカライズ手法でローカライズされたバージョンとする。更に、プリンタドライバＵＩのリソース情報を取得する手段を有するプログラムも本ＰＣ上の記憶装置に格納されている。また、リソース情報取得プログラムの表示用言語として、本実施例においては韓国語版を使用するが、他のローカル言語版でも良い。
【００３７】
更に、Ｃｌｉｅｎｔ−Ｂにインストール済みの日本語バージョンプリンタドライバとＣｌｉｅｎｔ−Ｃにインストール済みの韓国語バージョンプリンタドライバはＣｌｉｅｎｔ−Ａにインストールされている英語バージョンプリンタドライバをベースにして、バイナリローカライズ手法でローカライズされたものである。各バージョンのＵＩ用表示言語は別物だが、ＵＩコントロール（部品）のＩＤは同じである。また、バイナリローカライズはドライバ実行モジュールのバイナリコードを変更しないため、機能面において各バージョンのドライバは同様な振舞いをする。
【００３８】
つづいて、プリンタドライバＵＩのプルーフリードドキュメント自動生成は図３のメインフロー図で示されているように、３０１〜３０４の四つのステップから構成されている。次に、各ステップの機能及び実現方法について詳しく説明する。
【００３９】
ステップ３０１にてＵＩ部品に関するリソース情報（ビットマップやＵＩ用語等）を取得するために使われるスクリプト（画面開く手順）を作成しておく。更に作成されたスクリプトファイルをＳｅｒｖｅｒ−１の共有フォルダに保存し、各クライアントＰＣからアクセスできるように設定しておく。本実施例に使われるスクリプトファイルの一例を図４に示している。
【００４０】
図４内一番左側の括弧内の数値は説明便宜上のライン番号を表し、スクリプトの内容ではない。スクリプト内容はライン番号の右側である。また、「；」より右側の内容はコメント（説明文）であり、スクリプトコマンドに影響しない。
【００４１】
まず、01行目の「Conon MFP C6870 印刷言語LX 」はプリンタのフレンドリーネームを表す。Ｗｉｎｄｏｗｓ（登録商標）の「スタート」メニュー→「コントロールパネル」→「プリンタとＦＡＸ」の手順で操作すると、図５画面のように現在システムにインストールされているすべてのプリンタが表示される。この画面に表示されているプリンタの名称はフレンドリーネームである。本実施例においては、プルーフリード用資料を「Conon MFP C6870 印刷言語LX 」ドライバＵＩベースに作成されるので、Ｃｌｉｅｎｔ−Ａに英語バージョン「Conon MFP C6870 印刷言語LX 」プリンタドライバ、Ｃｌｉｅｎｔ−Ｂに日本語バージョン「Conon MFP C6870 印刷言語LX 」プリンタドライバを事前にインストールされていることを前提とする。また、Ｗｉｎｄｏｗｓ（登録商標）環境でプリンタドライバ印刷設定画面を開いた際、ダイアログタイトルの一部としてプリンタフレンドリーネームが使われる。印刷設定を表すローカル言語文字列はＷｉｎｄｏｗｓ（登録商標）システムにより提供される。例えば、英語版ＯＳの場合「Conon MFP C6870 印刷言語LX Printing Preferences」、日本語版ＯＳの場合「Conon MFP C6870 印刷言語LX 印刷設定」と表示される。
【００４２】
次、スクリプト02〜05行目はプリントドライバ印刷設定画面の第一階層（タブシートコントロール）のタブページ番号を表す。英語や日本語のようなLeft-To-Right言語の場合、タブシートの配置は左から右への順番で、図６の示す通り「Sheet 1＝ページ設定」、「Sheet 2＝仕上げ」、「Sheet 3＝給紙」、「Sheet 4＝印刷品質」である。逆に、アラビア語のようなRight-To-Left言語の場合、タブシートの配置順番は右から左へとなる。
【００４３】
次、スクリプト06行目の「Button 0xFFEE000A 1」は第一階層「Sheet 1」タブページ（ページ設定）の「ユーザ定義用紙」プッシュボタンがクリックされた場合、表示される第２階層のダイアログを意味する。「0xFFEE000A」は「ユーザ定義用紙」プッシュボタンのコントロールIDを表す。Ｗｉｎｄｏｗｓ（登録商標）システムで、それぞれのＵＩ部品は他の部品と区別できる唯一のＩＤが割り当てられている。更にドライバがローカライズされた後、ＵＩ部品の文字列が換わるが、ＩＤが変わらない特徴がある。この特徴を利用して、文字列の代わりにコントロールＩＤで作成されたスクリプトはローカライズの必要性がなくなり、そのまま、すべてのローカル言語ＯＳ環境で利用できるメリットを得られる。07行目「CloseDialog」は第２階層のユーザ定義用紙ダイアログをクローズすることを意味する。同様に、08行目「Button 0xFFEE000B 2」は、第一階層「Sheet 2」タブページ（仕上げ）の「仕上げ詳細」プッシュボタンがクリックされた場合、表示される第２階層のダイアログを意味する。09行目「CloseDialog」は、「仕上げ詳細」ダイアログを閉じることを意味する。同様に、10行目「Button 0xFFEE000C 4」は、第一階層「Sheet 4」タブページ（印刷品質）の「色設定」プッシュボタンがクリックされた場合、表示される第２階層のダイアログを意味する。11行目「CloseDialog」は、「仕上げ詳細」ダイアログを閉じることを意味する。また、12行目「TheEnd」でスクリプトの終了を識別する。
【００４４】
図４のスクリプト実施例は第２階層画面までしか操作しないが、決して制限を意味することがない。本特許で開示した方法で、複数階層の画面を開いたり、閉じたりすることが実現できる。例えば、下記スクリプトのように「Button XXX #」と「CloseDialog」のエンベッドにより、複数階層の対応が可能となる（；より右の内容は説明文）。
【００４５】
Sheet 1;（第１階層のタブページ１を開く）
Button 0xFFEE000A 1;（第１階層のタブページ１上のButton 0xFFEE000Aをクリックし、第２階層ダイアログを開く）
Button 0xFFEE002B 2;（第２階層のタブページ２上のButton 0xFFEE002Bをクリックし、第３階層ダイアログを開く）
Button 0xFFEE003C 1;（第３階層のタブページ１上のButton 0xFFEE003Cをクリックし、第４階層ダイアログを開く）
CloseDialog；（第４階層のダイアログを閉じる）
CloseDialog；（第３階層のダイアログを閉じる）
CloseDialog；（第２階層のダイアログを閉じる）
TheEnd；（第１階層のダイアログを閉じ、スクリプトを終了させる）
前記説明したように、本実施例のスクリプトファイルはローカル言語に依存しないので、ローカライズせずにクライアントＡ、Ｂ、Ｃの環境で使える。ただ、スクリプトファイルを各クライアントＰＣに直接配布して使う場合、以下の問題点が考えられる。
【００４６】
1. スクリプトを変更する場合、すべてのクライアントＰＣ上のスクリプトを修正しなければならない。手間がかかる。
【００４７】
2. あるクライアントＰＣ上のスクリプトが不注意で変更されたら、他のクライアントＰＣ上のスクリプトとマッチしなくなるので、プルーフリード用資料を作成する必要なリソース情報の整合性が取れなくなる。
【００４８】
そこで、本実施例のステップ３０１（図３）で作成済みのスクリプトファイルをＳｅｒｖｅｒ−１の記憶装置に格納し、他のクライアントＰＣからアクセスできるようにファイル共有を設定しておく。
【００４９】
つづいて、ステップ３０２で共有スクリプトファイルに従い、第一言語（英語）とローカル言語（日本語等）のＵＩ部品のリソース情報の取得方法について詳しく説明する。
【００５０】
図７はＵＩ部品のリソース情報を取得できるユーティリティ（ＧｅｔＡｌｌ）のメイン画面である。ＵＩ７０１は本ユーティリティの使用時のヘルプ情報を表示する。ＵＩ７０２コントロールでプリンタドライバＵＩ言語を選択する。通常プリンタドライバＵＩ言語はＷｉｎｄｏｗｓ（登録商標）言語と一致するので、手動設定の代わりに、Ｗｉｎｄｏｗｓ（登録商標） ＡＰＩ関数を使用してＯＳ言語を自動探索し、結果をＵＩ７０２に自動反映しても良い。ＵＩ７０３は取得したＵＩ部品リソース情報を格納する場所のサブフォルダを指定する。本ユーティリティのデフォルト設定で、格納先は「C:\AutoUI」であるが、ＵＩ７０３が「driver」に指定された場合、格納先は「C:\AutoUI\driver」となる。また、本ユーティリティは自動モード（Auto）と手動モード（Manual）２つのモードを提供する。ＵＩ７０５で手動モードを選択した場合、表示中１画面のりソース情報をしかとれない。本実施例は画面操作手順のスクリプトを使用して、複数画面の情報を一括で取得するために、ＵＩ７０４の自動モード状態でＵＩ７０６の取得（Capture）ボタンを実行する。次に、「Capture」ボタンが押された時、図４のスクリプトコマンドをどのように実行するかについて図８を使ってその処理の流れを説明する。
【００５１】
図８のステップ８０１で一行のスクリプトを読み込み、スクリプトコマンドの中身を分析する。ステップ８０６で「TheEnd」コマンドであるかどうかを判断する。Yesの場合、スクリプト処理を終了し、Noの場合、処理を継続する。次、ステップ８０７で「Conon MFP 6870 印刷言語LX 」のようなプリンタドライバフレンドリーネームかどうかを判断する。フレンドリーネームの命名規則はプリンタメーカーに委ねられていて、本実施例では「機種名＋PDL名称」のような構成となっているが、必要に応じて別の命名規則やドライバ名称以外の他のアプリケーション名も構わない。ドライバフレンドリーネームと判断できた場合、ステップ８０２で該当プリンタドライバ印刷設定画面を特定する処理を行う。Noの場合、処理をステップ８０８に移る。
【００５２】
ステップ８０２処理の目的は以降のスクリプトコマンドを実行するための前準備である。プリンタドライバ印刷設定画面が表示されなければ、画面のスクリーンショットやUI部品情報を取得できない。Ｗｉｎｄｏｗｓ（登録商標）環境でプリンタドライバ印刷設定画面を表示する方法は２つある。１つ目は手動操作であり、図５の「プリンタとFAX」ダイアログを表示させ、次に目的のプリンタアイコンを選択した上で、マウス右クリックでショートカット（ポップアップ）メニューを表示し、メニューから「印刷設定...」を選択する方法である。２つ目はＷｉｎｄｏｗｓ（登録商標）のシェル関数を呼び出すプログラムで自動表示させる方法である。何れの方法でもかまわないが、プリンタドライバの印刷設定画面が表示されると、ダイアログが初期化され、ウィンドウのインスタンスがシステム上に存在することになる。この時点でFindWindows() API関数を利用し、「ドライバフレンドリーネーム＋印刷設定」をタイトルとするウィンドウを特定し、そのウィンドウハンドル情報を取得できる。前記ウィンドウタイトルはＯＳ言語に依存であり、英語版の場合「ドライバフレンドリーネーム＋Printing Settings」となるが、ターゲットＷｉｎｄｏｗｓ（登録商標）システムの命名方法に従えば、確実にプリンタドライバの印刷設定画面のウィンドウハンドルを取得できる。ステップ８０２の処理が完了したら、ステップ８０１へ移る。
【００５３】
ステップ８０８の判断部で「Sheet」コマンドと判断した場合、第一階層上の所定のタブシートを表示させ、ステップ８０３で該当ダイアログのリソース情報を取得する処理を行う。「Sheet」コマンドは「Sheet #」のようなフォーマットで書かれる。「#」はタブシートのページ番号を表す。ステップ８０３処理のフローを図９で示しており、後で詳しく説明する。ステップ８０８の判断結果はNoの場合、処理がステップ８０９へ移る。
【００５４】
ステップ８０９の判断部で「Button」コマンドと判断した場合、ステップ８０４の処理で現階層のダイアログ上の指定UI部品（通常コマンドボタン）をクリックして、次の階層のダイアログを表示させる。更に、ステップ８０４の処理が終わると、ステップ８０３で新しく開かれたダイアログのリソース情報を取得する処理を行う。「Button」コマンドは「Button Control-ID #」のようなフォーマットで書かれる。「#」はタブシートのページ番号を表し、「Control-ID」で指定されたUIコントロールは第＃番目タブシートページ上に存在することを意味する。「Control-ID」はＷｉｎｄｏｗｓ（登録商標）システムに振り当てられたＵＩ部品を識別するための唯一のIDであり（Ｍｉｃｒｏｓｏｆｔ社製のSPY++ユーティリティを使って、より簡単に調べだすことができる）、Ｗｉｎｄｏｗｓ（登録商標）のAPI関数（SendMessage()等）を使用して、IDで指定されたＵＩコントロールにクリックイベントを表すメッセージを送ると、ＵＩコントロールのクリック操作をシミュレートし、次の階層のダイアログを表示させ、更にコントロールの文字列情報を使用しFindWindow() API関数で、新しいダイアログのウィンドウハンドルを取得することができる。ステップ８０９の判断結果はNoの場合、処理がステップ８１０へ移る。
【００５５】
ステップ８１０の判断部で「CloseDialog」コマンドと判断した場合、ステップ８０５の処理において「Button」で開かれた現在のダイアログを閉じ、上の階層ダイアログを現在の画面として表示させる。更に、ステップ８０５の処理が終わると、処理がステップ８０１に移り、次のスクリプトコマンドの読み込み処理を継続する。
【００５６】
図９はダイアログのリソース情報取得時の処理フローを示している。ステップ９０１で前記ステップ８０２または８０４で取得したウィンドウハンドルを利用して、Ｗｉｎｄｏｗｓ（登録商標）のBitBlt()関数で該当ダイアログのスクリーンショットのビットマップデータをバッファにコピーすることができる。バッファに格納されたビットマップデータは圧縮されておらず、そのままファイルに保存すれば、より多くの容量が必要となる。例えば、1024(pixel) ＊768(pixel) サイズの画面をフルカラー（32Bit/pixel）モードで保存する場合、1024＊768＊(32/8)＝3145728バイトになる。ファイルサイズが大きくなればなるほど、ネットワークでの転送時間がかかり、最終的に作成されるプルーフリードドキュメントのサイズも膨大になる問題がある。この問題を解決するために、ステップ９０２の処理はバッファに格納したスクリーンショットのビットマップデータを圧縮フォーマット（PNGやJPEG等）に変換して、ファイルに保存することを実現する。図４のスクリプト (02)行目「Sheet 1」を実行する際、ステップ９０１処理で取得した画面スクリーンショットを図１０の示す通りで、上は英語版、下は日本語版である。更に圧縮前・後の画像ファイルサイズの対比情報を以下に記載する。
【００５７】
次に、ステップ９０３の処理で、所定ダイアログ上のすべてのＵＩ部品を調べだす。Ｗｉｎｄｏｗｓ（登録商標）システムにおいて、ＵＩ部品も一つ一つ小さなウィンドウであり、更に厳密な所属関係があり、あるダイアログ上のＵＩ部品の親ウィンドウは該当ダイアログとなっている。Ｗｉｎｄｏｗｓ（登録商標）に提供されるＡＰＩ関数を利用して所定ダイアログ上のすべてのＵＩ部品を調べだすことができる。
【００５８】
次に、ステップ９０４の処理で、ＡＰＩ関数を利用してステップ９０３の調べた結果に従い、順次各ＵＩ部品のＵＩ表示用文字列とホットキー情報を取得し、所定のテキストファイルに保存していく。ＵＩ部品の種類によって、取得する文字列方法が違う。図１０のダイアログ画面を例に言うと、「お気に入り」のようなラベルや「縦」「横」のようなチェックボックスや「スタンプ編集」のようなプッシュボタンの場合、ターゲットＵＩ部品に文字列情報取得メッセージを送り、一回だけで文字列情報及びホットキー情報を取得できるが、「原稿サイズ」コンボボックスやリストボックスの場合、ターゲットＵＩ部品に複数回メッセージを送る必要がある。１回目のメッセージ送信は該当ＵＩ部品内のアイテム数を取得し、２回目以降のメッセージ送信により各アイテムの文字列取得を取得する。なお、本実施例では、１つダイアログ上のすべてのＵＩ部品の文字とホットキー情報を１つのテキストファイルに格納するように実装している。図１１は「Sheet 1」スクリプト実行後、取得した図１０ダイアログの文字列情報を示している。左側は英語版ＯＳ環境での実行結果で、右側は日本語版ＯＳ環境での実行結果である。
【００５９】
次に、ステップ９０５ですべてのＵＩ部品を処理完了と判断した場合、リソース情報取得処理が終了する。図４のスクリプトファイルを英語版Ｃｌｉｅｎｔ−Ａ環境で実行した後、ＰＣの「C:\AutoUI\driver」フォルダの下に、以下のようなリソースファイルが作成される。
【００６０】
【表１】
図４のスクリプトファイルを日本語版Ｃｌｉｅｎｔ−Ｂ環境で実行した後、ＰＣの「C:\AutoUI\driver」フォルダの下に前記と同様な結果を得られる。
【００６１】
次に、図３のステップ３０３の処理において、前記取得したリソースファイルをＳｅｒｖｅｒ−１の共有フォルダ「\\Server-1\AutoUI\」へ格納する。前記リソースファイルがオーバーライトされないように、英語版を「\\Server-1\AutoUI\English\driver」、日本語版を「\\Server-1\AutoUI\Japanese\driver」の下に格納する。本実施例はリソース情報を単に画像ファイルとテキストファイルとしてＳｅｒｖｅｒ−１の共有フォルダに格納しているが、検索・抽出しやすい形式のリレーションナルデータベースに格納しても可能で、オラクルデータベースやＳＱＬサーバやＤＢ２等典型的な市販品を使用することできる。
【００６２】
次に、図３のステップ３０４のプルーフリード用ドキュメント作成処理はＳｅｒｖｅｒ−１の環境で行い、処理の詳細は図１２のフローチャートを使って説明する。ステップ１２０１はドキュメントを新規作成するための初期化処理を行う。本実施例では、マイクロソフト社のＯｆｆｉｃｅ製品のマクロ機能を利用しＥｘｃｅｌフォーマットのプルーフリード用ドキュメントを作成することで、初期化処理においてはＭｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ（登録商標）とマクロプログラムを起動し、図１３のような画面を表示する。「\\Server-1\AutoUI\」はＳｅｒｖｅｒ−１の共有フォルダ名であり、ローカルフォルダ名は任意なので、ここで「C:\AutoUI\」とする。１３０１「Resource Folder」にてリソース情報の格納場所を指定できる。また、１３０２「Language」にてローカル言語を日本語に指定すると、英語と日本語用語対照一覧のプルーフリード資料を作成する。なお、１３０３の「Destination File」にて自動作成されるドキュメント名を指定できる。次に、１３０４「Checklist」コマンドボタンをクリックすると、処理は図１２のステップ１２０２に移り、１つ目のページ設定画面（図１０）関連のリソースファイルを特定し、以下の４つのファイルを開いて、データの読み込み準備をしておく。
【００６３】
・C:\AutoUI\English\driver\001.png
・C:\AutoUI\English\driver\001.txt
・C:\AutoUI\Japanese\driver\001.png
・C:\AutoUI\ Japanese \driver\001.txt
ステップ１２０３で画像ファイル「C:\AutoUI\English\driver\001.png」から英語版「ページ設定」ダイアログのスクリーンショットを読み込み、新規のＥｘｃｅｌシートの左上の適切な位置に配置する。同様にステップ１２０４で、画像ファイル「C:\AutoUI\Japanese\driver\001.png」から日本語版「ページ設定」ダイアログのスクリーンショットを読み込み、前記Ｅｘｃｅｌシートの右上の適切な位置に配置する。次、ステップ１２０５でテキストファイル「C:\AutoUI\English\driver\001.txt」から英語版「ページ設定」ダイアログの文字列＆ホットキーデータを読み込み、前記英語版「ページ設定」ダイアログのスクリーンショット下のセルに配置する。更に必要に応じて、コラムに名を付けてセルフォーマットを読みやすい形に整える。同様にステップ１２０６で、テキストファイル「C:\AutoUI\ Japanese \driver\001.txt」から日本語版「ページ設定」ダイアログの文字列＆ホットキーデータを読み込み、前記日本語版「ページ設定」ダイアログのスクリーンショット下のセルに配置する。更に必要に応じて、コラムに名を付けてセルフォーマットを読みやすい形に整える。次、ステップ１２０７判断部ですべてのＵＩ画面処理が完了したかどうかを判断し、「仕上げ」ダイアログ、「給紙」ダイアログ、「印刷品質」ダイアログ、「ユーザ定義用紙」ダイアログ、「仕上げ詳細」ダイアログ、「色設定」ダイアログに対して、前記ステップ１２０２〜１２０７の処理を繰り返す。すべてのダイアログ画面処理が完了したら、前記Ｅｘｃｅｌシートをファイルとして所定のフォルダに保存する。結果、図１のようなプルーフリード用ドキュメントを自動的に作成できる。
【００６４】
なお、前記説明はリソース情報が複数画像ファイル及びテキストファイルに格納される場合の処理説明であり、リソース情報がリレーションナルデータベースに格納される場合、データベースに接続しSQLクエリーを使用して、データベースからリソース情報データを抽出して、新規Ｅｘｃｅｌシートに配置することで同様にプルーフリード用ドキュメントを自動的に作成できる。
【００６５】
また、本実施例は２言語（英語＋日本語）プルーフリード用ドキュメントの自動作成方法を説明したが、本特許で開示した方法で他の言語を簡単に追加することが可能で、２言語以上のドキュメントを作成することも可能である。
【００６６】
また、本実施例において、Ｓｅｒｖｅｒ−１、Ｃｌｉｅｎｔ−Ａ、Ｃｌｉｅｎｔ−Ｂ、Ｃｌｉｅｎｔ−Ｃは別々のＰＣで構成されているが、必要に応じて任意のクライアントＰＣにＳｅｒｖｅｒ−１の機能を持たせることも可能である。
【００６７】
また、本実施例においてはＧＵＩを持つプリンタドライバのローカライズ版プルーフリード用ドキュメントの自動作成方法を例として説明してきたが、プリンタドライバ以外の他のＧＵＩを持つアプリケーションに対しても適応する。
【実施例２】
【００６８】
以下本特許の第二の好適な実施例を説明する。
【００６９】
第二実施例は図１４の示す通り、一台のＰＣに複数のＯＳを同時に稼働させるような構成となっている。このような環境を構築するには、まず１４０１英語版Windows XP（登録商標）をホストＯＳとしてＰＣにインストールする。次に、１４０２マイクロソフト社製Ｖｉｒｔｕａｌ−ＰＣを１４０１ホストＯＳにインストールする。更に、Ｖｉｒｔｕａｌ−ＰＣに日本語版Windows XP（登録商標）、韓国語版Windows XP（登録商標）、中国語簡体字版Windows XP（登録商標）、フランス語版Windows XP（登録商標）、ドイツ語版Windows XP（登録商標）等その他のローカル言語版Windows XP（登録商標）をインストールすることで、複数Windows XP（登録商標）を同時に一台のＰＣに立ち上げることが可能である。Ｖｉｒｔｕａｌ−ＰＣ動作時の画面の一例として図１５を参照ください。
【００７０】
図１４の環境において、１４０３スクリプトが１４０１英語版Windows XP（登録商標）の記憶装置に格納され、他のＯＳからアクセスできるように共有されている。リソース情報を保存するための１４０４リソースデータＤＢも１４０１英語版Windows XP（登録商標）に格納され、１４０３と同様、複数ＯＳ間で共有されている。ドキュメント作成プログラムが１４０１環境で実行できる状態にある。尚且つ、それぞれのWindows XP（登録商標）にＯＳと同じ言語のプリンタドライバがインストールされ、リソース取得プログラムもインストールされている状態である。
【００７１】
実施例１と同様な方法で、１４０１英語版Windows XP（登録商標）で動作しているリソース取得プログラムは１４０３スクリプトを読み込み、スクリプトコマンドに従い、英語版プリンタドライバＵＩを開き、リソース情報を取得して結果を１４０４リソースデータＤＢに保存する。
【００７２】
また、実施例１と同様な方法で、ローカル言語版Windows XP（登録商標）上で動作しているリソース取得プログラムは１４０３スクリプトを取得し、スクリプト手順に従い、ローカル言語版プリンタドライバダイアログのリソース情報を取得して結果を１４０４リソースデータＤＢに保存する。
【００７３】
実施例１と同様な方法で、１４０１英語版Windows XP（登録商標）で動作しているドキュメント作成プログラムは１４０４リソースデータＤＢから、画面スクリーンショットと文字列情報を抽出し、所定のフォーマットで１４０５プルーフリード用ドキュメントを自動的に作成できる。
【図面の簡単な説明】
【００７４】
【図１】自動作成されたプルーフリード用ドキュメントの一例。
【図２】実施例１の全体構成図
【図３】実施例１のメインフロー図
【図４】スクリプトファイルの一例
【図５】プリンタフレンドリーネームの例
【図６】ドライバ印刷設定画面の第一階層
【図７】リソース情報取得ユーティリティのメイン画面
【図８】スクリプトコマンドの実行
【図９】ダイアログのリソース情報取得時の処理フロー
【図１０】スクリプト実行後、取得したスクリーンショットの例
【図１１】スクリプト実行後、取得した文字列情報の例
【図１２】プルーフリード用ドキュメント作成処理のフローチャート
【図１３】ドキュメント作成プログラム画面の一例
【図１４】第二実施例の構成図
【図１５】第二実施例Ｖｉｒｔｕａｌ ＰＣ画面。なお、図中、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａは登録商標である。
【技術分野】
【０００１】
本発明は情報処理装置、ＧＵＩプログラムの画面制御方法及びプログラム、ＵＩ部品の属性情報の取得方法及びプログラム。特に、前記方法で取得したＵＩスクリーンショットとＵＩ部品の属性情報を用いて、プルーフリーディングドキュメト作成の効率化に関する好適な技術に関する。
【背景技術】
【０００２】
コンピュータシステムは数多くの言語で存在している。多数のソフトウェアアプリケーションおよびオペレーティングシステムは、第１の言語で作成され、次いで、他の言語に移植される。これを、アプリケーションおよびオペレーティングシステムのローカライゼーションと呼ぶことがある。通常のローカライゼーション手法として２つやり方が存在する。
【０００３】
1. ソースプログラムのリソースファイル中の第１言語の文字列を抽出し、ローカル言語に翻訳した後、第１言語の文字列と差し替えて、ソースプログラムを再ビルド（コンパイル、リンク）することによって、ローカライズ版実行モジュールを生成する手法である。
【０００４】
2. 第１言語の実行モジュールから第１言語の文字列を抽出し、ローカル言語に翻訳した後、直接実行モジュール中の第１言語文字列と差し替え、再ビルドしない手法である。
【０００５】
前記何れの手法においても、翻訳作業は言語専門の翻訳者が担当し、ローカライズ版実行モジュールの作成作業は、専門のソフトエンジニアが担当するような形の共同作業が多い。このようなプロセスで作成されたローカライズ版の翻訳品質は翻訳担当者のレベルと経験に大きく依存しており、場合によって、翻訳精度は翻訳者の製品に関する知識にも関わる。また、熟練の翻訳者でも、文字列を翻訳する際、特定の文字列はＵＩ上の用語なのか、メッセージ用語なのか、コンテキストヘルプ用語なのか、それとも非表示用語なのかを知らないケースが多いので、翻訳用語の一貫性を保てない問題が少なくない。一方、ソフトエンジニアがローカル言語の知識がないので、翻訳の品質をチェックすることができない。よって、高品質のローカライズ版ソフトウェアを作成するために、対象のローカル言語知識及び製品知識を両方持つ第三者によるプルーフリード（翻訳用語チェック）が必要となる。プルーフリードを実施する場合、プルーフリーダー（翻訳用語チェックを行う人）がソフトウェア開発環境を持っていないため、彼らのためにプルーフリード用ドキュメントを準備しなければいけない。通常プルーフリード用ドキュメントは以下のような構成となっている。
【０００６】
1. 第１言語とローカル言語の該当プログラムの画面スクリーンショット
2. 前記画面上すべてＵＩ部品に表示している用語の一覧
3. プルーフリーダーが読みやすい形で前記スクリーンショットとＵＩ用語一覧を所定のフォーマットでまとめられ、プルーフリード結果やコメントの記入欄が用意されている
プルーフリード用ドキュメントの一例として、図１を参照ください。
【０００７】
図１のようなドキュメントを作成するには、従来以下のような手法が主に使われていた。
【０００８】
1. 第一言語ＯＳ環境で、第一言語で作られたプログラムを起動し、ＧＵＩ画面の切り替え操作で所定の画面を表示させ、ユーティリティを利用し、画面のスクリーンショットをクリップボードから取得した後、プルーフリードドキュメント内所定の位置に貼り付ける。
【０００９】
2. 次に、第一言語ＯＳ環境でステップ１の画面上のＵＩ用語を一々ドキュメントに手入力するか、プログラムソースコードのリソースファイル等からコピーし、プルーフリードドキュメント内所定の位置に貼り付ける。
【００１０】
3. 次に、ステップ１と同様な方法を用いて第二言語ＯＳ環境で、画面のスクリーンショットを取得し、プルーフリードドキュメント内第一言語スクリーンショットの右側に貼り付ける。
【００１１】
4. 次に、ステップ２と同様な方法を用いて第二言語ＯＳ環境で、手入力するかプログラムソースコードのリソースファイル等からコピーしてプルーフリードドキュメント内第一言語用語の右側に貼り付ける。
【００１２】
このようなプルーフリーディングドキュメント作成方法には、以下のような問題がある。
【００１３】
1. ２つ以上のＯＳ環境においての手作業が多く、時間がかかる。
【００１４】
2. ＵＩ用語を手入力する場合、不慣れな開発者にとって、キーボード操作が難しいので、タイピングミスが発生しやすい。
【００１５】
3. 図１に示されているように、ＵＩ用語一覧表の第一言語用語と第二言語用語が一対一の関係を持っているが、第二言語の意味が分らない開発者にとっては位置ズレ等編集ミスが発生しやすい。
【００１６】
そこで、ドキュメント作成の効率を向上させるために、所定操作手順に従いプログラムを起動し、自動的に特定のＧＵＩ画面を表示させることが実現できれば、スクリーンショット取得するための画面操作は速くなるはず。ソフトウェア規模が大きく、大量のＧＵＩ画面を有する場合、特に有効と考えられる。
【００１７】
文献１〜文献３に記載の操作マクロ生成装置では、利用者がシステムに対して操作を順に入力し、この一連の操作を記録することで、操作マクロを作成できる。利用者が行った操作から操作マクロを生成することにより、利用者がよく行う操作の手順を、操作マクロで実行することが可能となり、操作の効率が向上してきた。
【００１８】
また、ＧＵＩを有するシステムの動作の正常さを検査する装置として、ソフトウェア製品が市販されている。市販ソフトウェア製品のＧＵＩ検査装置では、利用者の入力操作に対するシステムの動作を検査するために、利用者の入力操作を自動化するためのスクリプトを記述する。また、入力操作を記録してスクリプトを作成することもできる。さらに、記録したスクリプトを編集することもできる。このようなスクリプトを用いて利用者の入力操作を自動的に実行させ、システムの動作結果を記録することで、異常な動作を検出することが可能となっている。
【特許文献１】特開平6-348481号公報
【特許文献２】特開平6-274329号公報
【特許文献３】特開平5-173741号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
しかし、文献１〜文献３に記載されている自動化操作装置の何れも、特定ＵＩ画面のスクリーンショットを取得できなかった。また、ＧＵＩ検査ツールはＵＩ部品の動作を検証し、ＵＩの問題とバッグを発見することが主目的なので、このようなシステムで自動生成されたスクリプトはローカル言語に依存し、複数言語を対応できないのが一般的である。更に、ＵＩ部品レベルまで詳細な属性情報（ＩＤや文字列等）をスクリプトに記述しないと、後ほどチェック動作ができなくなるので、スクリプト文法は煩雑、スクリプトライン数が長く、手入力の作成編集は大変難しい。なお、プルーフリードドキュメントを作成する場合、ＵＩ部品を一々記述せず、特定ダイアログ画面を開く手順だけをスクリプトに記載すれば、プログラム実行時すべてのＵＩ部品属性情報を自動的に取得することはできなかった。
【００２０】
本発明の目的は、複雑なスクリプトを用いず、画面開く手順だけを記載する簡単なスクリプトを使用し、自動操作で指定画面を開き、画面スクリーンショットを取得し、また該当画面上すべてのＵＩ部品の属性情報を取得できる。最終的に、前記取得した情報で、プルーフリード用ドキュメントを所定のフォーマットで自動的に生成できることである。
【課題を解決するための手段】
【００２１】
本発明の目的はローカライズしたアプリケーションの翻訳品質をチェックするために、第一言語の画面スクリーンショット及びリソース情報と、一対となるローカル言語の画面スクリーンショット及びリソース情報を自動的に取得し、マージしてプルーフリード（用語チェック）用資料を自動的に生成できることである。
【００２２】
なお、本発明のポイントは下記の通りである。
【００２３】
所定のダイアログＵＩを開く手順を記述するＵＩ操作手順記述手段を有する。
【００２４】
前記ＵＩ操作手順記述手段はＯＳの言語に依存しないことが特徴である。つまり、一旦作成したＵＩ手順記述をローカライズする必要がなく、どの言語のＯＳ環境でも実行できることが特徴である。
【００２５】
前記ＵＩ操作手順記述を複数ＯＳ間で共有できるＵＩ操作手順共有手段を有する。
【００２６】
前記ＵＩ操作手順記述に従い、所定のＵＩ画面を開き、画面のスクリーンショットを取得し、イメージファイルに保存する画面スクリーンショット取得手段を有する。
【００２７】
前記ＵＩ操作手順記述に従い表示させたＵＩ画面上に配置されているすべてのＵＩ部品（通常コントロールと呼ばれている）の表示可能な文字列及びホットキー等リソース情報を取得できるリソース情報取得手段を有する。
【００２８】
前記複数ＯＳ環境で取得できた画面スクリーンショット及びリソース情報を一か所に集め、ドキュメント上に配置し、所定フォーマットのドキュメントを自動的に生成できるドキュメント生成手段を有する。
【発明の効果】
【００２９】
ＧＵＩ画面のスクリーンショットとＵＩ部品属性情報の自動取得及びこれらのデータを用いてプルーフリードドキュメントを自動的に作成することで、ソフトウェアローカリゼーション開発者の作業効率を著しく向上させることができる。
【発明を実施するための最良の形態】
【００３０】
次に、本発明の詳細を実施例の記述に従って説明する。
【実施例１】
【００３１】
サーバＰＣの役割を果たすＳｅｒｖｅｒ−１及びクライアントＰＣの役割を果たすＣｌｉｅｎｔ−Ａ、Ｃｌｉｅｎｔ−Ｂ、Ｃｌｉｅｎｔ−ＣがローカルエリアネットワークＬＡＮ−１により接続され、相互的に通信可能な状態にある。なお、ＧＵＩを有するシステムソフトウェアはプリンタドライバとする。プリンタドライバ開発のプロセスとして、先ず英語版がビルドされ、市場リリース可能な一定レベルの品質に達した後、英語版をベースに日本語や韓国語等ローカル言語版をビルドしていく。また、本実施例のプリンタドライバのアーキテクチャ（内部モジュール構成）は機能モジュールとリソースモジュールを分離し、ＵＩ部品関連用語やメッセージ等ローカライズ必要なリソース情報（文字列、アイコン、ビットマップ、ホットキー、マウスカーソル等）をリソース専用ＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋ Ｌｉｂｒａｒｙ）に配置する。なお、ローカライズ手法は発明背景のところで紹介したバイナリローカライズを採用し、完成後のすべてのローカル言語版とベースの英語版と同様なバイナリコードを使用し、ＵＩ関連リソースだけ違うような構造となることで、すべて言語のプリンタドライバは同様に振舞い、機能差がないメリットを得られる。更に、このような手法で作成されたローカル言語版ＵＩ部品の識別ＩＤはベースの英語版と変わらないメリットも得られる。本発明により開示された技術を使用することで、ドライバ開発者はローカル言語がわからなくても、図１で示すようプルーフリードドキュメントを自動的に作成することができる。自動作成されたプルーフリードドキュメントを 用語チェック部門担当者に送付して、プリンタドライバがインストールされていない環境でも、ドライバＵＩ用語のチェックを行うことが可能になる。
【００３２】
さて、図２で示した各ＰＣのソフトウェア環境を簡単に紹介する。
【００３３】
● Ｓｅｒｖｅｒ−１
日本語版Ｗｉｎｄｏｗｓ（登録商標）を搭載し、画面スクリーンショットやＵＩ部品の属性情報（以降、便宜上リソース情報と呼ぶ）を取得する際に必要なダイアログ開く手順（以降、便宜上スクリプトと呼ぶ）をＳｅｒｖｅｒ−１のハードディスク上に格納し、各クライアントＰＣからアクセスできるように共有している。また、各クライアントＰＣ上で取得したリソース情報をＬＡＮ−１経由で本ＰＣのリソースＤＢに保存される。また、リソースＤＢに格納された情報に基づき、所定のフォーマットに従って、プルーフリードドキュメントを自動生成する手段を有するプログラムも本ＰＣ上の記憶装置に格納される。また、Ｓｅｒｖｅｒ−１に搭載するＯＳ言語は日本語版に限らず、プルーフリードドキュメント作成者にとって使いやすい言語であれば、ローカル言語でも良い。また、プルーフリードドキュメント自動生成プログラムの使用言語に制限がない。
【００３４】
● Ｃｌｉｅｎｔ−Ａ
英語版Ｗｉｎｄｏｗｓ（登録商標）及び英語版プリンタドライバを搭載する。更に、プリンタドライバＵＩのリソース情報を取得する手段を有するプログラムも本ＰＣ上の記憶装置に格納されている。また、リソース情報取得プログラムの表示用言語として、本実施例においては英語版を使用するが、他のローカル言語版でも良い。
【００３５】
● Ｃｌｉｅｎｔ−Ｂ
日本語版Ｗｉｎｄｏｗｓ（登録商標）及び日本語版プリンタドライバを搭載する。また、日本語版プリンタドライバは英語版プリンタドライバをベースにバイナリローカライズ手法でローカライズされたバージョンとする。更に、プリンタドライバＵＩのリソース情報を取得する手段を有するプログラムも本ＰＣ上の記憶装置に格納されている。また、リソース情報取得プログラムの表示用言語として、本実施例においては日本語版を使用するが、他のローカル言語版でも良い。
【００３６】
● Ｃｌｉｅｎｔ−Ｃ
韓国語版Ｗｉｎｄｏｗｓ（登録商標）及び韓国語版プリンタドライバを搭載する。また、韓国語版プリンタドライバは英語版プリンタドライバをベースにバイナリローカライズ手法でローカライズされたバージョンとする。更に、プリンタドライバＵＩのリソース情報を取得する手段を有するプログラムも本ＰＣ上の記憶装置に格納されている。また、リソース情報取得プログラムの表示用言語として、本実施例においては韓国語版を使用するが、他のローカル言語版でも良い。
【００３７】
更に、Ｃｌｉｅｎｔ−Ｂにインストール済みの日本語バージョンプリンタドライバとＣｌｉｅｎｔ−Ｃにインストール済みの韓国語バージョンプリンタドライバはＣｌｉｅｎｔ−Ａにインストールされている英語バージョンプリンタドライバをベースにして、バイナリローカライズ手法でローカライズされたものである。各バージョンのＵＩ用表示言語は別物だが、ＵＩコントロール（部品）のＩＤは同じである。また、バイナリローカライズはドライバ実行モジュールのバイナリコードを変更しないため、機能面において各バージョンのドライバは同様な振舞いをする。
【００３８】
つづいて、プリンタドライバＵＩのプルーフリードドキュメント自動生成は図３のメインフロー図で示されているように、３０１〜３０４の四つのステップから構成されている。次に、各ステップの機能及び実現方法について詳しく説明する。
【００３９】
ステップ３０１にてＵＩ部品に関するリソース情報（ビットマップやＵＩ用語等）を取得するために使われるスクリプト（画面開く手順）を作成しておく。更に作成されたスクリプトファイルをＳｅｒｖｅｒ−１の共有フォルダに保存し、各クライアントＰＣからアクセスできるように設定しておく。本実施例に使われるスクリプトファイルの一例を図４に示している。
【００４０】
図４内一番左側の括弧内の数値は説明便宜上のライン番号を表し、スクリプトの内容ではない。スクリプト内容はライン番号の右側である。また、「；」より右側の内容はコメント（説明文）であり、スクリプトコマンドに影響しない。
【００４１】
まず、01行目の「Conon MFP C6870 印刷言語LX 」はプリンタのフレンドリーネームを表す。Ｗｉｎｄｏｗｓ（登録商標）の「スタート」メニュー→「コントロールパネル」→「プリンタとＦＡＸ」の手順で操作すると、図５画面のように現在システムにインストールされているすべてのプリンタが表示される。この画面に表示されているプリンタの名称はフレンドリーネームである。本実施例においては、プルーフリード用資料を「Conon MFP C6870 印刷言語LX 」ドライバＵＩベースに作成されるので、Ｃｌｉｅｎｔ−Ａに英語バージョン「Conon MFP C6870 印刷言語LX 」プリンタドライバ、Ｃｌｉｅｎｔ−Ｂに日本語バージョン「Conon MFP C6870 印刷言語LX 」プリンタドライバを事前にインストールされていることを前提とする。また、Ｗｉｎｄｏｗｓ（登録商標）環境でプリンタドライバ印刷設定画面を開いた際、ダイアログタイトルの一部としてプリンタフレンドリーネームが使われる。印刷設定を表すローカル言語文字列はＷｉｎｄｏｗｓ（登録商標）システムにより提供される。例えば、英語版ＯＳの場合「Conon MFP C6870 印刷言語LX Printing Preferences」、日本語版ＯＳの場合「Conon MFP C6870 印刷言語LX 印刷設定」と表示される。
【００４２】
次、スクリプト02〜05行目はプリントドライバ印刷設定画面の第一階層（タブシートコントロール）のタブページ番号を表す。英語や日本語のようなLeft-To-Right言語の場合、タブシートの配置は左から右への順番で、図６の示す通り「Sheet 1＝ページ設定」、「Sheet 2＝仕上げ」、「Sheet 3＝給紙」、「Sheet 4＝印刷品質」である。逆に、アラビア語のようなRight-To-Left言語の場合、タブシートの配置順番は右から左へとなる。
【００４３】
次、スクリプト06行目の「Button 0xFFEE000A 1」は第一階層「Sheet 1」タブページ（ページ設定）の「ユーザ定義用紙」プッシュボタンがクリックされた場合、表示される第２階層のダイアログを意味する。「0xFFEE000A」は「ユーザ定義用紙」プッシュボタンのコントロールIDを表す。Ｗｉｎｄｏｗｓ（登録商標）システムで、それぞれのＵＩ部品は他の部品と区別できる唯一のＩＤが割り当てられている。更にドライバがローカライズされた後、ＵＩ部品の文字列が換わるが、ＩＤが変わらない特徴がある。この特徴を利用して、文字列の代わりにコントロールＩＤで作成されたスクリプトはローカライズの必要性がなくなり、そのまま、すべてのローカル言語ＯＳ環境で利用できるメリットを得られる。07行目「CloseDialog」は第２階層のユーザ定義用紙ダイアログをクローズすることを意味する。同様に、08行目「Button 0xFFEE000B 2」は、第一階層「Sheet 2」タブページ（仕上げ）の「仕上げ詳細」プッシュボタンがクリックされた場合、表示される第２階層のダイアログを意味する。09行目「CloseDialog」は、「仕上げ詳細」ダイアログを閉じることを意味する。同様に、10行目「Button 0xFFEE000C 4」は、第一階層「Sheet 4」タブページ（印刷品質）の「色設定」プッシュボタンがクリックされた場合、表示される第２階層のダイアログを意味する。11行目「CloseDialog」は、「仕上げ詳細」ダイアログを閉じることを意味する。また、12行目「TheEnd」でスクリプトの終了を識別する。
【００４４】
図４のスクリプト実施例は第２階層画面までしか操作しないが、決して制限を意味することがない。本特許で開示した方法で、複数階層の画面を開いたり、閉じたりすることが実現できる。例えば、下記スクリプトのように「Button XXX #」と「CloseDialog」のエンベッドにより、複数階層の対応が可能となる（；より右の内容は説明文）。
【００４５】
Sheet 1;（第１階層のタブページ１を開く）
Button 0xFFEE000A 1;（第１階層のタブページ１上のButton 0xFFEE000Aをクリックし、第２階層ダイアログを開く）
Button 0xFFEE002B 2;（第２階層のタブページ２上のButton 0xFFEE002Bをクリックし、第３階層ダイアログを開く）
Button 0xFFEE003C 1;（第３階層のタブページ１上のButton 0xFFEE003Cをクリックし、第４階層ダイアログを開く）
CloseDialog；（第４階層のダイアログを閉じる）
CloseDialog；（第３階層のダイアログを閉じる）
CloseDialog；（第２階層のダイアログを閉じる）
TheEnd；（第１階層のダイアログを閉じ、スクリプトを終了させる）
前記説明したように、本実施例のスクリプトファイルはローカル言語に依存しないので、ローカライズせずにクライアントＡ、Ｂ、Ｃの環境で使える。ただ、スクリプトファイルを各クライアントＰＣに直接配布して使う場合、以下の問題点が考えられる。
【００４６】
1. スクリプトを変更する場合、すべてのクライアントＰＣ上のスクリプトを修正しなければならない。手間がかかる。
【００４７】
2. あるクライアントＰＣ上のスクリプトが不注意で変更されたら、他のクライアントＰＣ上のスクリプトとマッチしなくなるので、プルーフリード用資料を作成する必要なリソース情報の整合性が取れなくなる。
【００４８】
そこで、本実施例のステップ３０１（図３）で作成済みのスクリプトファイルをＳｅｒｖｅｒ−１の記憶装置に格納し、他のクライアントＰＣからアクセスできるようにファイル共有を設定しておく。
【００４９】
つづいて、ステップ３０２で共有スクリプトファイルに従い、第一言語（英語）とローカル言語（日本語等）のＵＩ部品のリソース情報の取得方法について詳しく説明する。
【００５０】
図７はＵＩ部品のリソース情報を取得できるユーティリティ（ＧｅｔＡｌｌ）のメイン画面である。ＵＩ７０１は本ユーティリティの使用時のヘルプ情報を表示する。ＵＩ７０２コントロールでプリンタドライバＵＩ言語を選択する。通常プリンタドライバＵＩ言語はＷｉｎｄｏｗｓ（登録商標）言語と一致するので、手動設定の代わりに、Ｗｉｎｄｏｗｓ（登録商標） ＡＰＩ関数を使用してＯＳ言語を自動探索し、結果をＵＩ７０２に自動反映しても良い。ＵＩ７０３は取得したＵＩ部品リソース情報を格納する場所のサブフォルダを指定する。本ユーティリティのデフォルト設定で、格納先は「C:\AutoUI」であるが、ＵＩ７０３が「driver」に指定された場合、格納先は「C:\AutoUI\driver」となる。また、本ユーティリティは自動モード（Auto）と手動モード（Manual）２つのモードを提供する。ＵＩ７０５で手動モードを選択した場合、表示中１画面のりソース情報をしかとれない。本実施例は画面操作手順のスクリプトを使用して、複数画面の情報を一括で取得するために、ＵＩ７０４の自動モード状態でＵＩ７０６の取得（Capture）ボタンを実行する。次に、「Capture」ボタンが押された時、図４のスクリプトコマンドをどのように実行するかについて図８を使ってその処理の流れを説明する。
【００５１】
図８のステップ８０１で一行のスクリプトを読み込み、スクリプトコマンドの中身を分析する。ステップ８０６で「TheEnd」コマンドであるかどうかを判断する。Yesの場合、スクリプト処理を終了し、Noの場合、処理を継続する。次、ステップ８０７で「Conon MFP 6870 印刷言語LX 」のようなプリンタドライバフレンドリーネームかどうかを判断する。フレンドリーネームの命名規則はプリンタメーカーに委ねられていて、本実施例では「機種名＋PDL名称」のような構成となっているが、必要に応じて別の命名規則やドライバ名称以外の他のアプリケーション名も構わない。ドライバフレンドリーネームと判断できた場合、ステップ８０２で該当プリンタドライバ印刷設定画面を特定する処理を行う。Noの場合、処理をステップ８０８に移る。
【００５２】
ステップ８０２処理の目的は以降のスクリプトコマンドを実行するための前準備である。プリンタドライバ印刷設定画面が表示されなければ、画面のスクリーンショットやUI部品情報を取得できない。Ｗｉｎｄｏｗｓ（登録商標）環境でプリンタドライバ印刷設定画面を表示する方法は２つある。１つ目は手動操作であり、図５の「プリンタとFAX」ダイアログを表示させ、次に目的のプリンタアイコンを選択した上で、マウス右クリックでショートカット（ポップアップ）メニューを表示し、メニューから「印刷設定...」を選択する方法である。２つ目はＷｉｎｄｏｗｓ（登録商標）のシェル関数を呼び出すプログラムで自動表示させる方法である。何れの方法でもかまわないが、プリンタドライバの印刷設定画面が表示されると、ダイアログが初期化され、ウィンドウのインスタンスがシステム上に存在することになる。この時点でFindWindows() API関数を利用し、「ドライバフレンドリーネーム＋印刷設定」をタイトルとするウィンドウを特定し、そのウィンドウハンドル情報を取得できる。前記ウィンドウタイトルはＯＳ言語に依存であり、英語版の場合「ドライバフレンドリーネーム＋Printing Settings」となるが、ターゲットＷｉｎｄｏｗｓ（登録商標）システムの命名方法に従えば、確実にプリンタドライバの印刷設定画面のウィンドウハンドルを取得できる。ステップ８０２の処理が完了したら、ステップ８０１へ移る。
【００５３】
ステップ８０８の判断部で「Sheet」コマンドと判断した場合、第一階層上の所定のタブシートを表示させ、ステップ８０３で該当ダイアログのリソース情報を取得する処理を行う。「Sheet」コマンドは「Sheet #」のようなフォーマットで書かれる。「#」はタブシートのページ番号を表す。ステップ８０３処理のフローを図９で示しており、後で詳しく説明する。ステップ８０８の判断結果はNoの場合、処理がステップ８０９へ移る。
【００５４】
ステップ８０９の判断部で「Button」コマンドと判断した場合、ステップ８０４の処理で現階層のダイアログ上の指定UI部品（通常コマンドボタン）をクリックして、次の階層のダイアログを表示させる。更に、ステップ８０４の処理が終わると、ステップ８０３で新しく開かれたダイアログのリソース情報を取得する処理を行う。「Button」コマンドは「Button Control-ID #」のようなフォーマットで書かれる。「#」はタブシートのページ番号を表し、「Control-ID」で指定されたUIコントロールは第＃番目タブシートページ上に存在することを意味する。「Control-ID」はＷｉｎｄｏｗｓ（登録商標）システムに振り当てられたＵＩ部品を識別するための唯一のIDであり（Ｍｉｃｒｏｓｏｆｔ社製のSPY++ユーティリティを使って、より簡単に調べだすことができる）、Ｗｉｎｄｏｗｓ（登録商標）のAPI関数（SendMessage()等）を使用して、IDで指定されたＵＩコントロールにクリックイベントを表すメッセージを送ると、ＵＩコントロールのクリック操作をシミュレートし、次の階層のダイアログを表示させ、更にコントロールの文字列情報を使用しFindWindow() API関数で、新しいダイアログのウィンドウハンドルを取得することができる。ステップ８０９の判断結果はNoの場合、処理がステップ８１０へ移る。
【００５５】
ステップ８１０の判断部で「CloseDialog」コマンドと判断した場合、ステップ８０５の処理において「Button」で開かれた現在のダイアログを閉じ、上の階層ダイアログを現在の画面として表示させる。更に、ステップ８０５の処理が終わると、処理がステップ８０１に移り、次のスクリプトコマンドの読み込み処理を継続する。
【００５６】
図９はダイアログのリソース情報取得時の処理フローを示している。ステップ９０１で前記ステップ８０２または８０４で取得したウィンドウハンドルを利用して、Ｗｉｎｄｏｗｓ（登録商標）のBitBlt()関数で該当ダイアログのスクリーンショットのビットマップデータをバッファにコピーすることができる。バッファに格納されたビットマップデータは圧縮されておらず、そのままファイルに保存すれば、より多くの容量が必要となる。例えば、1024(pixel) ＊768(pixel) サイズの画面をフルカラー（32Bit/pixel）モードで保存する場合、1024＊768＊(32/8)＝3145728バイトになる。ファイルサイズが大きくなればなるほど、ネットワークでの転送時間がかかり、最終的に作成されるプルーフリードドキュメントのサイズも膨大になる問題がある。この問題を解決するために、ステップ９０２の処理はバッファに格納したスクリーンショットのビットマップデータを圧縮フォーマット（PNGやJPEG等）に変換して、ファイルに保存することを実現する。図４のスクリプト (02)行目「Sheet 1」を実行する際、ステップ９０１処理で取得した画面スクリーンショットを図１０の示す通りで、上は英語版、下は日本語版である。更に圧縮前・後の画像ファイルサイズの対比情報を以下に記載する。
【００５７】
次に、ステップ９０３の処理で、所定ダイアログ上のすべてのＵＩ部品を調べだす。Ｗｉｎｄｏｗｓ（登録商標）システムにおいて、ＵＩ部品も一つ一つ小さなウィンドウであり、更に厳密な所属関係があり、あるダイアログ上のＵＩ部品の親ウィンドウは該当ダイアログとなっている。Ｗｉｎｄｏｗｓ（登録商標）に提供されるＡＰＩ関数を利用して所定ダイアログ上のすべてのＵＩ部品を調べだすことができる。
【００５８】
次に、ステップ９０４の処理で、ＡＰＩ関数を利用してステップ９０３の調べた結果に従い、順次各ＵＩ部品のＵＩ表示用文字列とホットキー情報を取得し、所定のテキストファイルに保存していく。ＵＩ部品の種類によって、取得する文字列方法が違う。図１０のダイアログ画面を例に言うと、「お気に入り」のようなラベルや「縦」「横」のようなチェックボックスや「スタンプ編集」のようなプッシュボタンの場合、ターゲットＵＩ部品に文字列情報取得メッセージを送り、一回だけで文字列情報及びホットキー情報を取得できるが、「原稿サイズ」コンボボックスやリストボックスの場合、ターゲットＵＩ部品に複数回メッセージを送る必要がある。１回目のメッセージ送信は該当ＵＩ部品内のアイテム数を取得し、２回目以降のメッセージ送信により各アイテムの文字列取得を取得する。なお、本実施例では、１つダイアログ上のすべてのＵＩ部品の文字とホットキー情報を１つのテキストファイルに格納するように実装している。図１１は「Sheet 1」スクリプト実行後、取得した図１０ダイアログの文字列情報を示している。左側は英語版ＯＳ環境での実行結果で、右側は日本語版ＯＳ環境での実行結果である。
【００５９】
次に、ステップ９０５ですべてのＵＩ部品を処理完了と判断した場合、リソース情報取得処理が終了する。図４のスクリプトファイルを英語版Ｃｌｉｅｎｔ−Ａ環境で実行した後、ＰＣの「C:\AutoUI\driver」フォルダの下に、以下のようなリソースファイルが作成される。
【００６０】
【表１】
図４のスクリプトファイルを日本語版Ｃｌｉｅｎｔ−Ｂ環境で実行した後、ＰＣの「C:\AutoUI\driver」フォルダの下に前記と同様な結果を得られる。
【００６１】
次に、図３のステップ３０３の処理において、前記取得したリソースファイルをＳｅｒｖｅｒ−１の共有フォルダ「\\Server-1\AutoUI\」へ格納する。前記リソースファイルがオーバーライトされないように、英語版を「\\Server-1\AutoUI\English\driver」、日本語版を「\\Server-1\AutoUI\Japanese\driver」の下に格納する。本実施例はリソース情報を単に画像ファイルとテキストファイルとしてＳｅｒｖｅｒ−１の共有フォルダに格納しているが、検索・抽出しやすい形式のリレーションナルデータベースに格納しても可能で、オラクルデータベースやＳＱＬサーバやＤＢ２等典型的な市販品を使用することできる。
【００６２】
次に、図３のステップ３０４のプルーフリード用ドキュメント作成処理はＳｅｒｖｅｒ−１の環境で行い、処理の詳細は図１２のフローチャートを使って説明する。ステップ１２０１はドキュメントを新規作成するための初期化処理を行う。本実施例では、マイクロソフト社のＯｆｆｉｃｅ製品のマクロ機能を利用しＥｘｃｅｌフォーマットのプルーフリード用ドキュメントを作成することで、初期化処理においてはＭｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ（登録商標）とマクロプログラムを起動し、図１３のような画面を表示する。「\\Server-1\AutoUI\」はＳｅｒｖｅｒ−１の共有フォルダ名であり、ローカルフォルダ名は任意なので、ここで「C:\AutoUI\」とする。１３０１「Resource Folder」にてリソース情報の格納場所を指定できる。また、１３０２「Language」にてローカル言語を日本語に指定すると、英語と日本語用語対照一覧のプルーフリード資料を作成する。なお、１３０３の「Destination File」にて自動作成されるドキュメント名を指定できる。次に、１３０４「Checklist」コマンドボタンをクリックすると、処理は図１２のステップ１２０２に移り、１つ目のページ設定画面（図１０）関連のリソースファイルを特定し、以下の４つのファイルを開いて、データの読み込み準備をしておく。
【００６３】
・C:\AutoUI\English\driver\001.png
・C:\AutoUI\English\driver\001.txt
・C:\AutoUI\Japanese\driver\001.png
・C:\AutoUI\ Japanese \driver\001.txt
ステップ１２０３で画像ファイル「C:\AutoUI\English\driver\001.png」から英語版「ページ設定」ダイアログのスクリーンショットを読み込み、新規のＥｘｃｅｌシートの左上の適切な位置に配置する。同様にステップ１２０４で、画像ファイル「C:\AutoUI\Japanese\driver\001.png」から日本語版「ページ設定」ダイアログのスクリーンショットを読み込み、前記Ｅｘｃｅｌシートの右上の適切な位置に配置する。次、ステップ１２０５でテキストファイル「C:\AutoUI\English\driver\001.txt」から英語版「ページ設定」ダイアログの文字列＆ホットキーデータを読み込み、前記英語版「ページ設定」ダイアログのスクリーンショット下のセルに配置する。更に必要に応じて、コラムに名を付けてセルフォーマットを読みやすい形に整える。同様にステップ１２０６で、テキストファイル「C:\AutoUI\ Japanese \driver\001.txt」から日本語版「ページ設定」ダイアログの文字列＆ホットキーデータを読み込み、前記日本語版「ページ設定」ダイアログのスクリーンショット下のセルに配置する。更に必要に応じて、コラムに名を付けてセルフォーマットを読みやすい形に整える。次、ステップ１２０７判断部ですべてのＵＩ画面処理が完了したかどうかを判断し、「仕上げ」ダイアログ、「給紙」ダイアログ、「印刷品質」ダイアログ、「ユーザ定義用紙」ダイアログ、「仕上げ詳細」ダイアログ、「色設定」ダイアログに対して、前記ステップ１２０２〜１２０７の処理を繰り返す。すべてのダイアログ画面処理が完了したら、前記Ｅｘｃｅｌシートをファイルとして所定のフォルダに保存する。結果、図１のようなプルーフリード用ドキュメントを自動的に作成できる。
【００６４】
なお、前記説明はリソース情報が複数画像ファイル及びテキストファイルに格納される場合の処理説明であり、リソース情報がリレーションナルデータベースに格納される場合、データベースに接続しSQLクエリーを使用して、データベースからリソース情報データを抽出して、新規Ｅｘｃｅｌシートに配置することで同様にプルーフリード用ドキュメントを自動的に作成できる。
【００６５】
また、本実施例は２言語（英語＋日本語）プルーフリード用ドキュメントの自動作成方法を説明したが、本特許で開示した方法で他の言語を簡単に追加することが可能で、２言語以上のドキュメントを作成することも可能である。
【００６６】
また、本実施例において、Ｓｅｒｖｅｒ−１、Ｃｌｉｅｎｔ−Ａ、Ｃｌｉｅｎｔ−Ｂ、Ｃｌｉｅｎｔ−Ｃは別々のＰＣで構成されているが、必要に応じて任意のクライアントＰＣにＳｅｒｖｅｒ−１の機能を持たせることも可能である。
【００６７】
また、本実施例においてはＧＵＩを持つプリンタドライバのローカライズ版プルーフリード用ドキュメントの自動作成方法を例として説明してきたが、プリンタドライバ以外の他のＧＵＩを持つアプリケーションに対しても適応する。
【実施例２】
【００６８】
以下本特許の第二の好適な実施例を説明する。
【００６９】
第二実施例は図１４の示す通り、一台のＰＣに複数のＯＳを同時に稼働させるような構成となっている。このような環境を構築するには、まず１４０１英語版Windows XP（登録商標）をホストＯＳとしてＰＣにインストールする。次に、１４０２マイクロソフト社製Ｖｉｒｔｕａｌ−ＰＣを１４０１ホストＯＳにインストールする。更に、Ｖｉｒｔｕａｌ−ＰＣに日本語版Windows XP（登録商標）、韓国語版Windows XP（登録商標）、中国語簡体字版Windows XP（登録商標）、フランス語版Windows XP（登録商標）、ドイツ語版Windows XP（登録商標）等その他のローカル言語版Windows XP（登録商標）をインストールすることで、複数Windows XP（登録商標）を同時に一台のＰＣに立ち上げることが可能である。Ｖｉｒｔｕａｌ−ＰＣ動作時の画面の一例として図１５を参照ください。
【００７０】
図１４の環境において、１４０３スクリプトが１４０１英語版Windows XP（登録商標）の記憶装置に格納され、他のＯＳからアクセスできるように共有されている。リソース情報を保存するための１４０４リソースデータＤＢも１４０１英語版Windows XP（登録商標）に格納され、１４０３と同様、複数ＯＳ間で共有されている。ドキュメント作成プログラムが１４０１環境で実行できる状態にある。尚且つ、それぞれのWindows XP（登録商標）にＯＳと同じ言語のプリンタドライバがインストールされ、リソース取得プログラムもインストールされている状態である。
【００７１】
実施例１と同様な方法で、１４０１英語版Windows XP（登録商標）で動作しているリソース取得プログラムは１４０３スクリプトを読み込み、スクリプトコマンドに従い、英語版プリンタドライバＵＩを開き、リソース情報を取得して結果を１４０４リソースデータＤＢに保存する。
【００７２】
また、実施例１と同様な方法で、ローカル言語版Windows XP（登録商標）上で動作しているリソース取得プログラムは１４０３スクリプトを取得し、スクリプト手順に従い、ローカル言語版プリンタドライバダイアログのリソース情報を取得して結果を１４０４リソースデータＤＢに保存する。
【００７３】
実施例１と同様な方法で、１４０１英語版Windows XP（登録商標）で動作しているドキュメント作成プログラムは１４０４リソースデータＤＢから、画面スクリーンショットと文字列情報を抽出し、所定のフォーマットで１４０５プルーフリード用ドキュメントを自動的に作成できる。
【図面の簡単な説明】
【００７４】
【図１】自動作成されたプルーフリード用ドキュメントの一例。
【図２】実施例１の全体構成図
【図３】実施例１のメインフロー図
【図４】スクリプトファイルの一例
【図５】プリンタフレンドリーネームの例
【図６】ドライバ印刷設定画面の第一階層
【図７】リソース情報取得ユーティリティのメイン画面
【図８】スクリプトコマンドの実行
【図９】ダイアログのリソース情報取得時の処理フロー
【図１０】スクリプト実行後、取得したスクリーンショットの例
【図１１】スクリプト実行後、取得した文字列情報の例
【図１２】プルーフリード用ドキュメント作成処理のフローチャート
【図１３】ドキュメント作成プログラム画面の一例
【図１４】第二実施例の構成図
【図１５】第二実施例Ｖｉｒｔｕａｌ ＰＣ画面。なお、図中、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａは登録商標である。
【特許請求の範囲】
【請求項１】
ＧＵＩを有するプログラムを実行し、所定の画面操作手続きに従い、前記プログラムのＧＵＩ画面を表示させる画面表示制御手段と、前記画面表示制御手段により表示されたＧＵＩ画面のスクリーンショット（ビットマップ）を取得できるスクリーンショット取得手段と、前記表示されたＧＵＩ画面上のすべてのＵＩ部品の属性情報を取得できるＵＩ部品属性取得手段と、
第一言語のＯＳ環境において、前記スクリーンショット取得手段で取得した画面スクリーンショットと前記ＵＩ部品属性取得手段で取得した画面上のＵＩ部品属性情報及び、第二言語のＯＳ環境において、前記スクリーンショット取得手段で取得した画面スクリーンショットと前記ＵＩ部品属性取得手段で取得した画面上のＵＩ部品属性情報を一か所に集め、所定フォーマットに従って一つのドキュメント上に配置し、ドキュメントを自動的に生成するドキュメント生成手段と、
を有することを特徴とするプルーフリーディングドキュメント作成方法。
【請求項２】
前記スクリーンショット取得手段で取得した画面スクリーンショットを最終的にプルーフリーディングドキュメントに配置する前に、一時的に画像ファイルに保存できる画像ファイル保存手段を有することを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項３】
前記画像ファイル保存手段で保存された画像ファイルは画像データ圧縮手段により圧縮されたことを特徴とする請求項２に記載のプルーフリーディングドキュメント作成方法。
【請求項４】
前記ＵＩ部品属性取得手段で取得した画面上のＵＩ部品属性情報を最終的にプルーフリーディングドキュメントに配置する前に、一時的に属性情報ファイルに保存できる属性情報ファイル保存手段を有することを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項５】
前記スクリーンショット取得手段で取得した画面スクリーンショット情報とＵＩ部品属性取得手段で取得した画面上のＵＩ部品属性情報を最終的にプルーフリーディングドキュメントに配置する前に、所定のフォーマットでデータバース（オラクル（登録商標）やＳＱＬ）に保存できるデータベース保存手段を有することを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項６】
前記ＵＩ部品属性取得手段により取得されたＵＩ部品属性情報には、ＵＩ部品のリソースＩＤ、ＵＩ部品の文字列、ＵＩ部品のホットキー、ＵＩ部品のウィンドウクラス名の情報を有することを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項７】
前記画面操作手続き（スクリプトとも呼ばれる）はＧＵＩプログラム画面の第一階層及び第二階層以降所定のＵＩダイアログを指定可能あることを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項８】
前記画面操作手続きに、ＵＩダイアログ階層及び所定のＵＩダイアログを指定されなかった場合、すべての階層のＵＩダイアログを自動的に探索できることを特徴とする請求項７に記載のプルーフリーディングドキュメント作成方法。
【請求項９】
前記画面操作手続きは第一ローカル言語や第二ローカル言語の文字列に依存せず、一旦作成した手続きはどのローカル言語にも適応できることを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項１０】
前記画面操作手続きは２つ以上のローカル言語ＯＳ間で共有手段により共有できることを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項１１】
請求項１〜請求項１０のいずれかに記載のプルーフリーディングドキュメント作成方法を有するプログラム、メディア及び情報処理装置。
【請求項１】
ＧＵＩを有するプログラムを実行し、所定の画面操作手続きに従い、前記プログラムのＧＵＩ画面を表示させる画面表示制御手段と、前記画面表示制御手段により表示されたＧＵＩ画面のスクリーンショット（ビットマップ）を取得できるスクリーンショット取得手段と、前記表示されたＧＵＩ画面上のすべてのＵＩ部品の属性情報を取得できるＵＩ部品属性取得手段と、
第一言語のＯＳ環境において、前記スクリーンショット取得手段で取得した画面スクリーンショットと前記ＵＩ部品属性取得手段で取得した画面上のＵＩ部品属性情報及び、第二言語のＯＳ環境において、前記スクリーンショット取得手段で取得した画面スクリーンショットと前記ＵＩ部品属性取得手段で取得した画面上のＵＩ部品属性情報を一か所に集め、所定フォーマットに従って一つのドキュメント上に配置し、ドキュメントを自動的に生成するドキュメント生成手段と、
を有することを特徴とするプルーフリーディングドキュメント作成方法。
【請求項２】
前記スクリーンショット取得手段で取得した画面スクリーンショットを最終的にプルーフリーディングドキュメントに配置する前に、一時的に画像ファイルに保存できる画像ファイル保存手段を有することを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項３】
前記画像ファイル保存手段で保存された画像ファイルは画像データ圧縮手段により圧縮されたことを特徴とする請求項２に記載のプルーフリーディングドキュメント作成方法。
【請求項４】
前記ＵＩ部品属性取得手段で取得した画面上のＵＩ部品属性情報を最終的にプルーフリーディングドキュメントに配置する前に、一時的に属性情報ファイルに保存できる属性情報ファイル保存手段を有することを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項５】
前記スクリーンショット取得手段で取得した画面スクリーンショット情報とＵＩ部品属性取得手段で取得した画面上のＵＩ部品属性情報を最終的にプルーフリーディングドキュメントに配置する前に、所定のフォーマットでデータバース（オラクル（登録商標）やＳＱＬ）に保存できるデータベース保存手段を有することを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項６】
前記ＵＩ部品属性取得手段により取得されたＵＩ部品属性情報には、ＵＩ部品のリソースＩＤ、ＵＩ部品の文字列、ＵＩ部品のホットキー、ＵＩ部品のウィンドウクラス名の情報を有することを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項７】
前記画面操作手続き（スクリプトとも呼ばれる）はＧＵＩプログラム画面の第一階層及び第二階層以降所定のＵＩダイアログを指定可能あることを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項８】
前記画面操作手続きに、ＵＩダイアログ階層及び所定のＵＩダイアログを指定されなかった場合、すべての階層のＵＩダイアログを自動的に探索できることを特徴とする請求項７に記載のプルーフリーディングドキュメント作成方法。
【請求項９】
前記画面操作手続きは第一ローカル言語や第二ローカル言語の文字列に依存せず、一旦作成した手続きはどのローカル言語にも適応できることを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項１０】
前記画面操作手続きは２つ以上のローカル言語ＯＳ間で共有手段により共有できることを特徴とする請求項１に記載のプルーフリーディングドキュメント作成方法。
【請求項１１】
請求項１〜請求項１０のいずれかに記載のプルーフリーディングドキュメント作成方法を有するプログラム、メディア及び情報処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００９−１４６３５７（Ｐ２００９−１４６３５７Ａ）
【公開日】平成２１年７月２日（２００９．７．２）
【国際特許分類】
【出願番号】特願２００７−３２６０５０（Ｐ２００７−３２６０５０）
【出願日】平成１９年１２月１８日（２００７．１２．１８）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２１年７月２日（２００９．７．２）
【国際特許分類】
【出願日】平成１９年１２月１８日（２００７．１２．１８）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]