JP2007293869A

JP2007293869A - 文書変換方法および装置

Info

Publication number: JP2007293869A
Application number: JP2007122725A
Authority: JP
Inventors: Dylan B Ashe; アシュ、ディラン、ビー．; Nick G Kledzik; クレジック、ニック、ジー．
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 1992-12-28
Filing date: 2007-05-07
Publication date: 2007-11-08
Anticipated expiration: 2023-09-03
Also published as: ATE164016T1; JP4145947B2; DE69317443T2; JP3993215B2; DE69317443D1; JPH08505723A; EP0676069B1; EP0676069A1; CA2152788A1; JP3993227B2; WO1994015307A1; AU5960594A; JP2006127551A; US5652876A; CA2152788C

Abstract

【課題】コンピュータシステムにもはや存在しないアプリケーションプログラムにより作成された文書を変換して開く。
【解決手段】まずターゲットの文書のフォーマットが特定される。こののち、コンピュータシステムに駐在しし、かつ当該文書を開くことができるアプリケーションプログラムをすべて特定し、当該文書のフォーマットから当該アプリケーションプログラムへの変換パスが計算される。特定されたアプリケーションプログラムおよびその変換パスを変換の忠実度に応じて一覧表示し、さらに推奨表示を行う。一覧から１のアプリケーションプログラムが選択され、それにより変換が行われ、アプリケーションが起動して変換後の文書を開く。
【選択図】図６

Description

本発明はコンピュータ用のファイリングシステムの改良に関する。より詳細には、異なるファイルシステム間における文書変換の簡素化に関する。

ワークステーションのソフトウエアのデベロッパにとって、ユーザーのインターフェイスにおける一貫性を維持しつつフレキシブルなソフトウエア環境を提供することがますます重要になっている。この種の操作環境を提供しようとする初期の試みについては特許文献１に記載がある。この特許はユーザーがカーソル位置に動的メニューを呼び出し、そのメニューからさまざまなファンクションのどんなものでも呼び出すことができる図表と文章とを組合せた処理システムについて記載している。この種のユーザーとの自然な相互作用は、ユーザーのインターフェイスを改良し、アプリケーションを格段に直感的なものにする。

Ｗ０ＲＤのワードプロセッシングプログラム及びＭａｃＷｒｉｔｅのワードプロセッシングプログラムは現在のところ、文書変換の際に使用できる翻訳プログラム（変換プログラムともいう。以下では、「翻訳」は「変換」と同義である）について静止リストを提供している。しかし追加的に変換ルーチンが作られるのにつれて静止リストに動的に追加していける能力はない。また、それがなければオペレーティングシステムに認識不能なファイルの動的オープニングを提供する解決法のあるシステムは未だ存在しない。今日の技術水準は、ファイルを選択した後、Ｍａｃｉｎｔｏｓｈ［商標］コンピュータ、その他のコンピュータシステムにオープニングを開始するようファイルを挿入しても、そのオープニングシステムが、その特定ファイルの独自の性質を認識するよう前以てプログラムされていないと、あるいはそのファイル取扱い用のアプリケーションがインストールされていないと、処理できない旨を標準指示メッセージ［ａｓｔａｎｄａｒｄｐｒｏｍｐｔ］がユーザーに表示するようなものにすぎない。

また、特許文献２は、１の文書フォーマットを１または複数の変換プログラムを用いて他の文書フォーマットに変換することを開示している。しかしながら、この引用文献では、対象の文書を作成したアプリケーションプログラムが現在アクセス可能かどうかを判別してアクセスできないと藩閥されたときに適宜にフォーマット変換を行うことについては何ら記載・示唆がない。
米国特許第４，６８６，５２２号特開平０３−５７０３９号公報

そこで本発明の第１の目的は、特定区域内情報通信網のような通信ライン経由で、地域的、遠隔的にコンピュータに接続される代替のプログラムや翻訳ソフトウエアをサーチし、ユーザーが文書をオープニングするか変換するかの二者択一的選択から選択することができるファイル変換能力を提供することにある。本発明は人間工学的な方法で１つ又は２つ以上の文書を新たなフォーマットに変換するオプションをユーザーに提供するのである。本発明はまた、ユーザーのファイルに対する視点に、ＤｉｓｋＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ（ＤＯＳ），ＷｉｎｄｏｗｓあるいはＵＮＩＸといった自システム以外のオペレーティングシステム（ＯＳ）で作られた文書を含むどんな種類の文書やプログラムについても新たな情報を供給するものでもある。

この発明によれば、上述の目的を達成するために、特許請求の範囲に記載のとおりの構成を採用している。ここでは、発明を詳細に説明するのに先だって、特許請求の範囲の記載について補充的に説明を行なっておく。

すなわち、この発明の一側面によれば、上述の目的を達成するために、コンピュータシステムにより現在アクセスすることができない第１のアプリケーションプログラムにより先に生成された当初の文書を処理するために当該コンピュータシステムによって実現される文書処理装置に：当該当初の文書を作成した上記第１のアプリケーションプログラムが当該コンピュータシステムによりアクセスできないことを判定する判定手段と；当該コンピュータシステムがアクセスすることができ、かつ、上記当初の文書を作成した上記第１のアプリケーションプログラムと異なり、さらに、上記当初の文書を変換した変換済み文書をアクセスすることができる第２のアプリケーションプログラムを識別するアプリケーションプログラム特定手段と；上記第２のアプリケーションプログラムから１のアプリケーションプログラムを選択する選択手段と；上記当初の文書を、上記選択手段により選択されたアプリケーションプログラムが許容可能なフォーマットに変換する変換手段とを設けるようにしている。

この構成においては、文書を作成したアプリケーションプログラムが利用できない場合に文書を変換するオプションを提示して使用勝手の良い態様で文書を利用可能にする。

なお、この発明は装置またはシステムとして実現できるのみでなく、方法としても実現可能である。また、そのような発明の一部をソフトウェアとして構成することができることはもちろんである。またそのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品もこの発明の技術的な範囲に含まれることも当然である。

この発明の上述の側面および他の側面は特許請求の範囲に記載され以下実施例を用いて詳述される。

この発明によれば、文書を作成したアプリケーションプログラムが利用できない場合に文書を変換するオプションを提示して使用勝手の良い態様で文書を利用可能にする。

以下、この発明の実施例について説明する。

本発明は、好ましくはＩＢＭのＰＳ／２コンピュータ、またはＡｐｐｌｅのＭａｃｉｎｔｏｓｈコンピュータのようなパーソナルコンピュータに既に備わっているオペレーティングシステムのコンテキスト中で実施されるのがよい。代表的なハードウエア環境を図１に示す。すなわち図１は、従来のマイクロプロセッサのような中央処理装置（ＣＰＵ）１０、ならびにシステムバス１２経由で相互接続されたその他多数の装置がある本発明のワークステーションの典型的なハードウエア構成を示している。図１のワークステーションには、ランダムアクセスメモリー（ＲＡＭ）１４、リードオンリーメモリー（ＲＯＭ）１６、磁気ディスク装置２０のような端末機に接続されるＩ／Ｏアダプタ１８、キーボード２４に接続されるユーザーインターフェイスアダプタ２２、マウス２６、スピーカ２８、マイクロホン３２、及び／又は例えばバスに対するタッチスクリーン装置（図示せず）のようなその他のユーザーインターフェイスデバイス、ワークステーションをデータ処理網に接続する通信アダプタ３４、バスをディスプレイ装置３８に接続するディスプレイアダブタ３６などがある。このワークステーションにはＡｐｐｌｅＳｙｓｔｅｍ／７［登録商標］のようなＯＳが既に装備されている。

図２はユーザーがプログラムを呼出し文書を使用可能なフォーマットに変換するため該当する翻訳ルーチンを積極的に選択しなければならない先行技術の翻訳プログラムの１例である。図３ではオープンファイルに失敗したときの代表的なＭａｃｉｎｔｏｓｈメッセージを示している。

