(57)【特許請求の範囲】
【請求項１】
バイナリ・エンコードの文書ファイル（バイナリファイル）からクリアテキスト・エンコード文書ファイル（テキストファイル）へ変換するファイルのフォーマツト変換装置であって、
バイナリファイルを入力するための手段、
該バイナリファイルのエレメントをテキストフォーマットへ変換するための手段、
該エレメントの該テキストフォーマットを第１のバッファに書き込むための手段、
該エレメントのためにアトリビュートが必要とされるか確認するための手段、
該バイナリファイルのサブエレメントが該エレメントのアトリビュートであるか、または該サブエレメントが該エレメントのアトリビュートであるかを判定するための手段、
該サブエレメントを該テキストフォーマットへ変換するための手段、
該サブエレメントが該エレメントのアトリビュートでないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該エレメントの該サブエレメントの該テキストフォーマットを第２のバッファに書き込むための手段、
該サブエレメントが該エレメントのアトリビュートでないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該必要とされるアトリビュートに出会うまで該バイナリファイルを処理するための手段、
該サブエレメントが該エレメントのアトリビュートではないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該必要とされるアトリビュートを該テキストフォーマットへ変換するための手段、
該サブエレメントが該エレメントのアトリビュートではないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むための手段、及び
該サブエレメントがアトリビュートであると判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該サブエレメントの該テキストフォーマットを該第１バッファに書き込むのための手段、
を具備してなるフォーマット変換装置。
【請求項２】
請求項１記載のフォーマット変換装置において、
該エレメントの該サブエレメントの該テキストフォーマットを該第２バッファに書き込むための手段は、該第１バッファを参照する該第２バッファに該エレメントの該サブエレメントの該テキストフォーマットを書き込み、
かつ
該フォーマット変換装置は、該サブエレメントが該エレメントのアトリビュートではないと判定された後、該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該第２バッファから逆向きに辿って該第１バッファを見つけるための手段、をさらに具備することを特徴とするフォーマット変換装置。
【請求項３】
請求項１記載のフォーマット変換装置において、該エレメントの該サブエレメントの該テキストフォーマットを該第２バッファに書き込むための手段は、該第１バッファを後方参照しかつ次のバッファを前方参照するダブルリンクリストであるところの該第２バッファに、該エレメントの該サブエレメントの該テキストフォーマットを書き込み、かつ
該フォーマット変換装置は、該サブエレメントが該エレメントのアトリビュートでないと判定された後、該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該ダブルリンクリストより逆向きに辿って該第１バッファを見つけるための手段をさらに具備することを特徴とするフォーマット変換装置。
【請求項４】
バイナリ・エンコードの文書ファイル（バイナリファイル）からクリアテキスト・エンコード文書ファイル（テキストファイル）へ変換するファイルのフォーマツト変換装置であって、
バイナリファイルを入力するための手段、
該バイナリファイルのエレメントをテキストフォーマットへ変換するための手段、
該エレメントの該テキストフォーマットを第１のバッファに書き込むための手段、
該エレメントの許容されるサブエレメントを記憶しているデータ構造を辿って調べることにより、該バイナリファイルの該エレメントのサブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが該エレメントの許容されないサブエレメントであるか判定するための手段、
該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時にエラーを表示するための手段、及び
該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時に、該バイナリファイルの後続部分を該テキストフォーマットへ変換するための手段、
を具備してなるフォーマット変換装置。
【請求項５】
請求項４記載のフォーマット変換装置において、該判定のための手段は、該エレメントの許容されるサブエレメントをそれぞれ記憶しているサブエレメントリンクリストデータ構造を辿って調べることにより、該エレメントの該サブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが許容されないサブエレメントであるか判定し、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つかるならば該サブエレメントは許容されると判定され、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つからなければ該サブエレメントは許容されないと判定される、ことを特徴とするフォーマット変換装置。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は文書のフォーマット変換に係り、特にバイナリ・エンコードの文書（binary  encoded  document）からクリアテキスト・エンコードの文書（cleartext  encoded  document）への変換に関する。本発明はまたさらに、バイナリ・エンコードの標準ページ記述言語文書（standard  Page  Description  Language  document）のクリアテキスト・エンコードの標準ページ記述言語文書への変換に関する。
【０００２】
なお、本出願は、米国特許出願第０８／１４７，６０３号（１９９３年１１月４日受理，”ＳＴＡＮＤＡＲＤ  ＰＡＧＥ  ＤＥＳＣＲＩＰＴＩＯＮ  ＬＡＮＧＵＡＧＥ  ＣＬＥＡＲＴＥＸＴ  ＳＴＲＵＣＴＵＲＥＧＥＮＥＲＡＴＯＲ”）、米国特許出願第０８／０６６，３８３号（１９９３年５月２１日受理，”  ＭＥＴＨＯＤ  ＡＮＤ  ＳＹＳＴＥＭ  ＦＯＲ  ＰＲＯＣＥＳＳＩＮＧ  ＭＩＸＥＤ  ＢＩＮＡＲＹ  ＬＥＮＧＴＨ  ＥＮＣＯＤＩＮＧＳＣＯＮＴＡＩＮＩＮＧ  ＤＥＦＩＮＩＴＥ  ＡＮＤ  ＩＮＤＥＦＩＮＩＴＥ  ＬＥＮＧＴＨ  ＦＯＲＭＡＴＳ  ”）及び米国特許出願第０８／００６，４１６号（１９９３年１月１９日，”  ＭＥＴＨＯＤ  ＡＮＤ  ＳＹＳＴＥＭ  ＴＯＲＥＣＯＧＮＩＺＥ  ＥＮＣＯＤＩＮＧ  ＴＹＰＥ  ＩＮ  ＤＯＣＵＭＥＮＴ  ＰＲＯＣＥＳＳＩＮＧ  ＬＡＮＧＵＡＧＥ”）の一部継続出願であり、上記３件の米国特許出願はそれぞれ米国特許出願第０７／９３１，８０８号（１９９２年８月１１日受理，”    Ａ  Ｍｅｔｈｏｄ    Ａｎｄ    Ｓｙｓｔｅｍ    ｔｏ  ＨａｎｄｌｅＤｉｃｔｉｏｎａｒｙ  Ｇｅｎｅｒａｔｉｏｎ  ａｎｄ  Ｃｏｎｔｅｘｔ  ＤＥｃｌａｒａｔｉｏｎ  ｉｎ  ａ  Ｄｏｃｕｍｅｎｔ  ＰｒｏｃｅｓｓｉｎｇＬａｎｇｕａｇｅ”）の一部継続出願であり、当該米国特許出願第０７／９３１，８０８号は米国特許出願第０７／８７６，６０１（１９９２年４月３０日受理，”  Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｔｏ  Ｍａｎａｇｅ  Ｐｉｃｔｕｒｅ  ａｎｄ  Ｐａｇｅｓｅｔ  ｆｏｒ  ＤｏｃｕｍｅｎｔＰｒｏｃｅｓｓｉｎｇ  ”  、米国特許出願第０７／８７６，２５１号（１９９２年４月３０日受理，”  Ｍｅｔｈｏｄ  ａｎｄ  Ｓｙｓｔｅｍ  ｔｏ  ｈａｎｄｌｅ  Ｉｎｃｌｕｓｉｏｎ  ｏｆ  Ｅｘｔｅｒｎａｌ  Ｆｉｌｅｓ  ｉｎｔｏａ  Ｄｏｃｕｍｅｎｔ  Ｐｒｏｃｅｓｓｉｎｇ  Ｌａｎｇｕａｇｅ  ”）及び米国特許出願第０７／７７８，５７８号（１９９１年１０月１７日受理，”  Ｓｙｓｔｅｍ    ａｎｄ    Ｍｅｔｈｏｄ    ｆｏｒ    ＤｏｃｕｍｅｎｔＰｒｏｃｅｓｓｉｎｇ”）の一部継続出願であり、上記各特許出願は引用により本明細書に組み込まれる。
【０００３】
【従来の技術】
一つの標準化ページ記述言語（ＳＰＤＬ）が提案され、国際標準化機構（ＩＳＯ）で国際規格として開発中である。この提案は、本願発明者の一人もその関与者であるが、現在、ＩＳＯの１セクションに草案として提出されている。この草案はＩＳＯ／ＩＥＣ  ＤＩＳ  １０１８０  ”Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  ＴｅｘｔーＣｏｍｍｕｎｉｃａｔｉｏｎ−Ｓｔａｎｄａｒｄ  Ｐａｇｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ”として知られ、ニューヨークの米国規格協会（ＡＮＳＩ）で入手可能であるが、ここに引用することによっ本明細書に組み込まれる。
【０００４】
標準ページ記述言語（ＳＰＤＬ）は階層的に構造化されたページ記述言語である。この構造化された階層によれば、文書の一部分の印刷をする場合に、当該部分に影響する可能性のあるフォーマット用コマンド（ｆｏｒｍａｔｔｉｎｇ  ｃｏｍｍａｎｄ）を文書全体にわたって調べる必要がなくなる。所望の部分を印刷するのに、その刷したい部分より階層が上の文書の部分しか処理する必要がない。
【０００５】
ＳＰＤＬのもう一つの利点は、ＳＰＤＬがＩＳＯ  ８８７９：１９８６  に定義された標準一般化マークアップ言語（Ｓｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｚｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ，ＳＧＭＬ）に準拠していることである。このことにより、文書構造を記述し包括的に結び付けることが可能になる。複数のファイルは、ＳＧＭＬで結びつけられたならば、変換ユーティリティを用いる事なく、かつ構造フォーマットを損なうことなく、あるプラットフォームから他のプラットフォームへ継ぎ目なく移ることができる。
【０００６】
ＳＰＤＬは、ＡＳＮ．１に述べられているベーシック・エンコーディング規則（Ｂａｓｉｃ  Ｅｎｃｏｄｉｎｇ  Ｒｕｌｅｓ）に準拠している。ＡＳＮ．１に関する完全な説明は、Ｄｏｕｇｌａｓ  Ｓｔｅｅｄｍａｎ著”ＡＳＮ．１，Ｔｈｅ  Ｔｕｔｏｒｉａｌ  ａｎｄ  Ｒｅｆｅｒｅｎｃｅ”（１９９０年）に見られるが、この文献は引用により本明細書に組み込まれる。
【０００７】
クリアテキスト（ｃｌｅａｒｔｅｘｔ）言語は、人間が読むことのできるコンピュータ言語の一種である。非クリアテキスト言語の一例をあげるならば、文書のバイナリ・エンコーディング（ｂｉｎａｒｙ  ｅｎｃｏｄｉｎｇ）であろう。２進もしくは１６進表現の文書を見ても、人間には文書内容を容易には理解できないからである。バイナリ・エンコードされた文書の一つの主要な利点として、２進で表現された文書は同等のクリアテキスト形式の文書に比べて必要とする記憶スペースが非常に少ない事がある。このことがバイナリ文書の記憶スペースの減少及び伝送時間の高速化を可能にする。しかしクリアテキスト・エンコードの文書に比べ、特殊なソフトウエアを用いないとバイナリ・エンコードの文書の編集及び理解が難しい。
【０００８】
したがって、前述のように文書のクリアテキスト・エンコーディングにもバイナリ・エンコーディングにも長所と短所があるので、文書を一方のフォーマットから他方のフォーマットへ変換したいことがあろう。
【０００９】
【発明が解決しようとする課題】
本発明の一つの目的は、バイナリ・エンコードの文書をクリアテキスト・エンコードの文書へ変換する手段を提供することである。
【００１０】
本発明のもう一つの目的は、バイナリ・エンコードの標準ページ記述言語文書を等価なクリアテキスト・エンコードの標準ページ記述言語文書へ変換する手段を提供することである。
【００１１】
バイナリＳＰＤＬ文書で要求されるフォーマットのゆえに、バイナリ・エンコード文書をクリアテキスト・エンコード文書に変換するために単純なルックアップ（ｌｏｏｋ−ｕｐ）プロシージャを実行することはできない。様々なバイナリ・シンボル（ｂｉｎａｒｙ  ｓｙｍｂｏｌ）の表わす内容は、ＳＰＤＬ文書中のバイナリ・シンボルのロケーションに依存して決まる。
【００１２】
本発明が扱わなければならないもう一つの課題は、バイナリ・エンコードされたプロセスそれぞれの長さを管理することである。ＳＰＤＬは階層的に構造化されたページ記述言語であり、各階層レベルの始まりは、該レベルが固定長フォーマットまたは不定長フォーマットのいずれでエンコードされるかを示し、また、固定長バイナリ・エンコーディングがある時には、エンコーディングの長さを示す。
【００１３】
本発明が扱う別の課題は、バイナリ・エンコーディングにおける特定エレメントの順序がクリアテキスト・エンコーディングでは変更されなければならないという事である。したがってクリアテキストＳＰＤＬフォーマットにおいて要求されるエンコーディング順序を知る必要がある。
【００１４】
【課題を解決するための手段】
前記目的もしくは課題を解決するための手段を、やや具体的に説明すれば、本発明は、バイナリからクリアテキストへの変換を行なうために、まず最初に、アプリケーション・テーブル（ａｐｐｌｉｃａｔｉｏｎ  ｔａｂｌｅ）よりＡＳＮ．１タグを検索し、このバイナリ・タグ（ｂｉｎａｒｙ  ｔａｇ）のクリアテキスト名を決定する。クリアテキスト名が決まったならば、当該エレメントに関するそれ以上の情報をエレメント・テーブル（ｅｌｅｍｅｎｔ  ｔａｂｌｅ）より検索できる。エレメント・テーブルのエレメントはサブエレメント（ｓｕｂ−ｅｌｅｍｅｎｔ）を持つことができ、サブエレメントはサブエレメント・リンクリスト（ｓｕｂ−ｅｌｅｍｅｎｔ  ｌｉｎｋｅｄ  ｌｉｓｔ）を指すエレメント・テーブル中のポインタによって参照される。
【００１５】
エレメントに関し必要な情報が得られた後、変換プロセスで用いられる情報の管理のための各種フィールドを持つエレメント・スタックに、一つのエントリーがプッシュされる。このエレメント・スタックは、バイナリ・コーディングの固定長フォーマット及び不定長フォーマットの処理に非常に有益である。
【００１６】
バイナリ・エレメントが変換されている時に、アトリビュート（ａｔｔｒｉｂｕｔｅ）値がアトリビュート・バッファに格納される。出力ファイルの生成前において、ファイルが変換されている時に変換された各クリアテキスト行がダブル・リンクリストデータ構造（ｄｏｕｂｌｅ  ｌｉｎｋｅｄ  ｌｉｓｔ  ｄａｔａ  ｓｔｒｕｃｔｕｒｅ）に書き込まれる。ファイル全体が変換されてダブル・リンクリストデータ構造に書き込まれると、ダブル・リンクリストデータ構造の情報が出力ファイルへ書き出される。
【００１７】
【作用】
ダブル・リンクリストデータ構造は、不適切な（ｏｕｔ  ｏｆ  ｏｒｄｅｒ）アトリビュートの処理のために有効に利用される。エレメントはアトリビュートとサブエレメントを含むことができる。通常、クリアテキストＳＰＤＬの場合、アトリビュートはエレメントの直後、及び、あらゆるサブエレメントの出現前に、出現しなければならない。しかし、バイナリＳＰＤＬエンコーディングにおいては、サブエレメントがアトリビュートの前に出現することがある。
【００１８】
本発明は、アトリビュート・バッファとダブル・リンクリストデータ構造を用いて、上述の不適切なアトリビュートの問題を解決する。本発明において、エレメントより階層的に下に現われるオブジェクトはサブエレメントと総称される。あるエレメントに対するサブエレメントは、そのエレメントのアトリビュートであるか、あるいは実際のサブエレメントである。アトリビュートを適切ならしめるためには、それらアトリビュートはエレメントの直後に出現するべきである。アトリビュートの全てが出現する以前にエレメントの後にサブエレメントが出現したならば、その後のアトリビュートは不適切なアトリビュートであると考えられる。ダブル・リンクリストデータ構造はエレメントのアトリビュート情報を格納するためのエントリーを有する。あるエレメントの下に、アトリビュートの全部が処理される前にノンアトリビュート（ｎｏｎ−ａｔｔｒｉｂｕｔｅ）・サブエレメントが出現した場合には、親（ｐａｒｅｎｔ）エレメントのダブル・リンクリストデータ構造によって新しいダブル・リンクリストデータ構造が参照される。親エレメントのサブエレメントの処理後に、不適切なアトリビュートが出現することになる。最も最近に生成されたダブル・リンクリストデータ構造より、親エレメントのダブル・リンクリストデータ構造に到達するまで、ダブル・リンクリストデータ構造が逆向きにトレースされる。そして、そのアトリビュート・サブエレメントのアトリビュート情報が親エレメントのダブル・リンクリストデータ構造のアトリビュート・エントリーに書き込まれる。このようにして、不適切アトリビュートが効率的に処理される。
【００１９】
【実施例】
以下、添付図面を参照して本発明の一実施例を説明するが、複数の図面にわたって同一の参照数字は同一部または対応部を示す。
【００２０】
添付図面中の図１を参照するに、バイナリ・エンコード文書に関する固定長及び不定長フォーマットのネスティングの一例が示されている。図１は、処理されるべき一つのデータストリームもしくは文書データストリームを示すと考えることができる。行１〜行１６及び行１７〜行１９は、最高階層レベルの２つのコーディングであるが、行１〜行１６内にはネストされたコーディングがある。行１〜行１６のエンコーディングのコンテント（ｃｏｎｔｅｎｔ）は４００バイトの固定長である。これら４００バイト内で、まず行４〜行１３に一つの不定長構造がある。この行４〜行１３の不定長コンテントは２４８バイト及び４０バイトの固定長コーディングである。行４〜行１３にある４００バイトのコンテントからなる不定長エンコーディングに加えて、１００バイトのコンテントを含む行１４〜行１６の固定長エンコーディングがある。図１の行１７〜１９は２５０バイトの長さの固定長エンコーディングを含む。
【００２１】
”固定長フォーマットと不定長フォーマットのネスティング（ｎｅｓｔｉｎｇ）”なるタームは、ある不定長エンコーディングが、そのコンテントとして、一つの不定長エンコーディングと一つの固定長エンコーディング、すなわち、これら二つのエンコーディングの組合せを持つことができる、ということを意味する。このことは、その固定長エンコーディングが、その不定長エンコーディングが終わる前に始まることを意味する。上記タームは不定長エンコーディングを含んだ固定長エンコーディングにも同様に当てはまる。すなわち、不定長エンコーディングは固定長エンコーディングが終わる前に始まることができる。さらに、一つのエンコーディング内に、任意数の任意タイプのエンコーディングをネスト可能である。
【００２２】
図１に示したようなエンコーディングが処理されている時に、ネストされた固定長エンコーディング及び不定長エンコーディングのハンドリングに関して一つの問題が生じる。図１に示した例は単純なケースである。固定長・不定長フォーマットのネスティングがずっと深くなることがあり得る。したがって、処理システムは、多くの不定長フォーマット及び固定長フォーマットの階層レベルを管理せねばならないかもしれない。
【００２３】
不定長エンコーディングの終わりを確認するには、ＡＳＮ．１エンコーディングで使用される行１３の０００Ｈのような、不定長エンコーディングの終わりフラグもしくはマーカーを捜すだけでは不十分である。というのは、行９及び行１２にあるコンテントが０００Ｈをデータ、イメージデータとして含むことがあるからである。したがって、本発明は、不定長エンコーディングの終わり０００Ｈを、ネストされた固定長エンコーディングの処理が済んだ後に捜す。不定長エンコーディングの終わりは、固定長フォーマットのネストされたルーチンの後に来る筈であるからである。
【００２４】
さて、ＡＳＮ．１に要求されるエンコーディングであるが、図２はＩＳＯ／ＩＥＣ８８２４に定義されたベーシック・エンコーディング規則に従ったバイナリ・エンコーディングの構造を示している。このエンコーディングは１個以上のアイデンティファイア・オクテット（ｉｄｅｎｔｉｆｉｅｒ  ｏｃｔｅｔ）から始まり、次に１個以上のレングス・オクテット（ｌｅｎｇｔｈ  ｏｃｔｅｔ）が来て、これにコンテント・オクテット（ｃｏｎｔｅｎｔｓ  ｏｃｔｅｔ）が続く。
【００２５】
ＩＳＯ／ＩＥＣ  ８８２４により定義されたアイデンティファイア・オクテットの構造が図３に示されている。このアイディンティファイア・オクテットの初めの２ビットはエンコーディングのクラスを表わす。図３に示されたビット８及びビット７で定義される可能なエンコーディング・クラスは、ユニバーサル、アプリケーション、コンテント・スペシフィック（ｃｏｎｔｅｎｔ−ｓｐｅｃｉｆｉｃ）、及びプライベートの４クラスである。ＡＳＮ．１によるエンコーディングの完全な説明は、ＩＳＯ／ＩＥＣ  ８８２４及びＩＳＯ／ＩＥＣ  ８８２５（いずれも引用によって本明細書に組み込まれる）に見られる。しかし、本発明の作用を理解するのにエンコーディングの様々なクラスについての理解は必要ではないので、説明の簡略のため、これ以上の詳細については述べない。
【００２６】
図３に示したビット６は、エンコーディングがプリミティブ（ｐｒｉｍｉｔｉｖｅ）であるか複合（ｃｏｎｓｔｒｕｃｔｅｄ）であるかを決定する。プリミティブとは他のエンコーディングが当該エンコーディング内にネストされていないことを意味し、複合とは他のエンコーディングが当該エンコーディング内にネストされていることを意味する。図３に示されているビット５〜１はタグの番号に関するものである。タグの番号が３１を超えるときには、ビット５〜１は同番号を表現するには足りないので、後続のアイデンティファィア・オクテットでタグの番号をエンコードする。様々なタグ番号の完全な理解は、本発明の作用を理解するためには必要ではないので簡略のため省略する。
【００２７】
アイデンティファイア・オクテット及びレングス・オクテットはプリアンブル（ｐｒｅａｍｂｌｅ）情報と考えることができ、コンテント・オクテットはコンテント情報と考えることができる。アイデンティファイア情報がテキストフォーマットへ変換されたときに得られるテキスト情報は、クリアテキスト開始タグにコンテント情報のクリアテキスト表現が続いたもので、必要ならば、もしくは要求されるならば、その後にクリアテキスト終了タグが続く。
【００２８】
当業者にとって以上の説明でバイナリＳＰＤＬエンコーディングの基本を理解するのに十分であると考えられる。しかし、バイナリ・エンコーディングの処理に関するより詳細かつ完全な説明を、係属中の米国特許出願第０８／０６６，３８３号（”ＭＥＴＨＯＤ  ＡＮＤ  ＳＹＳＴＥＭ  ＦＯＲ  ＰＲＯＣＥＳＳＩＮＧ  ＭＩＸＥＤ  ＢＩＮＡＲＹ  ＬＥＮＧＴＨ  ＥＮＣＯＤＩＮＧ  ＣＯＮＴＡＩＮＩＮＧ  ＤＥＦＩＮＩＴＥ  ＡＮＤ  ＩＮＤＥＦＩＮＩＴＥ  ＬＥＮＧＴＨ  ＦＯＲＭＡＴＳ”）に見ることができる。本出願の主要な関心事及び処理はファイルをバイナリ表現からクリアテキスト表現へ変換することであるが、上記関連出願に述べられている処理は主としてプリンタ、ＣＲＴ等による文書の出力（ｐｒｅｓｅｎｔａｔｉｏｎ）に関係するものである。
【００２９】
本発明は各種ＳＰＤＬエレメントの情報を管理するためにエレメント・テーブルとサブエレメント・リンクリストを用いる。ＳＰＤＬは階層的に構造化されたページ記述言語であるので、エレメント・テーブル及びサブエレメント・リンクリストの情報を生成するにはＳＰＤＬ内の階層構造を決定する必要があった。
【００３０】
ＳＰＤＬの階層の秩序を決定するため、本願発明者は、規格草案に含まれているＳＰＤＬエレメントの記述を使用し、図４に示すようなＳＰＤＬエレメント状態遷移ダイヤグラムを作成した。図４は、ＳＰＤＬ構造エレメントをツリー構造を用いて図示しており、また、一つのエレメントから出て同じエレメントに戻るラベル付けされたアトリビュート用円弧矢印を示すことにより、様々なＳＰＤＬエレメントに対するアトリビュートを図示している。  この状態遷移ダイヤグラムから、本願発明者は本発明に用いられるエレメント・テーブルとサブエレメント・リンクリストを生成することができた。
【００３１】
状態遷移ダイヤグラムの最初のエレメントはＳＰＤＬ１５２である。ＳＰＤＬエレメントの下に出現できる２つの可能なエレメントがある。すなわち、文書エレメント１５４とリソース定義（ｒｅｓｏｕｒｃｅ  ｄｅｆｉｎｉｔｉｏｎ）エレメント１５６である。このリソース定義エレメント１５６はリソース・アトリビュート、ＳＰＤＬＩＤアトリビュート及びファンクション（ｆｕｎｃｔｉｏｎ）アトリビュートというアトリビュートを持つとして示されている。アトリビュートは固定値を持つことも、ユーザによって入力された値を持つこともある。
【００３２】
図４において、特定の階層構造における終端エレメントつまり最も下のエレメントはアスタリスクが付けられており、また、前に定義済みのエレメントはプラス記号が付けられている。特定の階層構造の最低レベルには終端エレメントが存在可能であるが、他のエレメントは存在できない。図４に示したＳＰＤＬエレメント状態遷移ダイヤグラムは完全ではなく、簡略化のためにＳＰＤＬ構造エレメントの一部を省略している。例えば、リソース・スペシフィケーション（ｓｐｅｃｉｆｉｃａｔｉｏｎ）１６４、外部宣言１７２、情報宣言１７４、リソース定義１７６、リソース宣言１７８、ＤＰＩ宣言１８０、コンテキスト（ｃｐｎｔｅｘｔ）宣言１８２、セットアップ・プロシージャ（ｓｅｔ−ｕｐ  ｐｒｏｃｅｄｕｒｅｓ）１８６の下に来る構造エレメントがある。
【００３３】
文書構造エレメント１５４の下にページセット（ｐａｇｅｓｅｔ）エレメント１５８とピクチャー（ｐｉｃｔｕｒｅ）エレメント１６０がある。ページセット１５８の下にページセット・ボディ（ｂｏｄｙ）１６６及びプロローグ（ｐｒｏｌｏｇｕｅ）１７２がある。図４に示されるように、ピクチャー・エレメント１６０はページセット・ボディ１６６の下に出現することも可能である。ピクチャー・エレメント１６０は、コンテント・タイプのアトリビュートとＳＰＤＬ  ＩＤとを有する。ピクチャーエレメント１６０の下に出現可能なＳＰＤＬエレメントはプロローグ１７２とピクチャー・ボディ１６８である。トークン・シーケンス（ｔｏｋｅｎ  ｓｅｑｕｅｎｃｅ）１７０がピクチャー・ボディ１６８の下に出現可能である。プロローグ１７２の下に出現する辞書ジェネレータ（ｄｉｃｔｉｏｎａｒｙ  ｇｅｎｅｒａｔｏｒ）１８４はその下に、サイズのアトリビュートを持つ辞書ジェネレータ・エレメント１８８が出現可能である。辞書１８８の下に出現可能なＳＰＤＬエレメントは辞書ＩＤ１９０、ネーム（ｎａｍｅ）１９４及びトークン・シーケンス１９２である。
【００３４】
図５は、典型的なバイナリＳＰＤＬ文書を１６進表現で示している。図５に示された文書と等価なクリアテキスト文書が図６に示されている。本発明が用いられた場合、図５に示した文書を入力して図６に示した形式へ変換させることができる。図５及び図６に示した文書に対する本発明の作用の説明を行なった後のほうが、図５及び図６の詳細を理解しやすいであろう。
【００３５】
図７は、図５に示された文書が図６に示された文書にどのように対応するかを説明するものである。図７より分かるように、６１はエレメントたるページセットを表わしている。６１の後の５９は、このページセットの長さ（ｌｅｎｇｔｈ）を表わしている。このページセット内にＳＰＤＬ  ＩＤがＡＳＮ．１タグ０６で表わされている。このＳＰＤＬ  ＩＤの長さは４である。実際のＳＰＤＬ  ＩＤである”ＩＳＯ／ＩＥＤ  １０１８０／／ＳＰＤＬ”は”２８  ＣＦ  ４４  ００”によって表わされている。
【００３６】
次に、図７において、ＡＳＮ．１タグ４４はコメントに対応することが分かる。このコメントの長さは１Ｆである。このコメントの内容は”ＳＰＤＬ  ＩＤ＝ＰｕｂｌｉｃＯｂｊｅｃｔ  ＩＤ  ｖａｌｕｅ  ”である。次に、Ａ１はページセット・ボディとも呼ばれるところのｐｓｂｏｄｙを表わすことが分かる。図７の残りの部分も同様に理解することができる。したがって、簡略化のために図７における対応関係の完全な説明は省略する。
【００３７】
図８は本発明で使用されるアプリケーション・テーブルを示す。このアプリケーション・テーブルはＡＳＮ．１タグ（アイデンティファイア・オクテット）のバイト値と、それに対応したクリアテキストのアプリケーション・エレメントのネーム（ｎａｍｅ）を記憶している。例えば、ＡＳＮ．１タグの４０Ｈはクリアテキスト・エレメント”ｎａｍｅ”に対応する。また、ＡＳＮ．１タグの６１Ｈ及び６２Ｈは、ページセット（ｐａｇｅｓｅｔ）及びピクチャー（ｐｉｃｔｕｒｅ）なるエレメントにそれぞれ対応することが分かる。当然、本発明で使用される完全なアプリケーション・テーブルは、ＳＰＤＬ構造エレメントそれぞれのための既知のＡＳＮ．１タグと既知のエレメント・ネームを記憶することになる。ＡＳＮ．１タグは公知文献で容易に知ることができるので、ＡＳＮ．１タグそれぞれの完全なリストは提示しない。
【００３８】
図９は、本発明で使用されるＳＰＤＬエレメント・テーブルを示す。このエレメント・テーブルの最初のカラムはエレメント・ネームもしくは同エレメントのクリアテキスト・タグである。次の２つのカラムは、開始タグ及び終了タグが省略可能であるか必要とされるかを示す。ハイフンはタグが必要であることを示し、０はタグがオプショナルであることを示す。なお、ここに開示される本発明の実施例においては、各エレメントの開始タグ及び終了タグが常に用いられる。勿論、エレメント・テーブルの開始タグ・エントリー及び終了タグ・エントリーを使用し、それらがオプショナルの時にタグを省略することも可能である。
【００３９】
エレメント・テーブルの４番目のカラムは、エレメントがプリミティブであるか複合（ｃｏｎｓｔｒｕｃｔｅｄ）であるかを示す。プリミティブはコンテント中に他のエンコーディングがネストされていないことを意味し、複合はコンテント中に他のエンコーディングがネストされていることを意味する。本発明は４番目のカラムを格別に参照することはないが、このプリミティブ／複合情報は他の関連発明で使用されるかのしれないので当該エレメント・テーブルに含まれている。
【００４０】
エレメント・テーブルの５番目のカラムは、エレメント宣言を記憶する。このエレメント宣言は、エレメントの特性の記述である。より具体的には、エレメント宣言は、エレメントのエレメント・ネームについての特性及び従属構造エレメント（それがあるならば）の扱いについての特性に関係する。例えば、ＤＯＣＴＹＰＥ、ＮＯ  ＤＥＣＬＡＲＡＴＩＯＮ、ＯＣＴＥＴ  ＳＴＲＩＮＧ、ＰＲＩＮＴＡＢＬＥ  ＳＴＲＩＮＧ  は第１のタイプのエレメント宣言である。ＣＨＯＩＣＥ、ＳＥＱＵＥＮＣＥ、ＳＥＱＵＥＮＣＥ  ＯＦ  ＣＨＯＩＣＥ  は第２のタイプのエレメント宣言である。ＤＯＣＴＹＰＥ  宣言は特殊タイプの宣言で、ＤＯＣＴＹＰＥ構造エレメントのためにだけ使用される。ＣＨＯＩＣＥ  宣言はエレメント下のサブエレメントの任意の一つをユーザが選択できることを示す。ＳＥＱＵＥＮＣＥ  宣言はエレメントの下に出現するサブエレメントは特定の順番で出現しなければならず、この順番は変更できないことを示す。
【００４１】
ＳＥＱＵＥＮＣＥ  ＯＦ  ＣＨＯＩＣＥ  宣言はＣＨＯＩＣＥ  宣言を繰り返すことにより、２つ以上の従属構造エレメントを選択させる。ＮＯ  ＤＥＣＬＡＲＡＴＩＯＮ  宣言はエレメントが従属構造エレメントを１つしか持たないことを意味する。
【００４２】
ＯＣＴＥＴ  ＳＴＲＩＮＧ  宣言は、エレメントが８ビット・バイトの文字ストリングであることを示す。ＰＲＩＮＴＡＢＬＥ  ＳＴＲＩＮＧ  宣言は、エレメントが印刷可能（ｐｒｉｎｔａｂｌｅ）ストリングであることを示す。
【００４３】
宣言が暗黙的である時、宣言は下に出現するタグに基づいて決定されるから、明示的に記述される必要がないことを意味する。この特徴の詳細は、ＡＳＮ．１等のＳＰＤＬで用いられるエンキコーディングに関する公知文献で知ることができるので、簡略化のため割愛する。
【００４４】
他のＳＰＤＬ文書タイプで他の宣言が用いられるが、これら宣言の詳細は説明の簡略化のため省略する。それらの詳細は、ＳＰＤＬに関する公知文献で知ることができる。本発明は、バイナリＳＰＤＬ文書のシンタックスがＳＰＤＬエンコーディング条件に違反しないようにするためにエレメント宣言を使用することができる。
【００４５】
エレメント・テーブルの６番目のカラムは、エレメントのアトリビュート数を示す。アトリビュートはエレメントの様々な特徴を記述するが、エレメントに対する固有のアトリビュートはサブエレメント・リンクリスト中に見つかる。
【００４６】
エレメント・テーブルの７番目のカラムは、エレメントのサブエレメント数を示す。このサブエレメント数はエレメントの下に出現可能な様々なサブエレメントの個数を示す。エレメント・テーブルの最後のカラムは、エレメントの下に出現可能なサブエレメントに関する情報を記憶しているサブエレメント・リンクリストデータ構造へのポインタである。
【００４７】
図１０は、図９に示したエレメント・テーブルのいずれかのポインタに対応するポインタ２０２により指されるサブエレメント・リンクリストデータ構造２００を示す。このサブエレメント・リンクリストデータ構造２００の最初のエントリー２０４はＡＳＮ．１タグであり、このタグはサブエレメントのバイナリ表現である。サブエレメント・リンクリストデータ構造２００のエントリー２０６はサブエレメント宣言で、エレメント・テーブルに関して述べたエレメント宣言と同様の宣言情報を記憶する。
【００４８】
サブエレメント・リンクリストデータ構造２００のエントリー２０８は、ＡＳＮ．１タグ２０４に対応したクリアテキスト・サブエレメントネームを記憶する。
【００４９】
エントリー２１０はサブエレメント・タイプを記憶する。可能なサブエレメントのタイプは、アトリビュート、オプショナル、デフォルト、またはターミネーティング（ｔｅｒｍｉｎａｔｉｎｇ）であり、これら４つのタイプの組合せも許される。本発明を実施する場合、サブエレメントのタイプは４タイプなら４ビットを用いて表現される。先に述べたサブエレメントの４タイプのいずれにも合致しないときには、サブエレメント・タイプを空白にすることも可能である。
【００５０】
フィールド２１２はサブエレメントのシーケンス番号を記憶しており、このシーケンス番号はサブエレメント・リンクリストデータ構造の番号である。例えば、あるエレメントに対する最初のサブエレメントはシーケンス番号１を有し、あるサブエレメント（２番目のサブエレメント）の最初のリンクリストデータ構造により指されるリンクリストデータ構造はシーケンス番号２を有する。
【００５１】
サブエレメント・リンクリストデータ構造の最後のフィールド２１４は、次のサブエレメント・リンクリストデータ構造へのポインタである。あるエレメントが、その下に出現する多数の様々なサブエレメントを階層構造中に持っている場合、各サブエレメントはそれ自体のリンクリストデータ構造を有する。これらのサブエレメント・リンクリストデータ構造は、あるエレメントの後続サブエレメント・リンクリストデータ構造を指すポインタ２１４によって相互にリンクされる。最後のサブエレメント・リンクリストデータ構造はヌルを指す。
【００５２】
図１１は、ページセットエレメントのためのサブエレメント・リンクリストデータ構造２３０，２４０，２５０を示す。最初のサブエレメントのためのＡＳＮ．１タグは０６で、これは  ＳＰＤＬ  ＩＤ  エレメントに対応する。  ＳＰＤＬ  ＩＤ  に対しては宣言がないので、  ＳＰＤＬ  ＩＤ  はアトリビュートである。この  ＳＰＤＬ  ＩＤ  は、最初のサブエレメントであるので、２番目のサブエレメントであるプロローグを指す。このプロローグ・サブエレメント・リンクリストデータ構造は、  ＰＳＢＯＤＹ  サブエレメント・リンクリストデータ構造２５０を指す。
【００５３】
図１２に示すピクチャーエレメント、図１３に示す  ＰＳＢＯＤＹ  エレメント、及び図１４に示す  ＰＩＣＢＯＤＹ  エレメントのためのサブエレメント・リンクリストデータ構造のフィールドは、ページセット・エレメントに関して述べたリンクリストデータ構造のフィールドと同じように記述することができる。
【００５４】
本明細書の作成時点では、ＳＰＤＬ規格は草案段階で未だ完成していない。将来、エレメントまたはサブエレメント宣言がシーケンスである時に使用される”フラグ”エントリーをサブエレメント・リンクリストデータ構造に追加する必要があるかもしれない。しかし、現時点では必要でないので、このフラグは図示したサブエレメント・リンクリストデータ構造には含まれていない。
【００５５】
図１５はバイナリ・ファイルをクリアテキストＳＰＤＬファイルに変換するプロセス中で本発明により使用されるエレメント・スタック３４０を示す。エレメント・スタック３４０のフィールド３４２は、処理されているエレメントのクリアテキスト表現であるところのエレメント・ネームを記憶している。フィールド３４４はエレメントの宣言である。フィールド３４６は、エレメントのアトリビュートを処理するために使用される。エレメントの各アトリビュートの処理後、当該エレメントの処理されたアトリビュートを管理するため、フィールド３４６は１だけデクリメントされる。フィールド３４８は、文書の階層レベルそれぞれのレベル番号を管理するために使用され、また、クリアテキストＳＰＤＬファイルにおける字下げ（ｉｎｄｅｎｔａｔｉｏｎ）レベルを管理するために用いられる。
【００５６】
ＩＮＤＥＦ  フラグ３５０及びエレメント・レングス（ＥＬＥＭＥＮＴ  ＬＥＮＧＴＨ）フィールド３５２は、バイナリ・エレメントの長さを管理するために使用される。ＩＮＤＥＦ  フラグ３５０内の”１”はバイナリ・エレメントが不定長フォーマットであることを示す。エレメント・レングスフィールド３５２はバイナリ・エンコーディングが処理されている時にそのバイトのカウントのために使用される。ポインタ３５４は、図１１乃至図１４に示したリンクリストと類似のサブエレメント・リンクリストを指す。
【００５７】
図１５に示したエレメント・スタック３４０が持っている  ｉｎｄｅｆ  フラグとエレメント・レングスフィールドは、係属中の米国特許出願第０８／０６６，３８３号（１９９３年５月２１日受理、”ＭＥＴＨＯＤ  ＡＮＤ  ＳＹＳＴＥＭ  ＦＯＲ  ＰＲＯＣＥＳＳＩＮＧＭＩＸＥＤ  ＢＩＮＡＲＹ  ＬＥＮＧＴＨ  ＥＮＣＯＤＩＮＧ  ＣＯＮＴＡＩＮＩＮＧ  ＤＥＦＩＮＩＴＥ  ＡＮＤ  ＩＮＤＥＦＩＮＩＴＥ  ＬＥＮＧＴＨＦＯＲＭＡＴＳ”）に詳しく述べられており、当該特許出願は引用により本明細書に組み込まれる。エレメント・スタックの他の特徴は係属中の米国特許出願第０８／１４７，６０３号（１９９３年１１月４日受理、”ＳＴＡＮＤＡＲＤ  ＰＡＧＥ  ＤＥＳＣＲＩＰＴＩＯＮ  ＬＡＮＧＵＡＧＥ  ＣＬＥＡＲＴＥＸＴ  ＳＴＲＵＣＴＵＲＥ  ＧＥＮＥＲＡＴＯＲ”）に述べられているエレメント・スタックと幾分類似しており、当該特許出願は引用により本明細書に組み込まれる。
【００５８】
図１６に示すダブル・リンクリストデータ構造（ｄｏｕｂｌｅ  ｌｉｎｋｅｄ  ｌｉｓｔ  ｄａｔａｓｔｒｕｃｔｕｒｅ）３６０は、クリアテキスト変換後情報を管理するために用いられる。一つのバイナリ・エレメントが処理変換される都度、当該エレメントのための情報がダブルリンクリストデータ構造に格納される。バイナリからクリアテキストへの変換が終了した後、ダブル・リンクリストデータ構造のそれぞれの情報が、図６に示した文書に類似した出力ファイルへコピーされる。このダブル・リンクリストは、バイナリ表現ではクリアテキスト表現での順序と違った順序を持つことのあるエレメントの処理に役立つ。
【００５９】
ダブル・リンクリストデータ構造３６０は、ポインタ３６２によって指される。ポインタ３６２は、当該ダブル・リンクリストデータ構造が変換されているファイルのための最初のダブル・リンクリストデータ構造でなければ、一つ前のダブル・リンクリストデータ構造の”ｎｅｘｔ”ポインタに対応する。当該ダブル・リンクリストデータ構造が変換されているファイルの最初のダブル・リンクリストデータ構造ならば、ポインタ３６２は、デフォルト値でよく、システムが当該最初のデータ構造を参照するために使用されるに過ぎない。フィールドレベル番号３６４はエレメントの字下げレベルを示す。エレメント・ネーム３６８はエレメントのクリアテキスト・ネームを示す。エントリー３６８は、そのネームを格納するメモリ領域を指すポインタであることもある。フィールド３７０はエレメントのアトリビュート情報を、それが存在するときに、格納する。フィールド３７０は、アトリビュート情報を格納する別のメモリロケーションへのポインタであることもある。
【００６０】
フィールド３７２はエレメントにより使用されるかもしれないデータを格納する。例えば、エレメントがコメントならば、このデータ・フィールドはコメントのテキストを格納することになろう。このデータ・フィールドは、実際のデータを格納している別のメモリロケーションへのポインタであることもある。フィールド３７４はバックポインタ（ｂａｃｋ  ｐｏｉｎｔｅｒ）であり、これは前のダブルリンクリストデータ構造が存在するならば、それを指すものである。前のダブル・リンクリストデータ構造が存在しないときは、このバックポインタはヌルを指す。ネクスト・ポインタ（ｎｅｘｔ  ｐｏｉｎｔｅｒ）３７６は、次のダブル・リンクリストデータ構造が存在するならば、それを指す。次のダブル・リンクリストデータ構造が存在しないときには、このネクスト・ポインタ３７６はヌルを指す。
【００６１】
図１７は、本発明に使用されるアトリビュート・バッファ３８０を示す。このアトリビュート・バッファ３８０は、エレメントの処理中に該エレメントのアトリビュート情報を一時的に記憶するために用いられる。
【００６２】
図１８乃至図２８は、バイナリＳＰＤＬファイルをクリアテキストＳＰＤＬファイルへ変換するために本発明により用いられるプロセスを示す。図１８のステップ４０２は、入力コマンドライン（ｃｏｍｍａｎｄ  ｌｉｎｅ）を解析して入力ファイルネーム及び出力ファイルネームを確定する。ステップ４０４は、その入力ファイルが存在するか判定する。入力ファイルが存在しないときには、フローはステップ４０６へ進み、入力ファイル不存在を原因とするエラーが表示され、プロセスから抜け出す。入力ファイルが存在するときには、フローはステップ４０８へ進み、出力ファイルが特定済みであるか判定する。出力ファイルが特定済みでなければ、ステップ４１０で出力ファイルにデフォルトのファイルネームが割り当てられる。ステップ４１２は、入力ファイルがＳＰＤＬバイナリ・ファイルであるか判定する。この判定は、ファイルの始まり部分を調べ、それにバイナリＳＰＤＬファイルであることを表示するビットが含まれているかを確かめることによって、行なうことができる。ファイルがバイナリＳＰＤＬファイルであるか判定する方法に関するより詳細な説明は、係属中の米国特許出願第０８／００６，４１６号（”ＭＥＴＨＯＤ  ＡＮＤ  ＳＹＳＴＥＭ  ＴＯ  ＲＥＣＯＧＮＩＺＥ  ＥＮＣＯＤＩＮＧ  ＴＹＰＥ  ＩＮ  ＤＯＣＵＭＥＮＴＰＲＯＣＥＳＳＩＮＧ  ＬＡＮＧＵＡＧＥ”）に見ることができ、当該出願は引用により本明細書に組み込まれる。ステップ４１２で入力ファイルがバイナリＳＰＤＬファイルではないと判定した場合、ステップ４１４は入力ファイルのフォーマットが正しくないことを表示し、プロセスは終了する。入力ファイルがバイナリＳＰＤＬファイルであるならば、フローは図１９に示すプロセスＡに進む。なお、図５，図６及び図７に挙げた例は国際規格草案に基づいているのに対し、米国特許出願第０８／００６，４１６号はそれより後のバージョンに基づいているが、該バージョンは未だ最終的な形で刊行されていない。しかし、いずれのバージョンでも”２８  ＣＦ  ４４  ００”はバイナリＳＰＤＬエンコーディングを意味する。
【００６３】
図１９のステップ４２０はエレメントスタックを初期化するが、これは単にスタックのためにメモリを予約するに過ぎない。ステップ４２２及びステップ４２４は、クリアテキスト・ファイルの初めの２行をダブル・リンクリストデータ構造に書き込む。クリアテキストＳＰＤＬファイルの初めの２行は常にＤＯＣＴＹＰＥ及びＳＰＤＬであるので、これらの２行を各ＳＰＤＬファイルの始めに書き込む必要がある。
【００６４】
ステップ４２６は入力ファイルよりタグを取得し、ステップ４２８は該タグを調べ、それがＲＥＳＤＥＦであるか判定する。最初のタグがＲＥＳＤＥＦでないときには、ＳＰＤＬエンコーディング規則はクリアテキスト・エンコーディングの第３行が文書エレメントであることを要求する。最初のエレメントタグがＲＥＳＤＥＦであれば、クリアテキスト・エンコーディングの第３行を文書エレメントにする必要はない。ステップ４２８及びステップ４３０より、フローは図２０に示すプロセスＢへ進む。
【００６５】
図２０のステップ４４０は、エレメント・テーブルをサーチしてバイナリタグに対応するエレメントを見つけ、エレメントタグに関する情報、例えば、クリアテキスト・エレメントネームや、開始タグと終了タグがオプショナルであるか必要であるか、エレメントがプリミティブであるか複合であるか、エレメントのアトリビュート数、エレメントのサブエレメント数、エレメントのサブエレメント・リンクリストへのポインタといった情報を取得する。ステップ４４２は入力ファイルより、エレメントの長さ（ｌｅｎｇｔｈ）を示す次のバイトを読み出す。エンコーディングのレングス・オクテット（ｌｅｎｇｔｈ  ｏｃｔｅｔ）が２進の１０００００００である時には、その長さは不定長である。不定長エンコーディングの終わりは、コンテント・オクテット（ｃｏｎｔｅｎｔｓ  ｏｃｔｅｔ）中の００００Ｈにより示される。ステップ４４４でエンコーディングが不定長であると判定した場合、ステップ４４６はＩＮＤＥＦ＿ＬＥＮ＿ＦＬＡＧを真（ｔｒｕｅ）に設定し、エンコーディングが不定長フォーマットであることを表示する。ステップ４４４でエンコーディングが不定長フォーマットではないと判定された場合には、フローはステップ４４８に進み、固定長エンコーディングの値が決定される。ステップ４４８及びステップ４４６より、フローは図２１に示すステップＣへ進む。
【００６６】
図２１において、ステップ４６０はエレメント・スタックが空であるか判定する。空でなければ、ステップ４６２で、エレメント・スタックのトップエントリーより、処理されるタグのバイト数、該タグに使用されるバイト及び該タグのレングス部を減じる必要がある。現タグのレングス・タイプが固定長であるときには、この固定長も減じられる。多くの場合、タグは１バイトで、レングスは１バイトであるので、エレメント・スタックのトップエントリーのレングス・フィールドより２バイトが減じられる。
【００６７】
ステップ４６０及びステップ４６２より、フローはステップ４６４に進み、サブエレメント・リンクリストポインタがヌルであるか判定される。サブエレメント・リンクリストポインタがヌルのときには、エレメントにはサブエレメントが存在しないので、エレメントは終端（ｔｅｒｍｉｎａｌ）エレメントであり、フローはステップ４７４に進み、終端エレメントに関するデータを、対応のダブル・リンクリストデータ構造３６０のポインタ３７２により指されたバッファに格納する。フローはステップ４７６に進み、ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧ  が真（ｔｒｕｅ）に設定される。フローはステップ４７６より、図２４に示すプロセスＥへ進み、エレメントの情報を新しいダブル・リンクリストに格納する。
【００６８】
ステップ４６４でサブエレメント・リンクリストポインタがヌルでないと判定した場合、エレメントのサブエレメントが存在するので、フローはサブエレメント情報の処理を開始すべくステップ４６８に進む。ステップ４６８はステップ４４０で得られたエレメント情報をエレメント・スタックへプッシュする。フローはステップ４６８から図２２に示すプロセスＤへ進む。
【００６９】
図２２において、ステップ４８０はアトリビュート数（エレメント・スタックに記憶されている）が０より大きいか判定する。アトリビュート数が０より大きくなければ、ステップ４８２はアトリビュート・バッファＡＴＴＲ＿ＢＵＦＦＥＲをヌルに設定し、フローは図２４に示すＥへと進む。アトリビュート数が０より大きいときには、アトリビュートが処理されなければならないので、フローはステップ４８０よりステップ４８４に進み、入力ファイルより次のＡＳＮ．１タグを読み出す。次にステップ４８６は、サブエレメント・リンクリストをサーチして、そのＡＳＮ．１タグが現エレメントのサブエレメントまたはアトリビュートの有効なタグであるかチェックする。サブエレメントがエレメントの正しいＡＳＮ．１サブエレメントならば、フローは図２３に示すプロセスＧへ進む。処理されるエレメントが適切なサブエレメントでないときは、フローはステップ４９０へ進み、タグがコメントであるか判定する。タグがコメントでなければ、サブエレメントはエレメントにとって適切でないので、ステップ４９２はエラーを表示し、プロセスから抜け出る。タグがコメントならば、タグは一つのエレメントとして処理すべく入力ファイルへ書き戻され、フローは場２０のプロセスＢへ戻る。
【００７０】
図２３に示したプロセスＧは、正しいサブエレメントの処理を扱うが、図２２のステップ４８８から始まる。図２３のステップ５００において、サブエレメント・リンクリストより、ＡＳＮ．１タグ値、サブエレメント宣言、サブエレメント・ネーム、サブエレメント・タイプ、サブエレメントの連続番号、次のサブエレメント・リンクリストデータ構造へのネクスト・ポインタのような、サブエレメントに関する情報を取得する。ステップ５０２は、サブエレメント・タイプを調べてサブエレメントがアトリビュートであるか判定する。サブエレメントがアトリビュートならば、ステップ５０８はアトリビュート・データをアトリビュート・バッファＡＴＴＲ＿ＢＵＦＦＥＲに格納し、フローは図２４に示すプロセスＨへ進む。ステップ５０２でサブエレメント・タイプがアトリビュートでないと判定したときには、フローはステップ５０４へ進む。ステップ５０４は、アトリビュートが続いていないことを表示する。エレメントのアトリビュートは、そのエレメントの直後及びそのエレメントのサブエレメントの出現前に現われるべきである。ステップ４８０でアトリビュート数が０より大きいと判定した場合にはフローはステップ５０２へ到達し、サブエレメントはアトリビュートのはずである（アトリビュートである必要はないが）。サブエレメントがアトリビュートでないならば、現サブエレメントに続くアトリビュートは不適切なものであろう。本発明は、図２８に示したフローチャートのステップ６０６，６０８により、そのようなアトリビュートを、その後に出現した時にきちんと整える。ステップ５０４の後に、ステップ５０６は不適切なタグを入力ファイルに書き戻し、フローは次の処理のため図２４のプロセスＥに進む。
【００７１】
図２４のプロセスＨはアトリビュートであるサブエレメントの処理を扱う。図２４のステップ５２０は、エレメント・スタックのトップエントリーより、アトリビュート数を減じる。ステップ５２２はエレメント・スタック内のアトリビュート数を１だけデクリメントする。ステップ５２４は、エレメント・スタック内のアトリビュート数が０より大きいか判定する。アトリビュート数が０より大きいときには、別のアトリビュートを処理しなければならないのでフローはステップ５２６へ進む。ステップ５２６はアトリビュート・バッファに新しい１行キャラクタを格納し、残りのアトリビュートの処理のためフローは図２２に示すプロセスＦへ進む。
【００７２】
ステップ５２４でアトリビュート数が０より大きいと判定した場合、フローはステップ５２８に進み、処理エレメントに関する、エレメントネーム、レベル番号、アトリビュート・バッファ、データ情報、ネクストポインタ及び前ポインタを含む情報の全てが新しいダブル・リンクリストデータ構造に格納される。ステップ５２８より、フローは図２５に示すプロセスＩへ進む。
【００７３】
ステップ５４０はＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧが真（ｔｒｕｅ）であるか判定する。ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧは図２１のステップ４７６で真に設定されている。このフラグが設定されていないならば、ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧのデフォルト値は偽（ｆａｌｓｅ）である。それが真ならば、フローはステップ５４２へ進んで現エレメントが終端エレメントであることを表示し、該エレメントのためのエレメント終了タグが新しいダブル・リンクリストデータ構造に書き込まれる。そしてステップ５４４は、ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧを偽に設定する。
【００７４】
ステップ５４０，５４４の次に、ステップ５４６はＩＮＤＥＦ＿ＬＥＮ＿ＦＬＡＧが真であるか判定する。それが真ならば、フローは不定長フォーマットの処理のため図２６に示したプロセスＪへ進む。そうでなければ、フローはステップ５４８へ進み、エレメントスタックのトップエントリーのエレメント・レングスが０であるか判定される。このレングスが０でなければ、エレメントは固定長であるので、エレメントの全長は処理が終わっておらず、さらに処理するため図２８に示すプロセスＫへ進む。そうでなければ、エレメント・スタックのトップエントリーのレングスは０であり、エレメント・スタックのトップエントリーにある現エレメントは処理が終了し、ステップ５５０はエレメントスタックのトップエレメントの終了タグを新しいダブル・リンクリストデータ構造に書き込む。ステップ５５０より、フローは図２７のＬへ進む。
【００７５】
図２６に示したプロセスＪは不定長フォーマットの処理を扱う。ステップ５６０は入力ファイルにおける現在位置を変数ＦＰＯＳへセーブする。ステップ５６２は入力ファイルより次の２バイトを読み出す。ステップ５６４は、この２バイトの両バイトが０であるか判定する。そうであるならば、不定長コーディング・フォーマットの終わりを意味しているので、フローはステップ５６６に進み、処理されている現エレメントの終了タグがダブル・リンクリストデータ構造に書き込まれ、そしてフローは図２７のＬへ進む。終了フラグに達しないときには、フローはステップ５６４からステップ５６８へ進み、ステップ５６２で読み出されたファイルの最後の２バイトを処理できるように、入力ファイルのポインタが再び位置ＦＰＯＳを指すよう調整される。ステップ５６８よりフローは図２８のＫへ進む。図２７に示したプロセスＬにおいて、ステップ５７６は現エレメントが不定長フォーマットであって、かつ現エレメントの下にエントリーが存在するかを判定する。そうならば、ステップ５７８で、エレメント・スタック内の該下のレベルのレングス・エントリーが、現エレメントのレングス（これは負の値である）を該下のレベルのレングス・エントリーに加算することによって調整される。そしてステップ５８０はエレメント・スタックのトップエントリーをポップする。
【００７６】
ステップ５８２でエレメント・スタックが空であると判定し、かつ、ステップ５８４で処理すべきデータがまだあると判定したときには、フローはステップ５８６へ進んでダブル・リンクリストデータ構造から出力ファイルへデータがコピーされ、プロセスは終了する。エレメント・スタックが空ではないか処理すべきデータがまだあるならば、フローは図２８に示すプロセスＫへ進む。
【００７７】
図２８において、ステップ５９０はバイナリ入力ファイルの次のタグを読み出す。ステップ５９２は、そのタグがコメントであるか判定し、コメントであるときは現エレメントがコメントに設定され、フローは図２０に示すプロセスＢへ進む。該次のタグがコメントでなければ、フローはステップ５９２からステップ５９６へ進み、サブエレメントの有効性を確認するためにサブエレメントリンクリストがサーチされる。このステップは、現サブエレメントが処理されているエレメントの下に出現することが許されるか判定する。ステップ５９８がサブエレメントを有効でないと判定したときには、不正のサブエレメントであるのでステップ６００でエラーが表示されプロセスを抜け出す。ステップ５９８でサブエレメントが有効であると判定したときには、フローはステップ６０２へ進む。
【００７８】
ステップ６０２において、エレメント・スタック内のトップエレメントのアトリビュート数が０より大きいか調べられる。０より大きくないときには、サブエレメントはアトリビュートでないのでフローはプロセスＢへ進む。エレメント・スタックのトップエントリーにおけるアトリビュート数が０より大きいときは、フローはステップ６０４へ進みサブエレメントがアトリビュートであるか判定する。ステップ６０４でサブエレメントがアトリビュートでないと判定したならば、フローはプロセスＢへ進む。ステップ６０４でサブエレメントがアトリビュートであると判定したときには、ステップ６０６はエレメント・スタックのトップエントリーのエレメント情報を見つけるためダブル・リンクリストをサーチする。次にステップ６０８はアトリビュートをアトリビュート・バッファに格納する。そして、フローは図２５に示すプロセスＭへ進む。
【００７９】
図２９及び図３０は、図５に示したバイナリ・ファイルが図６に示したクリアテキスト・ファイルへ変換される時に作られるダブル・リンクリストデータ構造を示す。最初のダブル・リンクリストデータ構造７００は、字下げレベルが０であり、エレメントネームが！ＤＯＣＴＹＰＥであり、アトリビュートもデータも持たず、（ネクスト・ポインタが）ダブル・リンクリストデータ構造７１０を指す。ダブル・リンクリストデータ構造７１０は、字下げレベルが０であり、ＳＰＤＬとネームが付けられ、データフィールドにアトリビュートもデータも持たず、（バックポインタが）ダブル・リンクリストデータ構造７００を指し、（ネクストポインタが）次のダブル・リンクリストデータ構造７２０を指す。
【００８０】
ダブル・リンクリストデータ構造７２０は、（ネクスト・ポインタが）ダブル・リンクリストデータ構造７３０を指す。このダブル・リンクリストデータ構造７３０は、字下げレベルが１であり、ページセットのエレメントを持ち、アトリビュートＳＰＤＬ  ＩＤ  を定義され、（ネクスト・ポインタが）ダブル・リンクリストデータ構造７４０を指す。ダブル・リンクリストデータ構造７４０は、字下げレベルが２のコメントであり、アトリビュートを持たないが、コメントの内容を含むデータを持つ。なお、ダブル・リンクリストデータ構造７４０のＤＡＴＡ＿ＨＥＡＤエントリーは、実際のデータを指すところのリンクリストデータ構造を指す。ダブル・リンクリストデータ構造７４０のＤＡＴＡ＿ＨＥＡＤエントリーにより指されたれたリンクリストデータ構造のネクストエントリーが次のリンクリストデータ構造を指すことがある。
【００８１】
ダブル・リンクリストデータ構造７４０は、（ネクストポインタが）図３０に示すダブル・リンクリストデータ構造７６０を指す。図３０に示すデータ構造は、図２９に示したデータ構造と同様に説明できる。なお、簡略化のため、ダブル・リンクリストデータ構造７８０とダブル・リンクリストデータ構造８００の間のデータ構造は省略されているが、本発明のプロセスを辿り、及び／または図６に示したクリアテキストの例をよく見ることにより、省略されたデータ構造を確認し得る。
【００８２】
図３１乃至図３５は、図５及び図６に示した例が処理される時のエレメントスタックを示す。エレメント・スタック内のポインタによって指されるサブエレメント・リンクリストは、一定のままであるので、図１１乃至図１４に示す同じゼネラルタイプのリンクリストとなろう。
【００８３】
バイナリＳＰＤＬファイルが本発明により処理される様子の例を示すため、図１８乃至図２８に示したフローチャートに戻る。本発明のプロセスは図１８から始まるが、入力ファイルと出力ファイルが特定されフローが図１９へ進んだと仮定する。ステップ４２２は図２９に示すダブル・リンクリストデータ構造７００を生成する。ステップ４２４は図２９に示したダブル・リンクリストデータ構造７１０を生成する。次にステップ４２６は、図５に示すファイルで最初に現われるエレメントであるエレメントタグバイト６１を読み出す。このエレメント６１はＰＡＧＥＳＥＴに対応しエレメントＲＥＳＤＥＦには対応しないので、フローはステップ４３０へ進み、図２９のダブル・リンクリスト７２０を生成する。そしてフローは図２０のプロセスＢへ進む。ステップ４４０は、ＰＡＧＥＳＥＴのようなエレメント・ネームやステップ４４０に列挙された他の全情報を含む、エレメント６１に関する情報を取得する。入力ファイルの次のバイトは５９であり、これはＰＡＧＥＳＥＴの固定長値である。したがって、フローはステップ４２２からステップ４４４、ステップ４４８と進み、図２１のステップ４６０へ進む。
【００８４】
図２１において、ステップ４６０は、エレメント・スタックにはエレメントが全くプッシュされていないので、エレメント・スタックが空であると判定する。ステップ４６４はサブエレメント・リンクリストがヌルでないと判定し、フローはステップ４６８へ進み、エレメント情報をエレメント・スタックへプッシュする。この時のエレメント・スタックは図３１に示す如きである。そしてフローは図２２に示すプロセスＤへ進む。
【００８５】
ＰＡＧＥＳＥＴのアトリビュート数は０より大きいので、フローはステップ４８０からステップ４８４へ進み、入力ファイルより次のＡＳＮ．１タグである０６が取り出される。０６はＰＡＧＥＳＥＴの適切なサブエレメントであるので、フローはステップ４８８から図２３に示したプロセスＧへ進む。ステップ５００はサブエレメントの情報を読み出し、ステップ５０２はサブエレメントがアトリビュートであると判定する。ＰＡＧＥＳＥＴエレメントは一つのアトリビュートを有し、ＰＡＧＥＳＥＴの最初のサブエレメントがアトリビュートであるから、このアトリビュートは順序通りであるので、フローはステップ５０８へ進み、アトリビュートデータはアトリビュート・バッファＡＴＴＲ＿ＢＵＦＦＥＲへ格納される。そしてフローは図２４に示すプロセスＨへ進む。
【００８６】
図２４において、ステップ５２０はエレメント・スタックのトップエントリーよりアトリビュートのレングスを差し引く。ＳＰＤＬ  ＩＤのレングスは４バイトであるので、４に、レングス情報のバイト数、ＳＰＤＬ  ＩＤのバイト数及びＰＡＧＥＳＥＴのバイト数を足した値が図３１に示したスタックより減じられる。最初のアトリビュートの処理が済んだのでステップ５２２はアトリビュート数を１だけ減らし、またＰＡＧＥＳＥＴはアトリビュートを１個しか持たないのでフローはステップ５２４からステップ５２８へ進み、エレメントの情報が図２９に示す新しいダブルリンクリストデータ構造７３０に格納される。ＰＡＧＥＳＥＴは図６の最初の字下げレベルであるので、ダブル・リンクリストデータ構造７３０のレベル番号エントリーは１に設定される。ステップ５２８より、フローは図２５に示すプロセスＩへ進む。
【００８７】
ＴＥＲＭＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧは偽（ｆａｌｓｅ）に初期化されているので、フローはステップ５４０からステップ５４６へ、そしてステップ５４８へと進み、エレメントスタックのトップエントリーのエレメント・レングスは０ではないと判定される。そしてフローは図２８に示すプロセスＫへ進む。
【００８８】
図２８において、ステップ５９０は入力ファイルより次のＡＳＮ．１タグを読み出すが、同タグは４４である。このタグはコメントタグであるので、ステップ５９４は現エレメントをコメントととし、フローは図２０に示すプロセスＢへ進む。
【００８９】
図２０において、ステップ４４０はエレメント・テーブルをサーチしてコメントに関する情報を取得し、ステップ４４８はコメントの固定長値を取得するが、この固定長値は１Ｆである。フローはステップ４６０に進み、エレメント・スタックが空でないことを確認し、ステップ４６２においてコメントのレングスがスタック内のＰＡＧＥＳＥＴのエレメントレングス・エントリーより差し引かれる。次にステップ４６４は、コメント・エレメントがサブエレメントを全く持たないので、サブエレメント・リンクリスト・ポインタがヌルであると判定する。ステップ４７４で、コメントに含まれる情報はデータバッファ・リンクリストデータ構造に格納される。次にステップ４７６は変数ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧを真に設定し、フローは図２４に示すプロセスＥへ進む。
【００９０】
図２４において、ステップ５２８はコメントの情報を図２９に示すダブル・リンクリストデータ構造７４０に格納する。そしてフローは図２５に示すプロセスＩへ進む。ステップ５４０１での判定結果はＹＥＳである。この変数は図２１のステップ４７６で真に設定されているからである。次にフローはステップ５４２に進み、エレメント終了タグが図３０に示すダブル・リンクリストデータ構造７６０に書き込まれる。フローはステップ５４６、ステップ５４８と進み、図２８に示すプロセスＫへ進む。
【００９１】
図２８のステップ５９０は入力ファイルより次のＡＳＮ．１タグを読み出すが、このタグはページセット・ボディに対応するＡ１である。そしてフローはステップ５９２からステップ５９６，５９８，６０２と進み、次に図２０に示すプロセスＢへ進む。
【００９２】
図２０において、ページセット・ボディの情報を取得するためエレメント・テーブルがサーチされる。次にフローは図２１に示すプロセスＣへ進み、ステップ４６２は図３１に示すスタック８５０内のＰＡＧＥＳＥＴエントリーのエレメント・レングス・エントリーから、ページセット・ボディ・エレメントのレングスを減じる。ステップ４６４はページセットボディのサブエレメント・リンクリストポインタがヌルでないと判定するので、フローはステップ４６８へ進み、ＰＡＧＥＳＥＴのエレメント情報をエレメント・スタックへプッシュする。これで、エレメント・スタックは図３２に示すようになる。
【００９３】
同様にして、図５に示すバイナリ・ファイルの残りの部分が本発明のフローチャートに従って処理されることにより、図３３乃至図３５に示すエレメント・スタックと図２９及び図３０に示すダブル・リンクリストデータ構造が得られる。フローチャートのこれ以上の追跡は、簡略化のため省略する。
【００９４】
図３６は本発明のプロセスを実行するために利用可能なワークステーション１０００の構成を示す。ワークステーション１０００はＣＰＵ９５０、ＲＡＭ９５２、ＲＯＭ９５４、キーボード９５８及びマウス９６０がつながれた入力コントローラ９５６を含む。印刷エンジンインターフェイス９６４は印刷エンジン９６２に直接接続され、印刷エンジン９６２はインターフェイス９６４により伝達されるイメージデータを表わすビデオ制御信号を受け取る。このワークステーションはさらに、ハードディスク９６８及びフロッピードライブ９７０とつながれたディスクコントローラ９７２、ネットワーク９８４（例えばＥｔｈｅｒｎｅｔ（登録商標）ネットワーク）との接続のための通信コントローラ９７４、外部ハードディスク９８０と例えばＳＣＳＩバスにより、またプリンタ９７８と例えばＲＳ−２３２Ｃケーブルにより接続されたＩ／Ｏコントローラ９７６を含む。ワークステーションはＣＲＴ９８６と接続されたディスプレイコントローラ９８２も含む。システムバス９６６はワークステーション内の各要素を接続する。
【００９５】
本発明のプロセスは図３６に示す記憶デバイスのどれに格納してもよい。さらに、本発明のプロセスの動作中に、プロセス中で生成され使用されるデータは図３６に示した記憶デバイスのどれに格納してもよい。
【００９６】
なお、本発明で使用されたデータ構造は、本願発明者による他の発明のいくつかで使用できる。これらの他の発明は本発明のフローチャートで使用されたデータフィールドより余分のデータフィールドを必要とするかもしれないので、本発明を構成するために各データ構造に示したフィールドの全ては必要でないかもしれない。さらに、ＳＰＤＬ規格は草案段階で発展中である。したがって、生成されたデータ構造の一部は、規格の変更によりもう必要でないフィールドを、あるいは、規格が変更される可能性の故に存在するフィールドを持っているかもしれない。
【００９７】
なお、付記するならば、下記方法及び装置は本発明の範囲に包含されるものである。
【００９８】
（１）ファイルのフォーマットを変換する方法で、次のステップを有する：
バイナリファイルを入力するステップ；
該バイナリファイルのエレメントをテキストフォーマットへ変換するステップ；
該エレメントの該テキストフォーマットを第１のバッファに書き込むステップ；
該エレメントのためにアトリビュートが必要とされるか確認するステップ；該バイナリファイルのサブエレメントが該エレメントのアトリビュートであるか、または該サブエレメントが該エレメントのアトリビュートでないか判定するステップ；
該サブエレメントをテキストフォーマットへ変換するステップ；
該サブエレメントが該エレメントのアトリビュートでないと判定され、かつ、該エレメントのためにアトリビュートが必要とされると確認された時に、次のステップを実行するステップ：
該エレメントの該サブエレメントの該テキストフォーマットを第２のバッファに書き込むステップ；
該必要とされるアトリビュートに出会うまで該バイナリファイルを処理するステップ；
該必要とされるアトリビュートをテキストフォーマットへ変換するステップ；
該必要とされるアトリビュートの該テキストフォーマットを該エレメントを格納している該第１バッファに書き込むステップ；
該サブエレメントがアトリビュートであると判定され、かつ、該第１のエレメントのためにアトリビュートが必要とされると確認された時に、次のステップを実行するステップ：
該サブエレメントの該テキストフォーマットを該第１バッファに書き込むステップ。
【００９９】
（２）前記（１）の方法において、
該エレメントの該サブエレメントの該テキストフォーマットを第２バッファに書き込むステップは、該エレメントの該サブエレメントの該テキストフォーマットを該第１バッファを参照する該第２バッファに書き込み、かつ該方法は、該サブエレメントが該エレメントのアトリビュートでないと判定された後に実行される次のステップをさらに有する：
該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該第２バッファから逆向きに辿って該第１バッファを見つけるステップ。
【０１００】
（３）前記（１）の方法において、該第２バッファは、該第１バッファを後方参照しかつ次のバッファを前方参照するダブルリンクリストであり、かつ該サブエレメントの該テキストフォーマットを該第２バッファに書き込むステップは、該サブエレメントの該テキストフォーマットを該ダブルリンクリストに書き込み、
該方法はさらに、該サブエレメントが該エレメントのアトリビュートではないと判定された後に実行される次のステップを有する：
該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該ダブルリンクリストから逆向きに辿って該第１バッファを見つけるステップ。
【０１０１】
（４）  以下の手段を有するファイルのフォーマットを変換するための装置：
バイナリファイルを入力するための手段；
該バイナリファイルのエレメントをテキストフォーマットへ変換するための手段；
該エレメントの該テキストフォーマットを第１のバッファに書き込むための手段；
該エレメントのためにアトリビュートが必要とされるか確認するための手段；
該バイナリファイルのサブエレメントが該エレメントのアトリビュートであるか、または該サブエレメントが該エレメントのアトリビュートであるかを判定するための手段；
該サブエレメントを該テキストフォーマットへ変換するための手段；
該サブエレメントが該エレメントのアトリビュートでないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該エレメントの該サブエレメントの該テキストフォーマットを第２のバッファに書き込むための手段；
該サブエレメントが該エレメントのアトリビュートでないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該必要とされるアトリビュートに出会うまで該バイナリファイルを処理するための手段；
該サブエレメントが該エレメントのアトリビュートではないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該必要とされるアトリビュートを該テキストフォーマットへ変換するための手段；該サブエレメントが該エレメントのアトリビュートではないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むための手段；及び
該サブエレメントがアトリビュートであると判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該サブエレメントの該テキストフォーマットを該第１バッファに書き込むのための手段。
【０１０２】
（５）前記（４）の装置において：
該エレメントの該サブエレメントの該テキストフォーマットを該第２バッファに書き込むための手段は、該第１バッファを参照する該第２バッファに該エレメントの該サブエレメントの該テキストフォーマットを書き込み、かつ該装置はさらに次の手段を有する：
該サブエレメントが該エレメントのアトリビュートではないと判定された後、該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該第２バッファから逆向きに辿って該第１バッファを見つけるための手段。
【０１０３】
（６）前記（４）の装置において、該エレメントの該サブエレメントの該テキストフォーマットを該第２バッファに書き込むための手段は、該第１バッファを後方参照しかつ次のバッファを前方参照するダブルリンクリストであるところの該第２バッファに、該エレメントの該サブエレメントの該テキストフォーマットを書き込み、かつ該装置はさらに次の手段を有する：
該サブエレメントが該エレメントのアトリビュートでないと判定された後、該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該ダブルリンクリストより逆向きに辿って該第１バッファを見つけるための手段。
【０１０４】
（７）ファイルのフォーマットを変換するための方法で次のステップを有する：
バイナリファイルを入力するステップ；
該バイナリファイルのエレメントをテキストフォーマットへ変換するステップ；
該エレメントの該テキストフォーマットを第１のバッファに書き込むステップ；
該エレメントの許容されるサブエレメントを記憶しているデータ構造を辿って調べることにより、該バイナリファイルの該エレメントのサブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが該エレメントの許容されないサブエレメントであるか判定するステップ；
該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時にエラーを表示するステップ；及び
該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時に、該バイナリファイルの後続部分をテキストフォーマットへ変換するステップ。
【０１０５】
（８）前記（７）の方法において、該判定のステップは、該エレメントの許容されるサブエレメントをそれぞれ記憶しているサブエレメントリンクリストデータ構造を辿って調べることにより、該エレメントの該サブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが該エレメントの許容されないサブエレメントであるか判定し、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つかるならば該サブエレメントは許容されると判定され、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つからなければ該サブエレメントは許容されないと判定される。
【０１０６】
（９）次の手段を有する、ファイルのフォーマットを変換する装置：
バイナリファイルを入力するための手段；
該バイナリファイルのエレメントをテキストフォーマットへ変換するための手段；
該エレメントの該テキストフォーマットを第１のバッファに書き込むための手段；
該エレメントの許容されるサブエレメントを記憶しているデータ構造を辿って調べることにより、該バイナリファイルの該エレメントのサブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが該エレメントの許容されないサブエレメントであるか判定するための手段；該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時にエラーを表示するための手段；及び
該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時に、該バイナリファイルの後続部分を該テキストフォーマットへ変換するための手段。
【０１０７】
（１０）前記（９）の装置において、該判定のための手段は、該エレメントの許容されるサブエレメントをそれぞれ記憶しているサブエレメントリンクリストデータ構造を辿って調べることにより、該エレメントの該サブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが許容されないサブエレメントであるか判定し、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つかるならば該サブエレメントは許容されると判定され、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つからなければ該サブエレメントは許容されないと判定される。
【０１０８】
（１１）固定長エンコーディングがネストされた不定長エンコーディングのフォーマットをバイナリからテキストへ変換する方法であり、該不定長エンコーディング及び該固定長エンコーディングは両方ともプリアンブル情報及びコンテント情報を含み、該方法は次のステップを有する：
バイナリファイルを入力するステップ；
該不定長エンコーディングの該プリアンブル情報を処理して該不定長エンコーディングの該プリアンブル情報のバイナリ表現をテキスト表現へ変換するステップ；
次のステップを実行することによって、該固定長エンコーディングを含む該不定長エンコーディングの該コンテント情報を処理するステップ：
該固定長エンコーディングの該プリアンブル情報を処理して該固定長エンコーディングのコンテント情報のバイト数を確認するステップ；
及び
該固定長エンコーディングのコンテント情報のバイナリ表現をテキスト表現へ変換することにより、該不定長エンコーディングの終わりを示すマーカーが存在するか判定することなく、該固定長エンコーディングのコンテント情報のバイト数が処理されるまでバイトを処理することによって該固定長エンコーディングの該コンテント情報を処理するステップ；
該固定長エンコーディングの該コンテント情報を処理した後、該固定長エンコーディングの該コンテント情報の後の該不定長エンコーディングのバイトを調べ該不定長エンコーディングの終わりを示すマーカーを捜すステップ；及び該固定長エンコーディングの該コンテント情報の後のバイトが該不定長エンコーディングの終わりを示すならば、該不定長エンコーディングの処理を終了させるステップ。
【０１０９】
（１２）前記（１１）の方法で、さらに次のステップを有する：
該固定長エンコーディングの該コンテント情報に続くバイトが該不定長エンコーディングの終わりを示さないならば、該固定長エンコーディングに続くバイトを、該不定長エンコーディング中にネストされた次のプロシージャとして処理するステップ。
【０１１０】
（１３）固定長エンコーディングがネストされた不定長エンコーディングのフォーマットをバイナリからテキストへ変換する方法であり、該不定長エンコーディング及び該固定長エンコーディングは両方ともプリアンブル情報及びコンテント情報を含み、該方法は次のステップを有する：
該不定長エンコーディングの該プリアンブル情報を処理して該プリアンブル情報のバイナリ表現をテキスト表現へ変換するステップ；
次のステップを実行することによって、該固定長エンコーディングを含む該不定長エンコーディングの該コンテント情報を処理するステップ：
該固定長エンコーディングの該プリアンブル情報を処理して該固定長エンコーディングの該コンテント情報のバイト数を確認し、該固定長エンコーディングの該コンテント情報のバイト数を一時的記憶手段に格納し、かつ、該固定長エンコーディングのバイナリ表現をテキスト表現へ変換するステップ；及び
該不定長エンコーディングの終わりを示すマーカーが該不定長エンコーディング中に存在するか判定することなく、該一時的記憶手段に記憶された該コンテント情報バイト数が処理されるまでバイトを処理することによって該固定長エンコーディングの該コンテント情報を処理し、該固定長エンコーディングの該コンテント情報が処理されている時に、該固定長エンコーディングの処理が済んだバイト数を該一時的記憶手段にカウントするステップ；
該固定長エンコーディングの該コンテント情報を処理した後、該固定長エンコーディングの該コンテント情報の後の該不定長エンコーディングのバイトを調べ該不定長エンコーディングの終わりを示すマーカーを捜すステップ；及び該固定長エンコーディングの該コンテント情報の後のバイトが該不定長エンコーディングの終わりを示すならば該不定長エンコーディングの処理を終了させるステップ。
【０１１１】
（１４）前記（１３）の方法において、該固定長エンコーディングの該コンテント情報の該バイト数を格納するステップは、そのレングス情報をスタックにプッシュし；かつ
該固定長エンコーディングの該コンテント情報を処理するステップは、該不定長エンコーディングの終わりを示すマーカーが該不定長エンコーディング中に存在するか判定することなく、該スタック上の該コンテントのバイト数が処理されるまでバイトを処理し、該固定長エンコーディングの該コンテント情報が処理されている時に、該固定長エンコーディングの処理の済んだバイト数を該スタックにカウントする。
【０１１２】
（１５）不定長エンコーディングがネストされた第１の固定長エンコーディングのフォーマットをバイナリからテキストへ変換する方法であり、該不定長エンコーディングは第２の固定長エンコーディングがネストされており、該不定長エンコーディング並びに該第１及び該第２の固定長エンコーディングはそれぞれプリアンブル情報及びコンテント情報を含み、該方法は次のステップを有する：
該第１固定長エンコーディングの該プリアンブル情報を処理し該プリアンブル情報をバイナリ表現からテキスト表現へ変換するステップ；
次のステップを実行することにより該第１固定長エンコーディングの該コンテント情報を処理するステップ：
該不定長エンコーディングの該プリアンブル情報を処理し、該不定長エンコーディングの該プリアンブル情報が処理されている時に、該不定長エンコーディングの該プリアンブル情報の処理されたバイト数を一時的記憶手段の第１のエントリーにカウントし、該不定長エンコーディングの該プリアンブル情報をバイナリ表現からテキスト表現へ変換するステップ；
次のステップを実行することにより該不定長エンコーディングの該コンテント情報を処理するステップ：
該第２固定長エンコーディングの該プリアンブル情報を処理して該第２固定長エンコーディングの該コンテント情報のバイト数を確認し、該第２固定長エンコーディングの該コンテント情報のバイト数を該一時的記憶手段の第２のエントリーに格納し、該第２固定長エンコーディングの該プリアンブル情報が処理されている時に、該第２固定長エンコーディングの処理されたバイト数を該一時的記憶手段の該第１エントリーにカウントし、該第２固定長エンコーディングのバイナリ表現をテキスト表現へ変換するステップ；及び
該不定長エンコーディングの終わりを示すマーカーが該エンコーディング中に存在するか判定することなく、該第２固定長エンコーディングの該コンテント情報のバイト数が処理されるまで該第２固定長エンコーディングを処理することによって該第２固定長エンコーディングの該コンテント情報を処理し、該第２固定長エンコーディングの該コンテント情報が処理されている時に、該第２固定長エンコーディングの処理されたバイト数を該一時的記憶手段の該第２エントリーにカウントするステップ；
該第２固定長エンコーディングの該コンテント情報を処理した後、該第２固定長エンコーディングの該コンテント情報の後の該エンコーディングのバイトを調べ、該不定長エンコーディングの終わりを示すバイトを捜すステップ；
該第２固定長エンコーディングの該コンテント情報に続くバイトが該不定長エンコーディングの終わりを示すならば、該不定長エンコーディングの処理を終了させるステップ；及び
該第１固定長エンコーディングのコンテントの後続バイトを、該第１固定長エンコーディングの全バイトが処理されるまで処理するステップ。
【０１１３】
【発明の効果】
以上、詳細に説明したところから理解されるように、本発明によれば、バイナリフォーマットをクリアテキストフォーマットへ変換する際に解決すべき前記したような諸課題を解決し、文書のバイナリフォーマットからクリアテキストフォーマットへの変換が可能になる。
【図面の簡単な説明】
【図１】バイナリ・エンコーディングの固定長フォーマット及び不定長フォーマットのネスティングの一例を示す図である。
【図２】ＩＳＯ／ＩＥＣ  ８８２５  によるエンコーディングの構造を示す図である。
【図３】ＩＳＯ／ＩＥＣ  ８８２５  によるアイデンティファイア・オクテットの構造を示す図である。
【図４】ＳＰＤＬエレメント状態遷移ダイヤグラムの部分図である。
【図５】バイナリ・エンコードのＳＰＤＬ文書サンプルの１６進表現を示す図である。
【図６】図５に示したバイナリ文書のクリアテキスト表現を示す図である。
【図７】図５に示したバイナリ・エレメントと図６に示したクリアテキスト・エレメントとの対応を示す図である。
【図８】ＡＳＮ．１タグ及び対応のクリアテキスト・エレメントを示すアプリケーション・テーブルを示す図である。
【図９】ＳＰＤＬ構造エレメントに関する情報を格納するために用いられるエレメント・テーブルを示すずである。
【図１０】エレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造の説明図である。
【図１１】図９に示したエレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造のサンプルを示す図である。
【図１２】図９に示したエレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造のサンプルを示す図である。
【図１３】図９に示したエレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造のサンプルを示す図である。
【図１４】図９に示したエレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造のサンプルを示す図である。
【図１５】本発明の変換プロセスに用いられるエレメント・スタックを示す図である。
【図１６】各ラインのクリアテキスト表現を、出力ファイルに書き出されるまで記憶するため使用されるダブル・リンクリストデータ構造を示す図である。
【図１７】本発明に使用されるアトリビュート・バッファを示す図である。
【図１８】本発明で用いられるプロセスを記述したフローチャートである。
【図１９】本発明で用いられるプロセスを記述したフローチャートである。
【図２０】本発明で用いられるプロセスを記述したフローチャートである。
【図２１】本発明で用いられるプロセスを記述したフローチャートである。
【図２２】本発明で用いられるプロセスを記述したフローチャートである。
【図２３】本発明で用いられるプロセスを記述したフローチャートである。
【図２４】本発明で用いられるプロセスを記述したフローチャートである。
【図２５】本発明で用いられるプロセスを記述したフローチャートである。
【図２６】本発明で用いられるプロセスを記述したフローチャートである。
【図２７】本発明で用いられるプロセスを記述したフローチャートである。
【図２８】本発明で用いられるプロセスを記述したフローチャートである。
【図２９】図５に示されたバイナリ文書の変換中に生成されるダブル・リンクリストデータ構造の一部を示す図である。
【図３０】図５に示されたバイナリ文書の変換中に生成されるダブル・リンクリストデータ構造の一部を示す図である。
【図３１】図５に示された文書の変換中におけるエレメント・スタックのステータスを示す図である。
【図３２】図５に示された文書の変換中におけるエレメント・スタックのステータスを示すずである。
【図３３】図５に示された文書の変換中におけるエレメント・スタックのステータスを示す図である。
【図３４】図５に示された文書の変換中におけるエレメント・スタックのステータスを示す図である。
【図３５】図５に示された文書の変換中におけるエレメント・スタックのステータスを示す図である。
【図３６】本発明のハードウエア構成例を示すブロック図である。
【符号の説明】
２３０〜３３０  サブエレメント・リンクリストデータ構造
３４０  エレメントスタック
３６０  ダブル・リンクリストデータ構造
３７４  バックポインタ
３７６  ネクストポインタ
３８０  アトリビュートバッファ
７００〜８１０  ダブル・リンクリストデータ構造
８５０  エレメントスタック
９５６  入力コントローラ
９５８  キーボード
９６０  マウス
９６２  印刷エンジン
９６４  印刷エンジンインターフェイス
９６６  システムバス
９６８  ハードディスク
９７０  フロッピーディスク
９７２  ディスクコントローラ
９７４  通信コントローラ
９７６  Ｉ／Ｏコントローラ
９７８  プリンタ
９８０  ハードディスク
９８２  ディスプレイコントローラ
９８４  ネットワーク
【図１】
0003560258.tif 000002
【図２】
0003560258.tif 000003
【図３】
0003560258.tif 000004
【図４】
0003560258.tif 000005
【図５】
0003560258.tif 000006
【図６】
0003560258.tif 000007
【図７】
0003560258.tif 000008
【図８】
0003560258.tif 000009
【図９】
0003560258.tif 000010
【図１０】
0003560258.tif 000011
【図１１】
0003560258.tif 000012
【図１２】
0003560258.tif 000013
【図１３】
0003560258.tif 000014
【図１４】
0003560258.tif 000015
【図１５】
0003560258.tif 000016
【図１６】
0003560258.tif 000017
【図１７】
0003560258.tif 000018
【図１８】
0003560258.tif 000019
【図１９】
0003560258.tif 000020
【図２０】
0003560258.tif 000021
【図２１】
0003560258.tif 000022
【図２２】
0003560258.tif 000023
【図２３】
0003560258.tif 000024
【図２４】
0003560258.tif 000025
【図２５】
0003560258.tif 000026
【図２６】
0003560258.tif 000027
【図２７】
0003560258.tif 000028
【図２８】
0003560258.tif 000029
【図２９】
0003560258.tif 000030
【図３０】
0003560258.tif 000031
【図３１】
0003560258.tif 000032
【図３２】
0003560258.tif 000033
【図３３】
0003560258.tif 000034
【図３４】
0003560258.tif 000035
【図３５】
0003560258.tif 000036
【図３６】
0003560258.tif 000037