本発明の好ましい実施例は、コンピュータが、それを作り出したプログラムにアクセスを有していないときでも文書をオープンできるシステムソフトウエアの拡張として実現されている。好ましくは本発明は文書をオープンしないでも文書を別のプログラムのフォーマットに変換する。

本発明は他のＭａｃｉｎｔｏｓｈのタスクと同じ様に容易に、このような文書をオープンし、別の文書フォーマットに変換する。それは文書をオープンすることができるプログラムを見つけだし、ユーザーの選択に供するためそれらのプログラムをリスト表示することができる機能をシステムに供給するものである。そうすればユーザーはそれ自身の内にある翻訳能力を使って文書を変換することができるプログラム、または特別の翻訳ソフトウエアを使うプログラムを選択することができる。

本発明は変換処理を準備し、変換を行う翻訳ソフトウエアを呼び出す。本発明は文書及びプログラムに関する情報を集め、最適のオプションを選択しリストアップさせるためにエキスパートシステムを使い、ユーザー選択を記録し、そしてユーザーに前に行った選択を思い出させる。本発明はまた、特定の具体的な文書にとって最も好ましいものを決定させるため、ユーザーがオプションから試行することを可能にする。こうした能力は文書に関する情報をより多く提供するもので、ひいてはユーザーをしてパーソナルコンピュータで利用可能なより広範な種類の文書、例えば、ＯｔｈｅｒＥｑｕｉｐｍｅｎｔＭａｎｕｆａｃｔｕｒｅｓ（ＯＥＭ）、ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ（ＰＣ）のようなその他のコンピュータで作り出されたシステムや文書に現時点で実行中でないプログラムにより作成された文書などに当たってみるという、より大きいフレキシビリティを与えるものである。図４Ａはファイル名４００ならびにそれらのサイズ４１０、種類４２０のディスプレイの１先行技術例である。図４Ｂは本発明のディスプレイの１例である。４４０の種類欄は先行技術のディスプレイより広い記述情報を有している。

ユーザーがディスクやフォルダの内容を名前、サイズ、種類あるいは日付につき見ることを選択すると、本発明でなければ見ることができない詳細な情報を見ることができる。図５Ａは先行技術のファイルビューの１例である。これと対照的に本発明では、アプリケーションプログラムで使われたときオープンすることができる文書全部のリストを示す。ユーザーがプログラムのＦｉｌｅメニューからＯｐｅｎメニューを選択すると、そのプログラムでオープンすることができる文書より多くの文書がディスプレイされ得る。図５Ｂは本発明のＯｐｅｎメニューを図示したものである。

典型的な翻訳拡張である翻訳拡張ファイルの例としては、アプリケーション拡張ファイル用のＸＴＮＤがある。これらのファイルは本発明をＣｌａｒｉｓのプログラム及びファイル翻訳ソフトウエアに結合させるように設計されている。ＲＴＦ／スタイル拡張ファイルは、ＭｉｃｒｏｓｏｆｔＷｏｒｄとＭａｃＷｒｉｔｅＩＩ間のような一定のプログラム間で複写や切張りをするとき材料を翻訳するのに要求される追加ファイルである。

本発明は、文書をオープンし、文書間で切張りし、キーボード省略［ｋｅｙｂｏａｒｄｓｈｏｒｔｃｕｔｓ］を使うなどするとき、典型的なＭａｃｉｎｔｏｓｈのツール全てを採用するものである。また本発明はユーザーのために次のことを可能にする。すなわち、

（１）文書をオープンし変換する際に使われるべきプログラム及び翻訳ソフトウエアを選択すること、
（２）高速変換用の特別な文書コンバータにすること、
（３）特定のユーザーの好みにマッチするように本発明を改変すること。

文書オープンの方法：
ＡｐｐｌｅＭａｃｉｎｔｏｓｈコンピュータに採用されている典型的なプロシージャは本発明の好ましい実施例に従い下記のステップに挙げてある。当業者であれば、特許請求された本発明の技術範囲から離れることなく、これら以外のステップでも代替できることを了解するであろう。

１．ＭａｃｉｎｔｏｓｈＥａｓｙＯｐｅｎ（ＭＥＯ）ディスクウインドウ中のＯｐｅｎＭｅアイコンを２度スイッチ［ｄｏｕｂｌｅ−ｃｌｉｃｋ］させる。ＯｐｅｎＭｅはＭａｃＷｒｉｔｅバージョン５．０文書である。当業者ならＯｐｅｎＭｅが文書の例示名称であって、それ以外の文書およびこれに関連する名称も同様に取扱うことができることを容易に理解するであろう。

２．リストを見直し、貴方の翻訳パフォーマンスを選択するためスイッチを入れる［ｃｌｉｃｋ］。ユーザーは同時に１個の選択しか選択しない。ユーザーに見えるチョイスはその特定のシステムにインストールされているプログラムおよび翻訳ソフトウエアの種類によって異なる。よく起こることは、翻訳拡張を含むチョイスは最良の結果をもたらすが、翻訳は必要に応じて交換できることである。図６はユーザーが本発明に従ってファイルをオープンしたとき、動的に提示されるディスプレイである。６００で本発明はどのプログラムがその文書を作ったのかを示す。この場合、“ＭａｃＷｒｉｔｅＩＩ”ラベル６１０はＭａｃＷｒｉｔｅＩＩがこの文書をそれ自身でオープンすることができること、あるいはラベル６２０でＭａｃＷｒｉｔｅＩＩはＸＴＮＤ翻訳拡張ファイルと共にワークすることができることを示している。最後にラベル６３０で、選択ボックスはオプションが推薦されたチョイスだけしか示さないために存在していることを示している。

３．オープンボタンを入れよ［ｃｌｉｃｋ］。進行度合インジケータは文書が翻訳されていく度合を示す。図７は本発明に従い文書が翻訳されていく進行度合インジケータを示している。ラベル７００は使用中の翻訳拡張を明確に表している。ラベル７１０は現時点に行われている翻訳の進行度合を示している。ラベル７２０は進行中の翻訳を中止するための選択領域である。

４．文書をオープンしたら、その文書が正しくフォーマットされているかチェックせよ。本発明は文書が新しいプログラムフォーマットに変換されていることを示すため文書を再命名する。

５．変換されたコピーを保管するため、ＦｉｌｅメニューからＳａｖｅＡｓ＿を選択し、貴方のチョイスの場所にそのコピーを置け。図８は本発明のＦｉｌｅメニューを示す。ラベル８００で、ユーザーがチョイスのファイル名を保管することができるように上記ＳａｖｅＡｓのオプションが選択されている。Ｆｉｌｅメニューがラベル８１０で選択されたことが示されている。

もし翻訳の結果が満足のいくものでないときは、別のオプションがある。すなわち、
・もし貴方がこのチョイスを欲していないことが明白なら、新しい文書を保管することなく貴方はプログラムを中止することができ、別のチョイスをするためＯｐｅｎＭｅアイコンを再び２度スイッチすることかできる。そして、
・もし貴方が結果を比較してみたいなら、変換された文書を保管し、別のチョイスでオリジナル文書を再びオープンすることができる。本発明は各種文書のため貴方がつくった最も新しい優先度を記憶していて、次回に同じような種類の文書が選択されたとき、その最も新しい優先度がチョイスのリスト中にハイライト表示される。最適の結果を生み出すチョイスがないときは、本発明はオリジナルのフォーマット形成をしないで単にテキストとして文書をオープンし得るチョイスをディスプレイする。「推薦されたチョイスだけを示せ」というオプションはない。図９は本発明に従った文書翻訳ディスプレイを図示したものである。ラベル９００は推薦されたチョイスだけがディスプレイされているなら選択することができるチェックボックスである。ラベル９１０は、もし貴方が前に同様な文書をオープンするようチョイスしたのなら、本発明はリスト中の貴方の最も新しい優先度を選択することを示している。ライン９２０以下にリストされているチョイスは最適結果を生み出すとは限らない。推薦されたチョイスだけしか選べないのなら、本発明は全部のチョイスをディスプレイする。

文書アイコンを貴方のシステムに追加されたプログラムアイコンに引き当てる［ｄｒａｇｔｏ］ことができ、１または２以上の文書を自動的にオープンすることができる。それは文書アイコンを図１０に示すようにその文書をオープンする能力のあるプログラムのアイコンに引き当てることによって行われる。もしそのプログラムが文書をオープンすることができるなら、そのアイコンがハイライト表示される。もしプログラムが貴方の引き出した文書をオープンすることができるなら、図６に示すのと同様に本発明は利用可能なチョイスのリストを提示する。このリストは特定のアプリケーションプログラムや利用可能な翻訳ソフトウエアを含むチョイスに限定される。プログラム同士を複写したり切張りすることは、情報が切張りされた文書中にある受容可能なフォーマット中に複写された材料の翻訳を行うよう本発明によって可能にされている。

文書コンバータ：
文書コンバータは文書を特定のプログラムのフォーマットにその文書をオープンすることなく変換するために設置される便利なシステムユーティリティである。ひとたび文書コンバータが特定のタイプの変換のために初期化されると、文書はそれらのアイコンをコンバータのアイコンに引き出すことによって容易かつ迅速に変換することができる。特定の文書コンバータのアイコンは各種文書のために設置することができる。

文書コンバータを設置するには次のステッブに従う。
１．貴方のハードディスクからＤｏｃｕｍｅｎｔＣｏｎｖｅｒｔｅｒを選択し、ＦｉｌｅメニューからＤｕｐｌｉｃａｔｅを選びなさい。
２．文書コンバータのコピーをオープンしなさい。
３．Ｓｅｔボタンを入れなさい。
４．Ｓｅｔボタンを入れなさい。

本発明は新しい文書コンバータ名を付与する。この名前はユーザーの判断で変更することができる。

文書の変換：

文書コンバータが正しく初期化されていれば使用は簡単である。文書を変換するには、ＯｐｅｎＭｅアイコンを文書コンバータアイコンに引き出し、マウスボタンを解放する。両アイコンともハイライトされて変換が始まったことを知らせる。

本発明は文書のコピーを作り、文書に（変換された）名前を付与し、オリジナルをそのまま残す。１グループの文書を新しいフォーマットに変換するには、アイコンを選択し、それらを初期化されている文書コンバータに引き出す。

本発明のオプションの初期化：
本発明のカスタム化のためのたくさんのオプションがある。

オプション

オン／オフ：
文書を翻訳する必要がないときは翻訳機能を切ることができる。しかし本発明のシステムソフトウエアがスタートアップ［ｓｔａｒｔｕｐ］ディスクに備わっている限り、向上された情報がＦｉｎｄｅｒ及びファイルのリストビューになお利用可能であり、文書コンバータもなお使用することができる。ＦｉｎｄｅｒについてはＡｄｄｉｓｉｓｏｎ−ＷｅｓｌｅｙＰｕｂｌｉｓｈｉｎｇＣｏ．から１９８５年〜９１年に発行された「ＩｎｓｉｄｅＭａｃｉｎｔｏｓｈ」第１〜６巻に詳述されている。

常時チョイスを表示する：
ＡｌｗａｙｓＳｈｏｗＣｈｏｉｃｅｓを選択すると、たとえ優先選択［ｐｒｅｆｅｒｅｎｃｅ］が選択されているとしても、特定の種類の文書をオープンするためのチョイスのリストを提示する。このオプションが解除［ｄｅｓｅｌｅｃｔ］されると、本発明はかつて指示してあった優先選択を特に確認することなく再作動させる。

サーバーからチョイスを算入する：
本発明は、たとえディスクトップで利用可能にされているファイルサーバーをも含めて、ディスク上のあらゆる利用可能なプログラムをサーチするように設置されているのが通常である。ネットワークを介して遠隔のディスクにあるプログラムを使うには長時間が要求されることがある。ハードディスクにしかないプログラムのシステムサーチを、そのシステムに直接接続するため、この制御を解除するようスイッチする。

優先選択の削除：
特定の翻訳優先選択用に選ばれた本発明のチョイスのレコードを消すには、ＤｅｌｅｔｅＰｒｅｆｅｒｅｎｃｅｓボタンを入れる。例えば新たな翻訳ソフトウエアが利用可能なときは、従前のチョイス全てを即座に削除し、そのシステムを各々の新しいチョイスに駆り立てることが便利であろう。

動的な翻訳リスト：
オペレーティングシステムがユーザーにファイルをオープンするための標準的ユーザーインターフェイスを提供しているコンピュータでは、本発明はインストールされている外部のトランスレータファイルに基づきアプリケーションが現実にオープンすることができるファイルフォーマットをオペレーティングシステムに供給する。本発明は後述するように、新しい［ｃｕｒｒｅｎｔ］能力を発揮するためアプリケーションプログラムによりオンザフライに操作することができるファイルのリストを構築する。

ロジックの詳述

動的なアプリケーションオープン能力：
特定のプログラムにどんなフォーマットの文書を決定するかのシステム及び方法は動的な方法で決定され、図１１Ａ及び図１１Ｂに示すロジックでユーザーに相互作用で提供される。処理はロジックの概括的一覧が提示される機能ブロック１１００から始まる。ロジックは特定のプログラムがオープンでき起動できるファイルフォーマットを見つけ出す。次に機能ブロック１１１０で、アプリケーションが常にオープンすることができるフォーマットで始めることによって処理が開始される。この情報は殆ど全てのアプリケーションプログラムの所定位置に配置され、好ましくはその後、最初のＤｙｎａｍｉｃＡｐｐｌｉｃａｔｉｏｎＯｐｅｎＣａｐａｂｉｌｉｔｙ（ＤＡＯＣ）が機能ブロック１１２０及び１１３０に示すように標準的なＳｙｓｔｅｍ７オペレーションを介してアプリケーションリストを得ることによって開始される。

機能ブロック１１３０に関係するロジックの詳述は図１１Ｂに示されている。

処理は、外部の全てのトランスレータファイルが同定される機能ブロック１１３１で開始する。すると機能ブロック１１３２に示された第１の外部のトランスレータファイルで開始して、第１トランスレータファイルが読み出すことのできる抽出ファイルフォーマットが機能ブロック１１３３で同定される。次に、機能ブロック１１３５で、前記ファイルトランスレータファイルに対応するファイルフォーマットがリストのソース部に付加される。次に何らかの追加的トランスレータファイルが利用可能かどうかを決定する決定ブロック１１３６でテストが行われる。もし利用可能なら、次のファイルが機能ブロック１１３４で選択され、トランスレータファイルが処理することができるファイルフォーマットが機能ブロック１１３３で決定される。もうファイルが残っていないなら、これら外部のトランスレータを使うアプリケーションがリストの宛て先部分に付加され、処理が図１１Ａの決定ブロック１１４０にターミナル１１３８から戻る。

プログラムがリストの宛先箇所に存在しているか否かを決定するため決定ブロック１１４０でテストが行われる。プログラムが存在しているなら、機能ブロック１１５０で全てのフォーマットがオープンできるプログラムのリストに付加される。次に、ほかに処理すべきＤＡＯＣが残っていないかを判断するため処理が決定ブロック１１７０に移される。それ以上処理の必要がないのであれば、オープンできるファイルの完全なリストがターミナル１１８０でユーザーにリターンされる。もし処理にさらに別のファイルが利用可能なら、次のＤＡＯＣが機能ブロック１１６０で選択され、リストを次のＤＡ０Ｃで更新するため制御が機能ブロック１１３０に移される。

図１２Ａ〜Ｇは本発明の翻訳ダイヤログのロジックの詳細のフローチャートである。翻訳ダイヤログは翻訳の可能性をコンピュータのユーザーに提供するユーザーインターフェイス部分である。可能性はユーザーが翻訳処理に関する知識をあまり要求せず、翻訳は通常のファイル処理オペレーションと同一方式で行われるという前提に基づいている。ユーザーが文書に二回スイッチを入れたことをシステムが感知すると、処理が機能ブロック１２００で始まる。

機能ブロック１２００で二回スイッチされた文書を作成したアプリケーションがシステムにインストールされているか否かにつき決定ブロック１２０２でテストされる。もしアプリケーションがシステム中に存在するなら、その文書が機能ブロック１２１２に示されるようにオープンされる。もしアプリケーションがシステム中に存在しないなら、本発明が文書をオープンすることができるか否かを決定するため別のテストが決定ブロック１２０４で行われる。もしオープンできないなら、その旨のメッセージが機能ブロック１２１４でユーザーに示される。

しかし通常そうなのだが、もし文書が本発明を使ってオープンできるなら、機能ブロック１２０６に示されるように、また図１２Ｂ〜図１２Ｇに詳細に示されるように、本発明の翻訳ダイヤログが文書に適用される。

図１２Ｂでは、本発明の翻訳ダイヤログが終了する機能ブロック１２０６と連携するロジックの拡張が開始している。最初の処理は可能な翻訳経路が計算される機能ブロック１５００で始まる。この機能ブロック１５００と関係するロジックについては図１２Ｃに詳細に示されている。最初の翻訳の組合せが機能ブロック１５２０で開始し、その他の全ての組合せは、機能ブロック１５３０をループの最初にして次の翻訳の組合せと始まることによって、機能ブロック１５１０でシステム用に定義された全ての翻訳組合せに関する表が作られる。次に機能ブロック１５４０で、ユーザーがオープンしようとしている文書からある経路が翻訳できるものか否かが決定される。もしできるのなら、その翻訳組合せが機能ブロック１５５０に示すように表中の可能な翻訳に加えられる。その他の組合せが残っているか否かにつき機能ブロック１５６０でテストされ、もし何も残っていないのなら、処理は機能ブロック１５３０へ戻される。

図１２Ｂの機能ブロック１６００のロジックは図１２Ｄに拡張されている。最初の翻訳経路から開始し、機能ブロック１６２０に示されるように次の翻訳経路を処理することによって機能ブロック１６１０で処理が始まる。次に、選択した文書をオープンするように、そのシステムにアプリケーションがインストールされているか否かを決定するため機能ブロック１６３０でサーチを行う。もし決定ブロック１６４０中にアプリケーションがあるなら、機能ブロック１６５０でそのアプリケーションが有効なエントリとして記録される。もしそのアプリケーションが決定ブロック１６４０中にないなら、その他の経路が残っているか否かにつき決定するため決定ブロック１６６０でテストが行なわれる。もし追加の経路が残っているなら、次の翻訳経路が機能ブロック１６２０で選択される。もし追加の経路が残っていないなら、制御はターミナル１６７０から図１２Ｂの機能ブロック１７００に戻される。

的確な翻訳ダイヤログが同定されたか否かを判断するため図１２Ｂの機能ブロック１７００でテストされる。もし何も検出されなければ、不履行という結果が機能ブロック２０４０にセットされ、制御は図１２Ａの決定ブロック１２０８に戻される。逆にもし的確な翻訳ダイヤログが確認されたら、機能ブロック１８００に進み、図１２Ｅに詳細が示されているように、確定した忠実度に基づいてカテゴリごとに経路が分割される。忠実度はフォーマットごとのデータ保存量についても示される。例えばＷＯＲＤ文書がＡＳＣＩＩフォーマットに変換されるときは、全てのフォーマッティング情報は喪失してしまう。しかしＷＯＲＤ文書がＷｏｒｄＰｅｒｆｅｃｔにトランスレータ経由で変換されるときは、そのフォーマッティングは保存される。

このようにＡＳＣＩＩ翻訳は忠実度が低くＷＯＲＤからＷｏｒｄＰｅｒｆｅｃｔへの翻訳は忠実度が高い。処理は最初の翻訳経路がセットされる機能ブロック１８１０で開始される。

次に機能ブロック１８２０で次の翻訳経路が立てられ、宛先が忠実度の低いフォーマットであるか否かが決定ブロック１８３０でテストされる。その宛先が忠実度の低いフォーマットなら、経路は機能ブロック１８４０の非優先選択チョイスのカテゴリにセットされ、制御は決定ブロック１８６０に進む。宛先が忠実度の低いフォーマットでないなら、機能ブロック１８５０で、経路は優先選択チョイスのカテゴリに付加され、処理されるべき経路が別に残っていないかどうかを判断するため制御が決定ブロック１８６０に進む。もし別の付加される経路が残っているなら、制御はその次の経路を処理するため機能ブロック１８２０へ進む。

もし付加される経路が残っていないなら、制御はターミナル１８７０へ進み、そこで処理は図１２Ｂの機能ブロック１９００に戻される。

優先選択機能が機能ブロック１９００に設けられる。優先選択機能設置オペレーションに関するロジックの詳細については図１２Ｆを参照のこと。処理は優先選択されたアプリケーションが設置される機能ブロック１９１０から始まる。次に機能ブロック１９２０で、優先選択された翻訳経路が設置される。そして最後に機能ブロック１９３０で優先選択機能が効力発効され、制御が図１２Ｂの機能ブロック２０００にターミナル１９４０から戻される。

図１２Ｇに詳細に描かれているように、内容のリストは機能ブロック２０００において作られる。処理は翻訳経路開始がセットされる機能ブロック２１００で始まる。次に機能ブロック２１１０で次の翻訳経路が選択され、アプリケーション名が機能ブロック２１２０で得られる。するとその経路がその翻訳システムを使うことができるかどうかを判断するため決定ブロック２１３０でテストが行われる。もし使えるなら、その翻訳システム名が機能ブロック２１４０で得られ、制御は機能ブロック２１５０へと進む。もし使えないなら、制御は機能ブロック２１５０へと進み、翻訳ファイルのリストへエントリを付加する。次に決定ブロック２１６０で、そのエントリが優先選択機能か否かを判断するためテストが行われる。もしそうなら、その優先選択機能が機能ブロック２１７０で選択され、制御が決定ブロック２１８０へと進む。もしそうでないなら、別に処理されるべき経路が残っていないかどうかを判断するため決定ブロック２１８０へと制御が進む。もし別の付加された経路が残っているなら、制御はその経路を処理するため機能ブロック２１１０へ進む。もし残っていないなら、制御は２１９０経由で図１２Ｂの機能ブロック２０１０へと戻る。

機能ブロック２０１０は図６に示したダイヤログを示し、機能ブロック２０２０で示されるユーザーの決定に基づく結果をセットする。すると制御はターミナル２０６０を経由して図１２Ａの決定ブロック１２０８に戻る。ユーザーが優先選択された翻訳プログラムを無効にしたか［ｏｖｅｒｒｉｄｅ］どうかを判断するため決定ブロック１２０８でテストが行われる。もしユーザーがその優先選択された翻訳プログラムを無効にしていないなら、ユーザーは機能ブロック１２１４でその旨を告げられる。もし別のチョイスが適当に選択されたときは、文書が機能ブロック１２１０で翻訳され、その文書が交換され、そして機能ブロック１２１２に示されるようにその文書はオープンされる。

それともなければ、もしユーザーが機能ブロック１２２０に示されるようにアイコンをアプリケーションに当てたなら［ｄｒａｇｏｎｔｏ］、そのアプリケーションがアイコンの示す文書をオープンすることができるか否かにつき決定ブロック１２２２で判断するためテストが行われる。もしその文書をオープンできるなら、そのことを示すためにアイコンがハイライトされる。もし文書がそのアプリケーションではオープンできないなら、その文書が図１１に示すロジックを採用してオープンすることができるか否かを判断するため決定ブロック１２２４でテストが行われる。もしその文書をオープンするのに本発明を使うことができるなら、そのアイコンをハイライトするため制御が機能ブロック１２３０へ進む。もしその文書をオープンするのに本発明を使うことができないなら、機能ブロック１２２６に示すようにそのアイコンはハイライトされない。

機能ブロック１２４０に示すように、もしユーザーが別のアプリケーションにとって最適である文書のアイコンを出したときは、その文書をアプリケーションがオープンできるかどうかについて判断するため決定ブロック１２４２でテストが行われる。アプリケーションが一つも利用できないなら、上述したように本発明を使ってその文書を処理するため決定ブロック１２０４に処理を進める。もしアプリケーションがその文書をオープンできるなら、機能ブロック１２４４に示すように文書はオープンされる。

機能ブロック１２６０に示すようにユーザーがＦｉｌｅＭｅｎｕからＯｐｅｎを選択したときは、機能ブロック１２６２に示すようにＯｐｅｎダイヤログリストに翻訳することができる文書が追加される。最後にもしユーザーがＯｐｅｎダイヤログにＯｐｅｎスイッチを入れたら、アプリケーションがその選択された文書をオープンすることができるかどうか判断するため決定ブロック１２５２でテストが行われる。アプリケーションがオープンできないなら、本発明がその文書をオープンするように決定ブロック１２０４に制御を進める。

アプリケーションの詳細：本発明にはプログラム上２つの視点がある。１つは本発明がＦｉｎｄｅｒ，ＳｔａｎｄａｒｄＦｉｌｅ及び将来的なアプリケーションのために提供する道具箱的なサービスである。これはＡｐｐｌｉｃａｔｉｏｎＣａｐａｂｉｌｉｔｉｅｓＭａｎａｇｅｒと呼ばれる。もう１つの視点は翻訳拡張の観点から要求されるサービスである。図１３は本発明に従って作成されたブロックダイヤグラムである。Ｆｉｎｄｅｒ１３００は標準的なオペレーティングシステムのＡｐｐｌｅＳｙｓｔｅｍ７の一部で、文書をオープンすることを含む通常のファイル処理ルーチンである。アプリケーション１３１０はワードプロセッサその他の標準的ファイル１３２０に作用するアプリケーションである。このＡｐｐｌｉｃａｔｉｏｎＣａｐａｂｉｌｉｔｉｅｓＭａｎａｇｅｒ１３３０は、Ｆｉｎｄｅｒ１３００が文書翻訳を行うのに必要とするサービスを提供する。翻訳拡張１３４０は、アプリケーションファイルではないファイルのための翻訳動作のセットである。アプリケーション翻訳拡張１３５０はアプリケーションのための翻訳拡張を含んでいる。これらの部分については以下に詳述する。

貴方のアプリケーションがオープンできるファイルのタイプを告知する：
Ａｐｐｌｅのシステムソフトウエアバージョン７．０及びその後のバージョンでは、リソースＩＤがアプリケーションの束中にリストされている（即ち、タイプ「ＢＮＤＵ」のアプリケーションのリソース）タイプ“ＦＲＥＦ”のリソースを検査することによって、どのタイプのファイルのアプリケーションをオープンすることができるかをＦｉｎｄｅｒは決定する。Ｆｉｎｄｅｒはこの情報を、どのファイルタイプが所定のアプリケーションにドロップラーンチ［ｄｒｏｐ−ｌａｕｎｃｈ］され得るのかを判断するのに用いる。アプリケーションの束中にリストされた「ＦＲＥＦ」リソースの全ファイルタイプは、それらが関連付けられたアイコンを有しているか否かとは無関係に、そのアプリケーションにドロップ可能と考えられる。

しかし場合によっては、アプリケーションがオープンされるべきでないファイルタイプの「ＦＲＥＦ」リソースを含んでいることがある。例えばアプリケーションが辞書のような非文書ファイルを使い、ファイルをヘルプすることがある。これらファイルはアイコンを持つべきなのであり、したがって「ＦＲＥＦ」リソースに相当するのであるが、これらの内容はユーザーに表示され得ない。同様にアプリケーションは優先選択ファイルからデータを読み込むことがあるが、このデータはそのアプリケーションによって内部的に利用されるのであって、ユーザーにより文書としてオープンされない。アプリケーションがオープンできるファイルタイプのリストはアイコンを有しているタイプのリストとは違うものかもしれないので、ＴｒａｎｓｌａｔｉｏｎＭａｎａｇｅｒは新しいリソースのタイプ「ｏｐｅｎ」を定義する。このオープンリソースはどのファイルタイプのアプリケーションが文書としてオープンできるかを宣言する。タイプ「ｏｐｅｎ」のサンプルリソースのＲｅｚ入力フォームにつき下記に示す。

／＊ＴｅａｃｈＴｅｘｔ用のリソースをオープンせよ＊／
リソース「ｏｐｅｎ」（１２８）
｛’ｔｔｘｔ’，｛’ｔｔｒｏ’，’ＰＩＣＴ’，’ＴＥＸＴ’｝｝，

オープンリソースはファイルタイプのリストが続くアプリケーションシグナチャでできている。これはある具体的なアプリケーションが、タイプがそのリスト中にあるファイルをオープンすることができることを示すものである。例えばＴｅａｃｈＴｅｘｔは、それ自身のプライベートなフォーマット、’ｔｔｒｏ’、あるいはファイルタイプ’ＰＩＣＴ’及び’ＴＥＸＴで作られた文書をオープンすることができる。もしＭａｃｉｎｔｏｓｈＥａｓｙＯｐｅｎを使用できるのなら、Ｆｉｎｄｅｒはユーザーがこれらのタイプの文書をそのアプリケーションにドロップすることを可能にする。さらに、もし何らかの翻訳拡張がインストールされているなら、１特定タイプに翻訳可能なあらゆる文書もそのアプリケーションにドロッブすることができる。したがってもしタイプ’ＳＵＲＦ’の文書をファイルタイプ’ｔｔｒｏ’に翻訳することができる翻訳拡張があるなら、ユーザーはＳｕｒｆＷｒｉｔｅｒ文書をＴｅａｃｈＴｅｘｔにドロップすることができる。もしＴｒａｎｓｌａｔｉｏｎＭａｎａｇｅｒが多数のファイルタイプから翻訳のための宛先ファイルタイプとしてのファイルタイプを選択しなければならないのだとすれば、そのリスト中で最初に出たファイルタイプを選ぶ。どの文書がファイルをオープンするダイアログボックス中にリストされるべきかを決定するために、オープンリソースもルーチンＳｔａｎｄａｒｄＯｐｅｎＤｉａｌｏｇによって使われる。

アプリケーションがオープンできるファイルのタイプは動的に決定され（おそらくあるフォルダにおいてどのフィルタが利用可能なのかを検査することによって）なければならないということは有り得ることである。フィルタは特定のアプリケーションのために利用可能な翻訳ルーチンを指摘する。もしそうなら、システムはオープンリソース中にそれらのファイルタイプを静的にリストすることができない。そのかわりに、オープンできるファイルタイプのリストをランタイムで作り出すために、簡単な翻訳拡張が書き込まれなければならない。

翻訳拡張の書込み：
翻訳拡張はデータ認識能力及び翻訳能力を供給するために本発明が果たす１構成要素である。翻訳拡張は１構成要素であるので、ＣｏｍｐｏｎｅｎｔＭａｎａｇｅｒによって送られる標準的なセレクタに応えなければならない。さらに、翻訳拡張は次の仕事を行わなければならない。

◎その翻訳能力をＭａｃｉｎｔｏｓｈＥａｓｙＯｐｅｎへ通信する
◎具体的な文書及びスクラップのフォーマットを同定する
◎文書及びスクラップを翻訳する
スクラップは、例えば切り張り作業の対象となる部分のような、文書の１部をいう。翻訳拡張はファイル、スクラッブ、またはこれら両者を同定する。翻訳拡張は’ｔｈｎｇ’リソース内の構成要素フラグ域にビットをセットすることによってファイル又はスクラップを取り扱う。この原則に対する唯一の例外は、それらがオープンできるのはどのファイルタイプかを動的に決定する必要があるアプリケーションに関する。

ファイルタイプとスクラッブタイプのデータタイプ：
タイプ
ＦｉｌｅＴｙｐｅ
＝ＯＳＴｙｐｅ；｛ファイルタイプ｝
ＳｃｒａｐＴｙｐｅ
＝ＲｅｓＴｙｐｅ｛スクラップタイプ｝

ＳｃｒａｐＴｙｐｅデータタイプはメモリー中にデータのフォーマットを書き込む。普通、本発明により使われるスクラップタイプはＳｃｒａｐＭａｎａｇｅｒによって使われるスクラップタイプと同一である。しかしながら一つ注意しなければならない例外がある。本発明は一定形式のテキストを記述するため、新しいスクラップタイプである’ｓｔｘｔ’を定義している。’ｓｔｘｔ’フォーマットを持つスクラップは、そのテキストをその形式情報に付加することによって形成される。これは１スクラップをスクラップ翻訳拡張へと進ませるのに必要である。ＦｉｌｅＴｙｐｅのデータタイプはファイルのフォーマットを記述する。常時あるわけではないがよくあるのは、ＨＦＳカタログファイル（以下、ファイルのカタログタイプと呼ぶ）で維持されているように、ファイルのデータのフォーマットがファイルタイプを検査することによって同定し得ることである。しかし翻訳目的のためには、より具体的な同定方法を使うことが必要な場合がしばしばある。例えばデベロッパがアプリケーションを改定するが、そのアプリケーションが作り出す文書のために従来のファイルタイプをそのまま保持するような場合である。これはファイルデータフォーマットの具体的なバージョンを翻訳することはできるが新しいバージョンはできない翻訳拡張にとってトラブルの原因となり得る。同様にＭａｃｉｎｔｏｓｈコンピュータにファイルを作り出す一定のアプリケーション（例えば電子メールプログラムとかディスクマウンティングユーティリティ）は、省略時新ファイルタイプのような標準的ファイルタイプ（例えば’ＴＥＸＴとか’ＢＩＮＡ’）をよく使う。ここでもまた翻訳拡張は、ファイル中のデータの実際のフォーマットを別のフォーマットに翻訳するには、その前にファイル中のデータの実際のフォーマットに関するより多くの情報を必要としている。

ファイルカタログタイプをそのファイルのデータフォーマットに関する唯一の表示として使うことに関係するトラブルを回避するため、本発明は翻訳ファイルタイプを定義している。多くの場合にカタログファイルタイプは翻訳ファイルタイプとして十分である。しかし、本発明は翻訳拡張に具体的なファイルのカタログファイルタイプが本当に翻訳目的のために十分であるかどうかを調べるため、その具体的なファイルを検査する機会を常に与えている。もし拡張が、より特定的なフォーマットを同定することができたときは、その情報を本発明に戻すことになる。

翻訳拡張データの構造：
このセクションは翻訳拡張を記述するのに必要なデータ構造について説明する。ＦｉｌｅＴｙｐｅＳｐｅｃｉｆｉｃａｔｉｏｎｓはファイル翻訳リスト中の文書フォーマットについて記載している。ファイルタイプ明細［ｓｐｅｃｉｆｉｃａｔｉｏｎ］の域のある一定のものに関する解釈は、その明細がソース文書タイプのリスト中に起こっているか宛先文書タイプのリスト中に起こっているかによって異なる。ファイルタイプ明細はＦｉｌｅＴｙｐｅＳｐｅｃデータ構造によって定義されている。

ＴＹＰＥＦｉｌｅＴｙｐｅＳｐｅｃ＝
フォーマット：
ＦｉｌｅＴｙｐｅ；
ヒント：
Ｌｏｎｇｌｎｔ；
フラグ：
ＴｒａｎｓｌａｔｉｏｎＡｔｔｒｉｂｕｔｅｓ；
ｃａｔＩｎｆｏＴｙｐｅ；
ＯＳＴｙｐｅ；
ＣａｔＩｎｆｏＣｒｅａｔｏｒ；
ＯＳＴｙｐｅ；
ＥＮＤ；

フォーマット：
文書の翻訳ファイルのタイプ。本発明では翻訳をするためファイルのフォーマット表現の基準的方法としてこの域を使っている。

ヒント：貴方の翻訳拡張による使用のために用意されている４バイト値。
フラグ：翻訳をどのように制御するかにつき特定するビットフラグからなる４バイト値。この域は宛先ファイルのタイプのためにのみ使われる。フラグはあらゆるソースのファイルタイプ明細につき０にセットしておくべきである。現時点では２ビットが定義されているが、その他全てのビットも０にされていなければならない。
定数：
ｔａＤｓｔＤｏｃＮｅｅｄｓＲｅｓｏｕｒｃｅＦｏｒｋ＝１；
ｔａＤｓｔＩｓＡｐｐＴｒａｎｓｌａｔｉｏｎ＝２；
本発明は翻訳ルーチンのＤｏＴｒａｎｓｌａｔｅＦｉｌｅを呼び出す前に、宛先ファイルのデータフォークを作る。翻訳された文書もまたリソースフォークを要求するときは、定数ｔａＤｓｔＤｏｃＮｅｅｄｓＲｅｓｏｕｒｃｅＦｏｒｋによって特定されたビットがセットされる。

関連するアプリケーションがその特定されたファイルのタイプを所望のフォーマットに翻訳することができるので拡張が翻訳を行わないときは、定数ｔａＤｓｔＩｓＡｐｐＴｒａｎｓｌａｔｉｏｎによって特定されたビットがセットされる。

ｃａｔＩｎｆｏＴｙｐｅ：ボリュームのカタログファイル中に入れられているファイルのタイプ。
ｃａｔＩｎｆｏＣｒｅａｔｏｒ：ボリュームのカタログファイル中に入れられているファイルのクリエータ。ファイル翻訳リスト中のソース文書のタイプに関するリスト中に発生するファイルのタイプ明細において、ＭａｃｉｎｔｏｓｈＥａｓｙ０ｐｅｎは、翻訳進捗ダイヤログボックス内の’Ｆｒｏｍ’フォーマット明細に表示されたカインドストリングを決定するのにフォーマットとｃａｔＩｎｆｏＣｒｅａｔｏｒ域を使う。

ファイル翻訳リスト中の宛先文書のタイプに関するリスト中に発生するファイルのタイプ明細において、本発明は、翻訳進捗ダイヤログボックス内の’Ｔｏ’フォーマット明細に表示されたカインドストリングを決定するのにフォーマットとｃａｔＩｎｆｏＣｒｅａｔｏｒ域を使う。このフオーマットとｃａｔＩｎｆｏＣｒｅａｔｏｒ域はまた、ＤｏｃｕｍｅｎｔＣｏｎｖｅｒｔｅｒダイヤログボックス中に表示される情報を得るのにも使われる。しかし本発明は翻訳されるファイルのクリエータ及びファイルのタイプを決定するためにｃａｔＩｎｆｏＴｙｐｅ域とｃａｔＩｎｆｏＣｒｅａｔｏｒ域を使う。
ファイル翻訳リスト：ＦｉｌｅＴｒａｎｓｌａｔｉｏｎＬｉｓｔデータは、貴方の拡張機能がどのファイルフォーマットを、他のどのファイルフォーマットに翻訳することができるかを記述するように構成される。ＴｒａｎｓｌａｔｉｏｎＭａｎａｇｅｒは、その翻訳能力のマスターデータベースを作るため各翻訳システムから得ることができるファイル翻訳リストを使う。

ファイル翻訳リストは、そのリストの改変日を示す域と、上記２つの域に続くグループ数の総数［ｃｏｕｎｔ］とからなる。拡張によって作られる翻訳リストのサイズは、グループ数、ファイル明細レコードのサイズ、拡張が知っているファイルタイプ数の如何に従い可変である。

ｍｏｄＤａｔｅ：ファイル翻訳リストの作成日。拡張が外部のトランスレータを使っているときは、この域はこれらトランスレータを有するフォルダの改変日にセットされる。
ｇｒｏｕｐＣｏｕｎｔ：続く翻訳グループの数。
ｇｒｏｕｐｌＳｒｃＣｏｕｎｔ：拡張が読むことのできるグループ内にあるファイルのタイプの数。
ｇｒｏｕｐｌＳｒｃＥｎｔｒｙＳｉｚｅ：この域に続く列中のファイル明細レコードのサイズ。
一般にこの域をＳｉｚｅＯｆ（ＦｉｌｅＴｙｐｅＳｉｚｅ）にセットすることができる。
ｇｒｏｕｐｌＳｒｃＴｙｐｅｓ：ファイル明細レコードの列。貴方の拡張が翻訳の仕方を知っている各ファイルタイプのために、この列にファイル明細レコードを含ましめよ。
ｇｒｏｕｐｌＤｓｔＣｏｕｎｔ：拡張が書き込むことのできるグループ中のファイルのタイプの数。
ｇｒｏｕｐｌＤｓｔＥｎｔｒｙＳｉｚｅ：この域に続く列中のファイル明細レコードのサイズ。
一般に貴方はこの域をＳｉｚｅＯｆ（ＦｉＩｅＴｙｐｅＳｐｅｃ）にセットすることができる。
ｇｒｏｕｐｌＤｓｔＴｙｐｅｓ：ファイル明細レコード列。この域は拡張が翻訳されることができるファイルタイプの各々のために、この列中のファイル明細レコードを含むべきである。

翻訳リストの作成：
翻訳拡張は、要求されたときその翻訳能力につきＭａｃｉｎｔｏｓｈＥａｓｙＯｐｅｎに情報を与えることができるのでなければならない。これをするため、ファイル翻訳リストがＦｉｌｅＴｒａｎｓｌａｔｉｏｎＬｉｓｔレコードによって定義されるようにファイル翻訳リストはファイルされているＤｏＧｅｔＦｉｌｅＴｒａｎｓｌａｔｉｏｎＬｉｓｔ機能を定義する。拡張はどのタイプのファイルがどのような他のタイプに翻訳することができるかを示すために戻されたファイル翻訳リストを、本発明は使う。この情報に基づきファイル翻訳リストはその後、具体的な文書を同定し、またできるだけそれを翻訳するために拡張を呼び出すこともある。

ＦｉＩｅＴｒａｎｓｌａｔｉｏｎＬｉｓｔレコードは以下の構成を有している。

このレコードは改変日と続く翻訳グループ数の総数とを有している。ファイル翻訳リスト中の各翻訳グループは、それから拡張が翻訳することができるファイルタイプの集合（ｇｒｏｕｐｌＳｒｃＴｙｐｅｓ域）と、拡張がそれに翻訳することができるファイルタイプの集合（ｇｒｏｕｐｌＤｓｔＴｙｐｅｓ域）を特定する。１翻訳グループ内で拡張は、ソースタイプのものを宛先タイプのものに翻訳できるのでなければならない。

別の翻訳グループたちは、１グループ内にあるさまざまなカテゴリのアプリケーションたちに対応する。例えばワードプロセッシングアプリケーションたちを１グループに、スプレッドシートアプリケーションたちを別のグループに置く、というふうにすることができる。殆ど全てのトランスレータは特定のデータモデルを介して翻訳することで作業するので、殆どの場合ｇｒｏｕｐｌＳｒｃＣｏｕｎｔとｇｒｏｕｐｌＤｓｔＣｏｕｎｔは各々１より大である。こうした殆どの場合、ソースのファイルタイプと宛先のファイルタイプが一部重複したりぴったり一致したりすることが頻発する。

ファイルタイプのいずれか特定のグループ内で、ＦｉｌｅＴｙｐｅＳｐｅｃデータタイプで定義されているファイルタイプ明細を使って具体的な文書フォーマットを指定する。

ファイルタイプ明細には、ファイルタイプと、貴方の拡張による使用にとっておかれるヒントと、フラグ域と、もとのファイルタイプとクリエータとがある。

この拡張が翻訳できるファイルタイプのリストは永久に変わらないので、ＤｏＧｅｔＦｉｌｅＴｒａｎｓＩａｔｉｏｎＬｉｓｔはＭａｃｉｎｔｏｓｈＥａｓｙＯｐｅｎがそれを呼び出すその最初のときにファイル翻訳リストを満たす。そしてそれが呼び出される１回おきごとにＤｏＧｅｔＦｉｌｅＴｒａｎｓｌａｔｉｏｎＬｉｓｔは、それが今通過したそのリストを単純に戻す［ｐａｓｓｂａｃｋ］。

殆どの場合、翻訳拡張はファイルまたはスクラッブを実際に翻訳するのには外部のトランスレータに依存している。この場合もそうであるなら、トランスレータをある特定のフォルダ中に又はフォルダから移動させることにより、ユーザーが貴方の拡張によって使われることになるトランスレータを追加したり削除したりすることもできるのが普通である。この場合、ＤｏＧｅｔＦｉｌｅＴｒａｎｓｌａｔｉｏｎＬｉｓｔ機能はそのフォルダの改変日を読むことができ、その翻訳リストを再作成するか否かを決定するためｍｏｄＤａｔｅ域中に既に入力されている値と比較する。

ファィルの同定：
どのタイプから、またはどのタイプへ拡張が翻訳できるかファイルのタイプを本発明が知ったなら、その拡張が特定のファイルを翻訳することができるか否かを判断するため拡張を呼び出す。ある種の文書は翻訳目的のために十分特定されていないファイルのタイプを持つことがあるので、このような再チェックが必要である。例えば別のオペレーティングシステムから導入された文書は’ＴＥＸＴ’タイプのファイルを持っているかもしれない。さらに別の翻訳拡張は、そのファイルが実際にＳｕｒｆＷｒｉｔｅｒＰＣデータを有していて、特殊なフォーマット変換処理をするべきものであるか否かを判断することができるかもしれない。翻訳拡張が特殊な文書を同定するために呼び出されたときは、それは貴方の拡張のＤｏＩｄｅｎｔｉｆｙＦｉｌｅ機能を呼び出すことになる。

ある種の文書は単にそれらのファイルタイプとクリエータを調べることによって同定することができる。その他の文書（特にタイプ’ＴＥＸＴ’の文書）は、それら文書が拡張によって翻訳され得るかどうかを判断するためファイルをオープンし、それらの内容を調べることを要求する場合がある。もし拡張がその文書のタイプを認識できなければ、ＤｏＩｄｅｎｔｉｆｙＦｉｌｅはどのＴｙｐｅＥｒｒにも戻らない。そうでなければＤｏＩｄｅｎｔｉｆｙＦｉｌｅはｎｏＥｒｒへ戻り、ｄｏｃＫｉｎｄパラメータがその認識されたファイルタイプにセットされなければならない。ＤｏＩｄｅｎｔ１ｆｙＦｉｌｅ機能は’ＴＥＸＴをその文書がプレインな［ｐｌａｉｎ］フォーマット化されていないＡＳＣＩＩテキストからできていることを確実に知っていない限り、ファイルタイプとして戻してはならない。たとえ拡張がそれが翻訳できるものとして特定の文書を同定したとしても、本発明は実際にはその翻訳をするために拡張を呼び出すことはしないということに注意してもらいたい。

ファイルの翻訳：
もし翻訳拡張が、それが翻訳できるものとして文書を同定し、ユーザーが貴方の翻訳拡張を使うべく選択した場合は、その文書を翻訳するためその拡張が呼び出される。コンポーネントセレクタのディスパッチャはＤｏＴｒａｎｓｌａｔｅＦｉｌｅ機能を呼び出す。

文書の翻訳：
ＤｏＴｒａｎｓｌａｔｅＦｉｌｅルーチンが呼び出される時までには、ｄｓｔＤｏｃパラメータによって特定されたファイルが既に存在している。宛て先ファイルはデータフォークを持っており、またそれは、もし適当な宛て先ファイルタイプ明細内のフラグ域がｔａＤｓｔＤｏｃＮｅｅｄｓＲｅｓｏｕｒｃｅＦｏｒｋビットセットを持っていれば、リソースフォークも持っている。拡張は宛て先ファイルをオープンし、それを翻訳されたデータで満たす。

アプリケーションの翻訳拡張：
アアリケーションの翻訳拡張は拡張フォルダ中に置かれるファイルである。殆どのアプリケーションは一定数のファイルタイプしかオープンできず、したがってそれらリソースフォークたちの中に１オープンリソースを含ましめることによってこれらオープン可能なファイルタイプを宣言することができる。しかしアプリケーションによってはどのファイルをオープンできるかにつき動的に決定する必要がある。これはおそらく、これらアプリケーションが外部のフィルタを使うデータ変換能力を既に持っているからであろう。これらのアプリケーションにとってはオープンリソースだけが、どの種類のファイルをこれらアプリケーションがオープンできるのかを特定するのが不適当なものとなっている。

アプリケーションがオープン可能なファイルタイプのリストを動的に作成する好ましい方法は、ファイルタイプのリストを作成しファイルを同定することはできるが、実際の翻訳は全く行わないというそんなアプリケーションの翻訳拡張を提供することである。アプリケーションの翻訳拡張は本質的に、アプリケーションがオープンできるファイルのタイプの動的リストを作成するためだけに存在する。拡張が本発明に戻すファイル翻訳リスト中のソースリストは、これらのタイプの各々のためのファイルタイプ明細を含んでいなければならず、タイプの宛て先リストにとって、ファイル翻訳リストはそのフォーマットがある程度随意的でほかには使用されないファイルタイプを有している簡単なファイルタイプ明細を含んでいなければならない。この宛て先ファイルタイプを’ＶＯＩＤ’と呼ぶことにする。

すると貴方のアプリケーション中のオープンリソースは、ファイル翻訳リスト中の唯一の宛て先ファイルタイプ明細（つまり’ＶＯＩＤ’）の少なくともフォーマット域中に値を有する静的リストからなる。本発明に関係する限りの純粋の効果は、アプリケーションがタイプ’ＶＯＩＤ’の文書をオープンでき、別のファイルタイプをタイプ’ＶＯＩＤ’に翻訳できる、そんな翻訳拡張が存在することである。その結果、動的に作成されたファイルタイプのリストは、今ではアプリケーションと連携されているのである。

本発明のパーソナルコンピュータシステムのブロックダイヤグラムである。先行技術のトランスレータを示す。ファイルをオープンすることに失敗したことを表示している先行技術のディスプレイの１例である。先行技術のファイル情報のディスプレイ例を示す。本発明のディスプレイ例を示す。オープンオペレーションの先行技術のＭａｃｉｎｔｏｓｈのディスプレイ例を示す。本発明のＯｐｅｎメニューの１例である。ユーザーが本発明に従ってファイルをオープンしたとき動的に示されるディスプレイである。本発明に従い文書の翻訳の進行度合を示すインジケータである。本発明のＦｉｌｅメニューの１例である。本発明の文書翻訳ディスプレイの１例である。本発明に従い文書アイコンが引き出されプログラムアイコン上にドロッピングしている操作を示す。本発明に係るフローチャートの詳細である。本発明に係るフローチャートの詳細である。本発明に係るフローチャートの詳細である。本発明に係るフローチャートの詳細である。本発明に係るフローチャートの詳細である。本発明に係るフローチャートの詳細である。本発明に係るフローチャートの詳細である。本発明に係るフローチャートの詳細である。本発明に係るフローチャートの詳細である。本発明のブロックダイヤグラムである。

符号の説明

１２システムバス
１８アダプタ
２０磁気ディスク装置
２２ユーザーインターフェイスアダプタ
２４キーボード
２６マウス
２８スピーカ
３２マイクロホン
３４通信アダプタ
３６ディスプレイアダブタ
３８ディスプレイ装置

Claims

コンピュータシステムにおいて、当該コンピュータシステムにより現在アクセスすることができない第１のアプリケーションプログラムにより先に生成された当初の文書を処理する文書処理方法において、
判定手段が、当該当初の文書を作成した上記第１のアプリケーションプログラムが当該コンピュータシステムによりアクセスできないことを判定するステップと、
アプリケーションプログラム特定手段が、当該コンピュータシステムがアクセスすることができ、かつ、上記当初の文書を作成した上記第１のアプリケーションプログラムと異なり、さらに、上記当初の文書を変換した変換済み文書をアクセスすることができる第２のアプリケーションプログラムを特定するステップと、
選択手段が、上記第２のアプリケーションプログラムから１のアプリケーションプログラムを選択するステップと、
変換手段が、上記当初の文書を、上記選択手段により選択されたアプリケーションプログラムが許容可能なフォーマットに変換するステップとを有することを特徴とする文書処理方法。
変換プログラム特定手段が、上記当初の文書を上記第２のアプリケーションプログラム用の上記変換済み文書の変換することができる１または複数の変換プログラムを特定するステップをさらに有する請求項１記載の文書処理方法。
起動手段が、上記選択手段により選択された上記アプリケーションプログラムを上記変換済み文書を処理するために起動するステップをさらに有する請求項２記載の文書処理方法。
一覧表示手段が、上記第２のアプリケーションプログラムの一覧を、上記変換手段による変換の後に保存されるデータの量に応じた順番で表示するステップをさらに有する請求項２記載の文書処理方法。
フォーマット特定手段が、上記当初の文書のフォーマットを特定するステップをさらに有し、上記判定手段、および上記アプリケーションプログラム特定手段がそれぞれ対応する上記ステップを実行するために、上記フォーマット特定手段で特定されたフォーマットの情報を利用する請求項１記載の文書処理方法。
コンピュータシステムにより現在アクセスすることができない第１のアプリケーションプログラムにより先に生成された当初の文書を処理するために当該コンピュータシステムによって実現される文書処理装置において、
当該当初の文書を作成した上記第１のアプリケーションプログラムが当該コンピュータシステムによりアクセスできないことを判定する判定手段と、
当該コンピュータシステムがアクセスすることができ、かつ、上記当初の文書を作成した上記第１のアプリケーションプログラムと異なり、さらに、上記当初の文書を変換した変換済み文書をアクセスすることができる第２のアプリケーションプログラムを特定するアプリケーションプログラム特定手段と、
上記第２のアプリケーションプログラムから１のアプリケーションプログラムを選択する選択手段と、
上記当初の文書を、上記選択手段により選択されたアプリケーションプログラムが許容可能なフォーマットに変換する変換手段とを有することを特徴とする文書処理装置。