JP3560258B2

JP3560258B2 - Format converter

Info

Publication number: JP3560258B2
Application number: JP3061195A
Authority: JP
Inventors: モトヤマテツロウ; マンガットサットウインダー; ツアイドニー
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 1994-03-09
Filing date: 1995-02-20
Publication date: 2004-09-02
Anticipated expiration: 2019-09-02
Also published as: JPH07271551A

Description

【０００１】
【産業上の利用分野】
本発明は文書のフォーマット変換に係り、特にバイナリ・エンコードの文書（binary encoded document）からクリアテキスト・エンコードの文書（cleartext encoded document）への変換に関する。本発明はまたさらに、バイナリ・エンコードの標準ページ記述言語文書（standard Page Description Language document）のクリアテキスト・エンコードの標準ページ記述言語文書への変換に関する。
【０００２】
なお、本出願は、米国特許出願第０８／１４７，６０３号（１９９３年１１月４日受理，”ＳＴＡＮＤＡＲＤＰＡＧＥＤＥＳＣＲＩＰＴＩＯＮＬＡＮＧＵＡＧＥＣＬＥＡＲＴＥＸＴＳＴＲＵＣＴＵＲＥＧＥＮＥＲＡＴＯＲ”）、米国特許出願第０８／０６６，３８３号（１９９３年５月２１日受理，” ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＰＲＯＣＥＳＳＩＮＧＭＩＸＥＤＢＩＮＡＲＹＬＥＮＧＴＨＥＮＣＯＤＩＮＧＳＣＯＮＴＡＩＮＩＮＧＤＥＦＩＮＩＴＥＡＮＤＩＮＤＥＦＩＮＩＴＥＬＥＮＧＴＨＦＯＲＭＡＴＳ ”）及び米国特許出願第０８／００６，４１６号（１９９３年１月１９日，” ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＴＯＲＥＣＯＧＮＩＺＥＥＮＣＯＤＩＮＧＴＹＰＥＩＮＤＯＣＵＭＥＮＴＰＲＯＣＥＳＳＩＮＧＬＡＮＧＵＡＧＥ”）の一部継続出願であり、上記３件の米国特許出願はそれぞれ米国特許出願第０７／９３１，８０８号（１９９２年８月１１日受理，” ＡＭｅｔｈｏｄＡｎｄＳｙｓｔｅｍｔｏＨａｎｄｌｅＤｉｃｔｉｏｎａｒｙＧｅｎｅｒａｔｉｏｎａｎｄＣｏｎｔｅｘｔＤＥｃｌａｒａｔｉｏｎｉｎａＤｏｃｕｍｅｎｔＰｒｏｃｅｓｓｉｎｇＬａｎｇｕａｇｅ”）の一部継続出願であり、当該米国特許出願第０７／９３１，８０８号は米国特許出願第０７／８７６，６０１（１９９２年４月３０日受理，” ＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓｔｏＭａｎａｇｅＰｉｃｔｕｒｅａｎｄＰａｇｅｓｅｔｆｏｒＤｏｃｕｍｅｎｔＰｒｏｃｅｓｓｉｎｇ ” 、米国特許出願第０７／８７６，２５１号（１９９２年４月３０日受理，” ＭｅｔｈｏｄａｎｄＳｙｓｔｅｍｔｏｈａｎｄｌｅＩｎｃｌｕｓｉｏｎｏｆＥｘｔｅｒｎａｌＦｉｌｅｓｉｎｔｏａＤｏｃｕｍｅｎｔＰｒｏｃｅｓｓｉｎｇＬａｎｇｕａｇｅ ”）及び米国特許出願第０７／７７８，５７８号（１９９１年１０月１７日受理，” ＳｙｓｔｅｍａｎｄＭｅｔｈｏｄｆｏｒＤｏｃｕｍｅｎｔＰｒｏｃｅｓｓｉｎｇ”）の一部継続出願であり、上記各特許出願は引用により本明細書に組み込まれる。
【０００３】
【従来の技術】
一つの標準化ページ記述言語（ＳＰＤＬ）が提案され、国際標準化機構（ＩＳＯ）で国際規格として開発中である。この提案は、本願発明者の一人もその関与者であるが、現在、ＩＳＯの１セクションに草案として提出されている。この草案はＩＳＯ／ＩＥＣＤＩＳ１０１８０ ”ＩｎｆｏｒｍａｔｉｏｎＰｒｏｃｅｓｓｉｎｇＴｅｘｔーＣｏｍｍｕｎｉｃａｔｉｏｎ−ＳｔａｎｄａｒｄＰａｇｅＤｅｓｃｒｉｐｔｉｏｎＬａｎｇｕａｇｅ”として知られ、ニューヨークの米国規格協会（ＡＮＳＩ）で入手可能であるが、ここに引用することによっ本明細書に組み込まれる。
【０００４】
標準ページ記述言語（ＳＰＤＬ）は階層的に構造化されたページ記述言語である。この構造化された階層によれば、文書の一部分の印刷をする場合に、当該部分に影響する可能性のあるフォーマット用コマンド（ｆｏｒｍａｔｔｉｎｇｃｏｍｍａｎｄ）を文書全体にわたって調べる必要がなくなる。所望の部分を印刷するのに、その刷したい部分より階層が上の文書の部分しか処理する必要がない。
【０００５】
ＳＰＤＬのもう一つの利点は、ＳＰＤＬがＩＳＯ８８７９：１９８６に定義された標準一般化マークアップ言語（ＳｔａｎｄａｒｄＧｅｎｅｒａｌｉｚｅｄＭａｒｋｕｐＬａｎｇｕａｇｅ，ＳＧＭＬ）に準拠していることである。このことにより、文書構造を記述し包括的に結び付けることが可能になる。複数のファイルは、ＳＧＭＬで結びつけられたならば、変換ユーティリティを用いる事なく、かつ構造フォーマットを損なうことなく、あるプラットフォームから他のプラットフォームへ継ぎ目なく移ることができる。
【０００６】
ＳＰＤＬは、ＡＳＮ．１に述べられているベーシック・エンコーディング規則（ＢａｓｉｃＥｎｃｏｄｉｎｇＲｕｌｅｓ）に準拠している。ＡＳＮ．１に関する完全な説明は、ＤｏｕｇｌａｓＳｔｅｅｄｍａｎ著”ＡＳＮ．１，ＴｈｅＴｕｔｏｒｉａｌａｎｄＲｅｆｅｒｅｎｃｅ”（１９９０年）に見られるが、この文献は引用により本明細書に組み込まれる。
【０００７】
クリアテキスト（ｃｌｅａｒｔｅｘｔ）言語は、人間が読むことのできるコンピュータ言語の一種である。非クリアテキスト言語の一例をあげるならば、文書のバイナリ・エンコーディング（ｂｉｎａｒｙｅｎｃｏｄｉｎｇ）であろう。２進もしくは１６進表現の文書を見ても、人間には文書内容を容易には理解できないからである。バイナリ・エンコードされた文書の一つの主要な利点として、２進で表現された文書は同等のクリアテキスト形式の文書に比べて必要とする記憶スペースが非常に少ない事がある。このことがバイナリ文書の記憶スペースの減少及び伝送時間の高速化を可能にする。しかしクリアテキスト・エンコードの文書に比べ、特殊なソフトウエアを用いないとバイナリ・エンコードの文書の編集及び理解が難しい。
【０００８】
したがって、前述のように文書のクリアテキスト・エンコーディングにもバイナリ・エンコーディングにも長所と短所があるので、文書を一方のフォーマットから他方のフォーマットへ変換したいことがあろう。
【０００９】
【発明が解決しようとする課題】
本発明の一つの目的は、バイナリ・エンコードの文書をクリアテキスト・エンコードの文書へ変換する手段を提供することである。
【００１０】
本発明のもう一つの目的は、バイナリ・エンコードの標準ページ記述言語文書を等価なクリアテキスト・エンコードの標準ページ記述言語文書へ変換する手段を提供することである。
【００１１】
バイナリＳＰＤＬ文書で要求されるフォーマットのゆえに、バイナリ・エンコード文書をクリアテキスト・エンコード文書に変換するために単純なルックアップ（ｌｏｏｋ−ｕｐ）プロシージャを実行することはできない。様々なバイナリ・シンボル（ｂｉｎａｒｙｓｙｍｂｏｌ）の表わす内容は、ＳＰＤＬ文書中のバイナリ・シンボルのロケーションに依存して決まる。
【００１２】
本発明が扱わなければならないもう一つの課題は、バイナリ・エンコードされたプロセスそれぞれの長さを管理することである。ＳＰＤＬは階層的に構造化されたページ記述言語であり、各階層レベルの始まりは、該レベルが固定長フォーマットまたは不定長フォーマットのいずれでエンコードされるかを示し、また、固定長バイナリ・エンコーディングがある時には、エンコーディングの長さを示す。
【００１３】
本発明が扱う別の課題は、バイナリ・エンコーディングにおける特定エレメントの順序がクリアテキスト・エンコーディングでは変更されなければならないという事である。したがってクリアテキストＳＰＤＬフォーマットにおいて要求されるエンコーディング順序を知る必要がある。
【００１４】
【課題を解決するための手段】
前記目的もしくは課題を解決するための手段を、やや具体的に説明すれば、本発明は、バイナリからクリアテキストへの変換を行なうために、まず最初に、アプリケーション・テーブル（ａｐｐｌｉｃａｔｉｏｎｔａｂｌｅ）よりＡＳＮ．１タグを検索し、このバイナリ・タグ（ｂｉｎａｒｙｔａｇ）のクリアテキスト名を決定する。クリアテキスト名が決まったならば、当該エレメントに関するそれ以上の情報をエレメント・テーブル（ｅｌｅｍｅｎｔｔａｂｌｅ）より検索できる。エレメント・テーブルのエレメントはサブエレメント（ｓｕｂ−ｅｌｅｍｅｎｔ）を持つことができ、サブエレメントはサブエレメント・リンクリスト（ｓｕｂ−ｅｌｅｍｅｎｔｌｉｎｋｅｄｌｉｓｔ）を指すエレメント・テーブル中のポインタによって参照される。
【００１５】
エレメントに関し必要な情報が得られた後、変換プロセスで用いられる情報の管理のための各種フィールドを持つエレメント・スタックに、一つのエントリーがプッシュされる。このエレメント・スタックは、バイナリ・コーディングの固定長フォーマット及び不定長フォーマットの処理に非常に有益である。
【００１６】
バイナリ・エレメントが変換されている時に、アトリビュート（ａｔｔｒｉｂｕｔｅ）値がアトリビュート・バッファに格納される。出力ファイルの生成前において、ファイルが変換されている時に変換された各クリアテキスト行がダブル・リンクリストデータ構造（ｄｏｕｂｌｅｌｉｎｋｅｄｌｉｓｔｄａｔａｓｔｒｕｃｔｕｒｅ）に書き込まれる。ファイル全体が変換されてダブル・リンクリストデータ構造に書き込まれると、ダブル・リンクリストデータ構造の情報が出力ファイルへ書き出される。
【００１７】
【作用】
ダブル・リンクリストデータ構造は、不適切な（ｏｕｔｏｆｏｒｄｅｒ）アトリビュートの処理のために有効に利用される。エレメントはアトリビュートとサブエレメントを含むことができる。通常、クリアテキストＳＰＤＬの場合、アトリビュートはエレメントの直後、及び、あらゆるサブエレメントの出現前に、出現しなければならない。しかし、バイナリＳＰＤＬエンコーディングにおいては、サブエレメントがアトリビュートの前に出現することがある。
【００１８】
本発明は、アトリビュート・バッファとダブル・リンクリストデータ構造を用いて、上述の不適切なアトリビュートの問題を解決する。本発明において、エレメントより階層的に下に現われるオブジェクトはサブエレメントと総称される。あるエレメントに対するサブエレメントは、そのエレメントのアトリビュートであるか、あるいは実際のサブエレメントである。アトリビュートを適切ならしめるためには、それらアトリビュートはエレメントの直後に出現するべきである。アトリビュートの全てが出現する以前にエレメントの後にサブエレメントが出現したならば、その後のアトリビュートは不適切なアトリビュートであると考えられる。ダブル・リンクリストデータ構造はエレメントのアトリビュート情報を格納するためのエントリーを有する。あるエレメントの下に、アトリビュートの全部が処理される前にノンアトリビュート（ｎｏｎ−ａｔｔｒｉｂｕｔｅ）・サブエレメントが出現した場合には、親（ｐａｒｅｎｔ）エレメントのダブル・リンクリストデータ構造によって新しいダブル・リンクリストデータ構造が参照される。親エレメントのサブエレメントの処理後に、不適切なアトリビュートが出現することになる。最も最近に生成されたダブル・リンクリストデータ構造より、親エレメントのダブル・リンクリストデータ構造に到達するまで、ダブル・リンクリストデータ構造が逆向きにトレースされる。そして、そのアトリビュート・サブエレメントのアトリビュート情報が親エレメントのダブル・リンクリストデータ構造のアトリビュート・エントリーに書き込まれる。このようにして、不適切アトリビュートが効率的に処理される。
【００１９】
【実施例】
以下、添付図面を参照して本発明の一実施例を説明するが、複数の図面にわたって同一の参照数字は同一部または対応部を示す。
【００２０】
添付図面中の図１を参照するに、バイナリ・エンコード文書に関する固定長及び不定長フォーマットのネスティングの一例が示されている。図１は、処理されるべき一つのデータストリームもしくは文書データストリームを示すと考えることができる。行１〜行１６及び行１７〜行１９は、最高階層レベルの２つのコーディングであるが、行１〜行１６内にはネストされたコーディングがある。行１〜行１６のエンコーディングのコンテント（ｃｏｎｔｅｎｔ）は４００バイトの固定長である。これら４００バイト内で、まず行４〜行１３に一つの不定長構造がある。この行４〜行１３の不定長コンテントは２４８バイト及び４０バイトの固定長コーディングである。行４〜行１３にある４００バイトのコンテントからなる不定長エンコーディングに加えて、１００バイトのコンテントを含む行１４〜行１６の固定長エンコーディングがある。図１の行１７〜１９は２５０バイトの長さの固定長エンコーディングを含む。
【００２１】
”固定長フォーマットと不定長フォーマットのネスティング（ｎｅｓｔｉｎｇ）”なるタームは、ある不定長エンコーディングが、そのコンテントとして、一つの不定長エンコーディングと一つの固定長エンコーディング、すなわち、これら二つのエンコーディングの組合せを持つことができる、ということを意味する。このことは、その固定長エンコーディングが、その不定長エンコーディングが終わる前に始まることを意味する。上記タームは不定長エンコーディングを含んだ固定長エンコーディングにも同様に当てはまる。すなわち、不定長エンコーディングは固定長エンコーディングが終わる前に始まることができる。さらに、一つのエンコーディング内に、任意数の任意タイプのエンコーディングをネスト可能である。
【００２２】
図１に示したようなエンコーディングが処理されている時に、ネストされた固定長エンコーディング及び不定長エンコーディングのハンドリングに関して一つの問題が生じる。図１に示した例は単純なケースである。固定長・不定長フォーマットのネスティングがずっと深くなることがあり得る。したがって、処理システムは、多くの不定長フォーマット及び固定長フォーマットの階層レベルを管理せねばならないかもしれない。
【００２３】
不定長エンコーディングの終わりを確認するには、ＡＳＮ．１エンコーディングで使用される行１３の０００Ｈのような、不定長エンコーディングの終わりフラグもしくはマーカーを捜すだけでは不十分である。というのは、行９及び行１２にあるコンテントが０００Ｈをデータ、イメージデータとして含むことがあるからである。したがって、本発明は、不定長エンコーディングの終わり０００Ｈを、ネストされた固定長エンコーディングの処理が済んだ後に捜す。不定長エンコーディングの終わりは、固定長フォーマットのネストされたルーチンの後に来る筈であるからである。
【００２４】
さて、ＡＳＮ．１に要求されるエンコーディングであるが、図２はＩＳＯ／ＩＥＣ８８２４に定義されたベーシック・エンコーディング規則に従ったバイナリ・エンコーディングの構造を示している。このエンコーディングは１個以上のアイデンティファイア・オクテット（ｉｄｅｎｔｉｆｉｅｒｏｃｔｅｔ）から始まり、次に１個以上のレングス・オクテット（ｌｅｎｇｔｈｏｃｔｅｔ）が来て、これにコンテント・オクテット（ｃｏｎｔｅｎｔｓｏｃｔｅｔ）が続く。
【００２５】
ＩＳＯ／ＩＥＣ８８２４により定義されたアイデンティファイア・オクテットの構造が図３に示されている。このアイディンティファイア・オクテットの初めの２ビットはエンコーディングのクラスを表わす。図３に示されたビット８及びビット７で定義される可能なエンコーディング・クラスは、ユニバーサル、アプリケーション、コンテント・スペシフィック（ｃｏｎｔｅｎｔ−ｓｐｅｃｉｆｉｃ）、及びプライベートの４クラスである。ＡＳＮ．１によるエンコーディングの完全な説明は、ＩＳＯ／ＩＥＣ８８２４及びＩＳＯ／ＩＥＣ８８２５（いずれも引用によって本明細書に組み込まれる）に見られる。しかし、本発明の作用を理解するのにエンコーディングの様々なクラスについての理解は必要ではないので、説明の簡略のため、これ以上の詳細については述べない。
【００２６】
図３に示したビット６は、エンコーディングがプリミティブ（ｐｒｉｍｉｔｉｖｅ）であるか複合（ｃｏｎｓｔｒｕｃｔｅｄ）であるかを決定する。プリミティブとは他のエンコーディングが当該エンコーディング内にネストされていないことを意味し、複合とは他のエンコーディングが当該エンコーディング内にネストされていることを意味する。図３に示されているビット５〜１はタグの番号に関するものである。タグの番号が３１を超えるときには、ビット５〜１は同番号を表現するには足りないので、後続のアイデンティファィア・オクテットでタグの番号をエンコードする。様々なタグ番号の完全な理解は、本発明の作用を理解するためには必要ではないので簡略のため省略する。
【００２７】
アイデンティファイア・オクテット及びレングス・オクテットはプリアンブル（ｐｒｅａｍｂｌｅ）情報と考えることができ、コンテント・オクテットはコンテント情報と考えることができる。アイデンティファイア情報がテキストフォーマットへ変換されたときに得られるテキスト情報は、クリアテキスト開始タグにコンテント情報のクリアテキスト表現が続いたもので、必要ならば、もしくは要求されるならば、その後にクリアテキスト終了タグが続く。
【００２８】
当業者にとって以上の説明でバイナリＳＰＤＬエンコーディングの基本を理解するのに十分であると考えられる。しかし、バイナリ・エンコーディングの処理に関するより詳細かつ完全な説明を、係属中の米国特許出願第０８／０６６，３８３号（”ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＰＲＯＣＥＳＳＩＮＧＭＩＸＥＤＢＩＮＡＲＹＬＥＮＧＴＨＥＮＣＯＤＩＮＧＣＯＮＴＡＩＮＩＮＧＤＥＦＩＮＩＴＥＡＮＤＩＮＤＥＦＩＮＩＴＥＬＥＮＧＴＨＦＯＲＭＡＴＳ”）に見ることができる。本出願の主要な関心事及び処理はファイルをバイナリ表現からクリアテキスト表現へ変換することであるが、上記関連出願に述べられている処理は主としてプリンタ、ＣＲＴ等による文書の出力（ｐｒｅｓｅｎｔａｔｉｏｎ）に関係するものである。
【００２９】
本発明は各種ＳＰＤＬエレメントの情報を管理するためにエレメント・テーブルとサブエレメント・リンクリストを用いる。ＳＰＤＬは階層的に構造化されたページ記述言語であるので、エレメント・テーブル及びサブエレメント・リンクリストの情報を生成するにはＳＰＤＬ内の階層構造を決定する必要があった。
【００３０】
ＳＰＤＬの階層の秩序を決定するため、本願発明者は、規格草案に含まれているＳＰＤＬエレメントの記述を使用し、図４に示すようなＳＰＤＬエレメント状態遷移ダイヤグラムを作成した。図４は、ＳＰＤＬ構造エレメントをツリー構造を用いて図示しており、また、一つのエレメントから出て同じエレメントに戻るラベル付けされたアトリビュート用円弧矢印を示すことにより、様々なＳＰＤＬエレメントに対するアトリビュートを図示している。この状態遷移ダイヤグラムから、本願発明者は本発明に用いられるエレメント・テーブルとサブエレメント・リンクリストを生成することができた。
【００３１】
状態遷移ダイヤグラムの最初のエレメントはＳＰＤＬ１５２である。ＳＰＤＬエレメントの下に出現できる２つの可能なエレメントがある。すなわち、文書エレメント１５４とリソース定義（ｒｅｓｏｕｒｃｅｄｅｆｉｎｉｔｉｏｎ）エレメント１５６である。このリソース定義エレメント１５６はリソース・アトリビュート、ＳＰＤＬＩＤアトリビュート及びファンクション（ｆｕｎｃｔｉｏｎ）アトリビュートというアトリビュートを持つとして示されている。アトリビュートは固定値を持つことも、ユーザによって入力された値を持つこともある。
【００３２】
図４において、特定の階層構造における終端エレメントつまり最も下のエレメントはアスタリスクが付けられており、また、前に定義済みのエレメントはプラス記号が付けられている。特定の階層構造の最低レベルには終端エレメントが存在可能であるが、他のエレメントは存在できない。図４に示したＳＰＤＬエレメント状態遷移ダイヤグラムは完全ではなく、簡略化のためにＳＰＤＬ構造エレメントの一部を省略している。例えば、リソース・スペシフィケーション（ｓｐｅｃｉｆｉｃａｔｉｏｎ）１６４、外部宣言１７２、情報宣言１７４、リソース定義１７６、リソース宣言１７８、ＤＰＩ宣言１８０、コンテキスト（ｃｐｎｔｅｘｔ）宣言１８２、セットアップ・プロシージャ（ｓｅｔ−ｕｐｐｒｏｃｅｄｕｒｅｓ）１８６の下に来る構造エレメントがある。
【００３３】
文書構造エレメント１５４の下にページセット（ｐａｇｅｓｅｔ）エレメント１５８とピクチャー（ｐｉｃｔｕｒｅ）エレメント１６０がある。ページセット１５８の下にページセット・ボディ（ｂｏｄｙ）１６６及びプロローグ（ｐｒｏｌｏｇｕｅ）１７２がある。図４に示されるように、ピクチャー・エレメント１６０はページセット・ボディ１６６の下に出現することも可能である。ピクチャー・エレメント１６０は、コンテント・タイプのアトリビュートとＳＰＤＬＩＤとを有する。ピクチャーエレメント１６０の下に出現可能なＳＰＤＬエレメントはプロローグ１７２とピクチャー・ボディ１６８である。トークン・シーケンス（ｔｏｋｅｎｓｅｑｕｅｎｃｅ）１７０がピクチャー・ボディ１６８の下に出現可能である。プロローグ１７２の下に出現する辞書ジェネレータ（ｄｉｃｔｉｏｎａｒｙｇｅｎｅｒａｔｏｒ）１８４はその下に、サイズのアトリビュートを持つ辞書ジェネレータ・エレメント１８８が出現可能である。辞書１８８の下に出現可能なＳＰＤＬエレメントは辞書ＩＤ１９０、ネーム（ｎａｍｅ）１９４及びトークン・シーケンス１９２である。
【００３４】
図５は、典型的なバイナリＳＰＤＬ文書を１６進表現で示している。図５に示された文書と等価なクリアテキスト文書が図６に示されている。本発明が用いられた場合、図５に示した文書を入力して図６に示した形式へ変換させることができる。図５及び図６に示した文書に対する本発明の作用の説明を行なった後のほうが、図５及び図６の詳細を理解しやすいであろう。
【００３５】
図７は、図５に示された文書が図６に示された文書にどのように対応するかを説明するものである。図７より分かるように、６１はエレメントたるページセットを表わしている。６１の後の５９は、このページセットの長さ（ｌｅｎｇｔｈ）を表わしている。このページセット内にＳＰＤＬＩＤがＡＳＮ．１タグ０６で表わされている。このＳＰＤＬＩＤの長さは４である。実際のＳＰＤＬＩＤである”ＩＳＯ／ＩＥＤ１０１８０／／ＳＰＤＬ”は”２８ＣＦ４４００”によって表わされている。
【００３６】
次に、図７において、ＡＳＮ．１タグ４４はコメントに対応することが分かる。このコメントの長さは１Ｆである。このコメントの内容は”ＳＰＤＬＩＤ＝ＰｕｂｌｉｃＯｂｊｅｃｔＩＤｖａｌｕｅ ”である。次に、Ａ１はページセット・ボディとも呼ばれるところのｐｓｂｏｄｙを表わすことが分かる。図７の残りの部分も同様に理解することができる。したがって、簡略化のために図７における対応関係の完全な説明は省略する。
【００３７】
図８は本発明で使用されるアプリケーション・テーブルを示す。このアプリケーション・テーブルはＡＳＮ．１タグ（アイデンティファイア・オクテット）のバイト値と、それに対応したクリアテキストのアプリケーション・エレメントのネーム（ｎａｍｅ）を記憶している。例えば、ＡＳＮ．１タグの４０Ｈはクリアテキスト・エレメント”ｎａｍｅ”に対応する。また、ＡＳＮ．１タグの６１Ｈ及び６２Ｈは、ページセット（ｐａｇｅｓｅｔ）及びピクチャー（ｐｉｃｔｕｒｅ）なるエレメントにそれぞれ対応することが分かる。当然、本発明で使用される完全なアプリケーション・テーブルは、ＳＰＤＬ構造エレメントそれぞれのための既知のＡＳＮ．１タグと既知のエレメント・ネームを記憶することになる。ＡＳＮ．１タグは公知文献で容易に知ることができるので、ＡＳＮ．１タグそれぞれの完全なリストは提示しない。
【００３８】
図９は、本発明で使用されるＳＰＤＬエレメント・テーブルを示す。このエレメント・テーブルの最初のカラムはエレメント・ネームもしくは同エレメントのクリアテキスト・タグである。次の２つのカラムは、開始タグ及び終了タグが省略可能であるか必要とされるかを示す。ハイフンはタグが必要であることを示し、０はタグがオプショナルであることを示す。なお、ここに開示される本発明の実施例においては、各エレメントの開始タグ及び終了タグが常に用いられる。勿論、エレメント・テーブルの開始タグ・エントリー及び終了タグ・エントリーを使用し、それらがオプショナルの時にタグを省略することも可能である。
【００３９】
エレメント・テーブルの４番目のカラムは、エレメントがプリミティブであるか複合（ｃｏｎｓｔｒｕｃｔｅｄ）であるかを示す。プリミティブはコンテント中に他のエンコーディングがネストされていないことを意味し、複合はコンテント中に他のエンコーディングがネストされていることを意味する。本発明は４番目のカラムを格別に参照することはないが、このプリミティブ／複合情報は他の関連発明で使用されるかのしれないので当該エレメント・テーブルに含まれている。
【００４０】
エレメント・テーブルの５番目のカラムは、エレメント宣言を記憶する。このエレメント宣言は、エレメントの特性の記述である。より具体的には、エレメント宣言は、エレメントのエレメント・ネームについての特性及び従属構造エレメント（それがあるならば）の扱いについての特性に関係する。例えば、ＤＯＣＴＹＰＥ、ＮＯＤＥＣＬＡＲＡＴＩＯＮ、ＯＣＴＥＴＳＴＲＩＮＧ、ＰＲＩＮＴＡＢＬＥＳＴＲＩＮＧは第１のタイプのエレメント宣言である。ＣＨＯＩＣＥ、ＳＥＱＵＥＮＣＥ、ＳＥＱＵＥＮＣＥＯＦＣＨＯＩＣＥは第２のタイプのエレメント宣言である。ＤＯＣＴＹＰＥ宣言は特殊タイプの宣言で、ＤＯＣＴＹＰＥ構造エレメントのためにだけ使用される。ＣＨＯＩＣＥ宣言はエレメント下のサブエレメントの任意の一つをユーザが選択できることを示す。ＳＥＱＵＥＮＣＥ宣言はエレメントの下に出現するサブエレメントは特定の順番で出現しなければならず、この順番は変更できないことを示す。
【００４１】
ＳＥＱＵＥＮＣＥＯＦＣＨＯＩＣＥ宣言はＣＨＯＩＣＥ宣言を繰り返すことにより、２つ以上の従属構造エレメントを選択させる。ＮＯＤＥＣＬＡＲＡＴＩＯＮ宣言はエレメントが従属構造エレメントを１つしか持たないことを意味する。
【００４２】
ＯＣＴＥＴＳＴＲＩＮＧ宣言は、エレメントが８ビット・バイトの文字ストリングであることを示す。ＰＲＩＮＴＡＢＬＥＳＴＲＩＮＧ宣言は、エレメントが印刷可能（ｐｒｉｎｔａｂｌｅ）ストリングであることを示す。
【００４３】
宣言が暗黙的である時、宣言は下に出現するタグに基づいて決定されるから、明示的に記述される必要がないことを意味する。この特徴の詳細は、ＡＳＮ．１等のＳＰＤＬで用いられるエンキコーディングに関する公知文献で知ることができるので、簡略化のため割愛する。
【００４４】
他のＳＰＤＬ文書タイプで他の宣言が用いられるが、これら宣言の詳細は説明の簡略化のため省略する。それらの詳細は、ＳＰＤＬに関する公知文献で知ることができる。本発明は、バイナリＳＰＤＬ文書のシンタックスがＳＰＤＬエンコーディング条件に違反しないようにするためにエレメント宣言を使用することができる。
【００４５】
エレメント・テーブルの６番目のカラムは、エレメントのアトリビュート数を示す。アトリビュートはエレメントの様々な特徴を記述するが、エレメントに対する固有のアトリビュートはサブエレメント・リンクリスト中に見つかる。
【００４６】
エレメント・テーブルの７番目のカラムは、エレメントのサブエレメント数を示す。このサブエレメント数はエレメントの下に出現可能な様々なサブエレメントの個数を示す。エレメント・テーブルの最後のカラムは、エレメントの下に出現可能なサブエレメントに関する情報を記憶しているサブエレメント・リンクリストデータ構造へのポインタである。
【００４７】
図１０は、図９に示したエレメント・テーブルのいずれかのポインタに対応するポインタ２０２により指されるサブエレメント・リンクリストデータ構造２００を示す。このサブエレメント・リンクリストデータ構造２００の最初のエントリー２０４はＡＳＮ．１タグであり、このタグはサブエレメントのバイナリ表現である。サブエレメント・リンクリストデータ構造２００のエントリー２０６はサブエレメント宣言で、エレメント・テーブルに関して述べたエレメント宣言と同様の宣言情報を記憶する。
【００４８】
サブエレメント・リンクリストデータ構造２００のエントリー２０８は、ＡＳＮ．１タグ２０４に対応したクリアテキスト・サブエレメントネームを記憶する。
【００４９】
エントリー２１０はサブエレメント・タイプを記憶する。可能なサブエレメントのタイプは、アトリビュート、オプショナル、デフォルト、またはターミネーティング（ｔｅｒｍｉｎａｔｉｎｇ）であり、これら４つのタイプの組合せも許される。本発明を実施する場合、サブエレメントのタイプは４タイプなら４ビットを用いて表現される。先に述べたサブエレメントの４タイプのいずれにも合致しないときには、サブエレメント・タイプを空白にすることも可能である。
【００５０】
フィールド２１２はサブエレメントのシーケンス番号を記憶しており、このシーケンス番号はサブエレメント・リンクリストデータ構造の番号である。例えば、あるエレメントに対する最初のサブエレメントはシーケンス番号１を有し、あるサブエレメント（２番目のサブエレメント）の最初のリンクリストデータ構造により指されるリンクリストデータ構造はシーケンス番号２を有する。
【００５１】
サブエレメント・リンクリストデータ構造の最後のフィールド２１４は、次のサブエレメント・リンクリストデータ構造へのポインタである。あるエレメントが、その下に出現する多数の様々なサブエレメントを階層構造中に持っている場合、各サブエレメントはそれ自体のリンクリストデータ構造を有する。これらのサブエレメント・リンクリストデータ構造は、あるエレメントの後続サブエレメント・リンクリストデータ構造を指すポインタ２１４によって相互にリンクされる。最後のサブエレメント・リンクリストデータ構造はヌルを指す。
【００５２】
図１１は、ページセットエレメントのためのサブエレメント・リンクリストデータ構造２３０，２４０，２５０を示す。最初のサブエレメントのためのＡＳＮ．１タグは０６で、これはＳＰＤＬＩＤエレメントに対応する。ＳＰＤＬＩＤに対しては宣言がないので、ＳＰＤＬＩＤはアトリビュートである。このＳＰＤＬＩＤは、最初のサブエレメントであるので、２番目のサブエレメントであるプロローグを指す。このプロローグ・サブエレメント・リンクリストデータ構造は、ＰＳＢＯＤＹサブエレメント・リンクリストデータ構造２５０を指す。
【００５３】
図１２に示すピクチャーエレメント、図１３に示すＰＳＢＯＤＹエレメント、及び図１４に示すＰＩＣＢＯＤＹエレメントのためのサブエレメント・リンクリストデータ構造のフィールドは、ページセット・エレメントに関して述べたリンクリストデータ構造のフィールドと同じように記述することができる。
【００５４】
本明細書の作成時点では、ＳＰＤＬ規格は草案段階で未だ完成していない。将来、エレメントまたはサブエレメント宣言がシーケンスである時に使用される”フラグ”エントリーをサブエレメント・リンクリストデータ構造に追加する必要があるかもしれない。しかし、現時点では必要でないので、このフラグは図示したサブエレメント・リンクリストデータ構造には含まれていない。
【００５５】
図１５はバイナリ・ファイルをクリアテキストＳＰＤＬファイルに変換するプロセス中で本発明により使用されるエレメント・スタック３４０を示す。エレメント・スタック３４０のフィールド３４２は、処理されているエレメントのクリアテキスト表現であるところのエレメント・ネームを記憶している。フィールド３４４はエレメントの宣言である。フィールド３４６は、エレメントのアトリビュートを処理するために使用される。エレメントの各アトリビュートの処理後、当該エレメントの処理されたアトリビュートを管理するため、フィールド３４６は１だけデクリメントされる。フィールド３４８は、文書の階層レベルそれぞれのレベル番号を管理するために使用され、また、クリアテキストＳＰＤＬファイルにおける字下げ（ｉｎｄｅｎｔａｔｉｏｎ）レベルを管理するために用いられる。
【００５６】
ＩＮＤＥＦフラグ３５０及びエレメント・レングス（ＥＬＥＭＥＮＴＬＥＮＧＴＨ）フィールド３５２は、バイナリ・エレメントの長さを管理するために使用される。ＩＮＤＥＦフラグ３５０内の”１”はバイナリ・エレメントが不定長フォーマットであることを示す。エレメント・レングスフィールド３５２はバイナリ・エンコーディングが処理されている時にそのバイトのカウントのために使用される。ポインタ３５４は、図１１乃至図１４に示したリンクリストと類似のサブエレメント・リンクリストを指す。
【００５７】
図１５に示したエレメント・スタック３４０が持っているｉｎｄｅｆフラグとエレメント・レングスフィールドは、係属中の米国特許出願第０８／０６６，３８３号（１９９３年５月２１日受理、”ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＦＯＲＰＲＯＣＥＳＳＩＮＧＭＩＸＥＤＢＩＮＡＲＹＬＥＮＧＴＨＥＮＣＯＤＩＮＧＣＯＮＴＡＩＮＩＮＧＤＥＦＩＮＩＴＥＡＮＤＩＮＤＥＦＩＮＩＴＥＬＥＮＧＴＨＦＯＲＭＡＴＳ”）に詳しく述べられており、当該特許出願は引用により本明細書に組み込まれる。エレメント・スタックの他の特徴は係属中の米国特許出願第０８／１４７，６０３号（１９９３年１１月４日受理、”ＳＴＡＮＤＡＲＤＰＡＧＥＤＥＳＣＲＩＰＴＩＯＮＬＡＮＧＵＡＧＥＣＬＥＡＲＴＥＸＴＳＴＲＵＣＴＵＲＥＧＥＮＥＲＡＴＯＲ”）に述べられているエレメント・スタックと幾分類似しており、当該特許出願は引用により本明細書に組み込まれる。
【００５８】
図１６に示すダブル・リンクリストデータ構造（ｄｏｕｂｌｅｌｉｎｋｅｄｌｉｓｔｄａｔａｓｔｒｕｃｔｕｒｅ）３６０は、クリアテキスト変換後情報を管理するために用いられる。一つのバイナリ・エレメントが処理変換される都度、当該エレメントのための情報がダブルリンクリストデータ構造に格納される。バイナリからクリアテキストへの変換が終了した後、ダブル・リンクリストデータ構造のそれぞれの情報が、図６に示した文書に類似した出力ファイルへコピーされる。このダブル・リンクリストは、バイナリ表現ではクリアテキスト表現での順序と違った順序を持つことのあるエレメントの処理に役立つ。
【００５９】
ダブル・リンクリストデータ構造３６０は、ポインタ３６２によって指される。ポインタ３６２は、当該ダブル・リンクリストデータ構造が変換されているファイルのための最初のダブル・リンクリストデータ構造でなければ、一つ前のダブル・リンクリストデータ構造の”ｎｅｘｔ”ポインタに対応する。当該ダブル・リンクリストデータ構造が変換されているファイルの最初のダブル・リンクリストデータ構造ならば、ポインタ３６２は、デフォルト値でよく、システムが当該最初のデータ構造を参照するために使用されるに過ぎない。フィールドレベル番号３６４はエレメントの字下げレベルを示す。エレメント・ネーム３６８はエレメントのクリアテキスト・ネームを示す。エントリー３６８は、そのネームを格納するメモリ領域を指すポインタであることもある。フィールド３７０はエレメントのアトリビュート情報を、それが存在するときに、格納する。フィールド３７０は、アトリビュート情報を格納する別のメモリロケーションへのポインタであることもある。
【００６０】
フィールド３７２はエレメントにより使用されるかもしれないデータを格納する。例えば、エレメントがコメントならば、このデータ・フィールドはコメントのテキストを格納することになろう。このデータ・フィールドは、実際のデータを格納している別のメモリロケーションへのポインタであることもある。フィールド３７４はバックポインタ（ｂａｃｋｐｏｉｎｔｅｒ）であり、これは前のダブルリンクリストデータ構造が存在するならば、それを指すものである。前のダブル・リンクリストデータ構造が存在しないときは、このバックポインタはヌルを指す。ネクスト・ポインタ（ｎｅｘｔｐｏｉｎｔｅｒ）３７６は、次のダブル・リンクリストデータ構造が存在するならば、それを指す。次のダブル・リンクリストデータ構造が存在しないときには、このネクスト・ポインタ３７６はヌルを指す。
【００６１】
図１７は、本発明に使用されるアトリビュート・バッファ３８０を示す。このアトリビュート・バッファ３８０は、エレメントの処理中に該エレメントのアトリビュート情報を一時的に記憶するために用いられる。
【００６２】
図１８乃至図２８は、バイナリＳＰＤＬファイルをクリアテキストＳＰＤＬファイルへ変換するために本発明により用いられるプロセスを示す。図１８のステップ４０２は、入力コマンドライン（ｃｏｍｍａｎｄｌｉｎｅ）を解析して入力ファイルネーム及び出力ファイルネームを確定する。ステップ４０４は、その入力ファイルが存在するか判定する。入力ファイルが存在しないときには、フローはステップ４０６へ進み、入力ファイル不存在を原因とするエラーが表示され、プロセスから抜け出す。入力ファイルが存在するときには、フローはステップ４０８へ進み、出力ファイルが特定済みであるか判定する。出力ファイルが特定済みでなければ、ステップ４１０で出力ファイルにデフォルトのファイルネームが割り当てられる。ステップ４１２は、入力ファイルがＳＰＤＬバイナリ・ファイルであるか判定する。この判定は、ファイルの始まり部分を調べ、それにバイナリＳＰＤＬファイルであることを表示するビットが含まれているかを確かめることによって、行なうことができる。ファイルがバイナリＳＰＤＬファイルであるか判定する方法に関するより詳細な説明は、係属中の米国特許出願第０８／００６，４１６号（”ＭＥＴＨＯＤＡＮＤＳＹＳＴＥＭＴＯＲＥＣＯＧＮＩＺＥＥＮＣＯＤＩＮＧＴＹＰＥＩＮＤＯＣＵＭＥＮＴＰＲＯＣＥＳＳＩＮＧＬＡＮＧＵＡＧＥ”）に見ることができ、当該出願は引用により本明細書に組み込まれる。ステップ４１２で入力ファイルがバイナリＳＰＤＬファイルではないと判定した場合、ステップ４１４は入力ファイルのフォーマットが正しくないことを表示し、プロセスは終了する。入力ファイルがバイナリＳＰＤＬファイルであるならば、フローは図１９に示すプロセスＡに進む。なお、図５，図６及び図７に挙げた例は国際規格草案に基づいているのに対し、米国特許出願第０８／００６，４１６号はそれより後のバージョンに基づいているが、該バージョンは未だ最終的な形で刊行されていない。しかし、いずれのバージョンでも”２８ＣＦ４４００”はバイナリＳＰＤＬエンコーディングを意味する。
【００６３】
図１９のステップ４２０はエレメントスタックを初期化するが、これは単にスタックのためにメモリを予約するに過ぎない。ステップ４２２及びステップ４２４は、クリアテキスト・ファイルの初めの２行をダブル・リンクリストデータ構造に書き込む。クリアテキストＳＰＤＬファイルの初めの２行は常にＤＯＣＴＹＰＥ及びＳＰＤＬであるので、これらの２行を各ＳＰＤＬファイルの始めに書き込む必要がある。
【００６４】
ステップ４２６は入力ファイルよりタグを取得し、ステップ４２８は該タグを調べ、それがＲＥＳＤＥＦであるか判定する。最初のタグがＲＥＳＤＥＦでないときには、ＳＰＤＬエンコーディング規則はクリアテキスト・エンコーディングの第３行が文書エレメントであることを要求する。最初のエレメントタグがＲＥＳＤＥＦであれば、クリアテキスト・エンコーディングの第３行を文書エレメントにする必要はない。ステップ４２８及びステップ４３０より、フローは図２０に示すプロセスＢへ進む。
【００６５】
図２０のステップ４４０は、エレメント・テーブルをサーチしてバイナリタグに対応するエレメントを見つけ、エレメントタグに関する情報、例えば、クリアテキスト・エレメントネームや、開始タグと終了タグがオプショナルであるか必要であるか、エレメントがプリミティブであるか複合であるか、エレメントのアトリビュート数、エレメントのサブエレメント数、エレメントのサブエレメント・リンクリストへのポインタといった情報を取得する。ステップ４４２は入力ファイルより、エレメントの長さ（ｌｅｎｇｔｈ）を示す次のバイトを読み出す。エンコーディングのレングス・オクテット（ｌｅｎｇｔｈｏｃｔｅｔ）が２進の１０００００００である時には、その長さは不定長である。不定長エンコーディングの終わりは、コンテント・オクテット（ｃｏｎｔｅｎｔｓｏｃｔｅｔ）中の００００Ｈにより示される。ステップ４４４でエンコーディングが不定長であると判定した場合、ステップ４４６はＩＮＤＥＦ＿ＬＥＮ＿ＦＬＡＧを真（ｔｒｕｅ）に設定し、エンコーディングが不定長フォーマットであることを表示する。ステップ４４４でエンコーディングが不定長フォーマットではないと判定された場合には、フローはステップ４４８に進み、固定長エンコーディングの値が決定される。ステップ４４８及びステップ４４６より、フローは図２１に示すステップＣへ進む。
【００６６】
図２１において、ステップ４６０はエレメント・スタックが空であるか判定する。空でなければ、ステップ４６２で、エレメント・スタックのトップエントリーより、処理されるタグのバイト数、該タグに使用されるバイト及び該タグのレングス部を減じる必要がある。現タグのレングス・タイプが固定長であるときには、この固定長も減じられる。多くの場合、タグは１バイトで、レングスは１バイトであるので、エレメント・スタックのトップエントリーのレングス・フィールドより２バイトが減じられる。
【００６７】
ステップ４６０及びステップ４６２より、フローはステップ４６４に進み、サブエレメント・リンクリストポインタがヌルであるか判定される。サブエレメント・リンクリストポインタがヌルのときには、エレメントにはサブエレメントが存在しないので、エレメントは終端（ｔｅｒｍｉｎａｌ）エレメントであり、フローはステップ４７４に進み、終端エレメントに関するデータを、対応のダブル・リンクリストデータ構造３６０のポインタ３７２により指されたバッファに格納する。フローはステップ４７６に進み、ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧが真（ｔｒｕｅ）に設定される。フローはステップ４７６より、図２４に示すプロセスＥへ進み、エレメントの情報を新しいダブル・リンクリストに格納する。
【００６８】
ステップ４６４でサブエレメント・リンクリストポインタがヌルでないと判定した場合、エレメントのサブエレメントが存在するので、フローはサブエレメント情報の処理を開始すべくステップ４６８に進む。ステップ４６８はステップ４４０で得られたエレメント情報をエレメント・スタックへプッシュする。フローはステップ４６８から図２２に示すプロセスＤへ進む。
【００６９】
図２２において、ステップ４８０はアトリビュート数（エレメント・スタックに記憶されている）が０より大きいか判定する。アトリビュート数が０より大きくなければ、ステップ４８２はアトリビュート・バッファＡＴＴＲ＿ＢＵＦＦＥＲをヌルに設定し、フローは図２４に示すＥへと進む。アトリビュート数が０より大きいときには、アトリビュートが処理されなければならないので、フローはステップ４８０よりステップ４８４に進み、入力ファイルより次のＡＳＮ．１タグを読み出す。次にステップ４８６は、サブエレメント・リンクリストをサーチして、そのＡＳＮ．１タグが現エレメントのサブエレメントまたはアトリビュートの有効なタグであるかチェックする。サブエレメントがエレメントの正しいＡＳＮ．１サブエレメントならば、フローは図２３に示すプロセスＧへ進む。処理されるエレメントが適切なサブエレメントでないときは、フローはステップ４９０へ進み、タグがコメントであるか判定する。タグがコメントでなければ、サブエレメントはエレメントにとって適切でないので、ステップ４９２はエラーを表示し、プロセスから抜け出る。タグがコメントならば、タグは一つのエレメントとして処理すべく入力ファイルへ書き戻され、フローは場２０のプロセスＢへ戻る。
【００７０】
図２３に示したプロセスＧは、正しいサブエレメントの処理を扱うが、図２２のステップ４８８から始まる。図２３のステップ５００において、サブエレメント・リンクリストより、ＡＳＮ．１タグ値、サブエレメント宣言、サブエレメント・ネーム、サブエレメント・タイプ、サブエレメントの連続番号、次のサブエレメント・リンクリストデータ構造へのネクスト・ポインタのような、サブエレメントに関する情報を取得する。ステップ５０２は、サブエレメント・タイプを調べてサブエレメントがアトリビュートであるか判定する。サブエレメントがアトリビュートならば、ステップ５０８はアトリビュート・データをアトリビュート・バッファＡＴＴＲ＿ＢＵＦＦＥＲに格納し、フローは図２４に示すプロセスＨへ進む。ステップ５０２でサブエレメント・タイプがアトリビュートでないと判定したときには、フローはステップ５０４へ進む。ステップ５０４は、アトリビュートが続いていないことを表示する。エレメントのアトリビュートは、そのエレメントの直後及びそのエレメントのサブエレメントの出現前に現われるべきである。ステップ４８０でアトリビュート数が０より大きいと判定した場合にはフローはステップ５０２へ到達し、サブエレメントはアトリビュートのはずである（アトリビュートである必要はないが）。サブエレメントがアトリビュートでないならば、現サブエレメントに続くアトリビュートは不適切なものであろう。本発明は、図２８に示したフローチャートのステップ６０６，６０８により、そのようなアトリビュートを、その後に出現した時にきちんと整える。ステップ５０４の後に、ステップ５０６は不適切なタグを入力ファイルに書き戻し、フローは次の処理のため図２４のプロセスＥに進む。
【００７１】
図２４のプロセスＨはアトリビュートであるサブエレメントの処理を扱う。図２４のステップ５２０は、エレメント・スタックのトップエントリーより、アトリビュート数を減じる。ステップ５２２はエレメント・スタック内のアトリビュート数を１だけデクリメントする。ステップ５２４は、エレメント・スタック内のアトリビュート数が０より大きいか判定する。アトリビュート数が０より大きいときには、別のアトリビュートを処理しなければならないのでフローはステップ５２６へ進む。ステップ５２６はアトリビュート・バッファに新しい１行キャラクタを格納し、残りのアトリビュートの処理のためフローは図２２に示すプロセスＦへ進む。
【００７２】
ステップ５２４でアトリビュート数が０より大きいと判定した場合、フローはステップ５２８に進み、処理エレメントに関する、エレメントネーム、レベル番号、アトリビュート・バッファ、データ情報、ネクストポインタ及び前ポインタを含む情報の全てが新しいダブル・リンクリストデータ構造に格納される。ステップ５２８より、フローは図２５に示すプロセスＩへ進む。
【００７３】
ステップ５４０はＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧが真（ｔｒｕｅ）であるか判定する。ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧは図２１のステップ４７６で真に設定されている。このフラグが設定されていないならば、ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧのデフォルト値は偽（ｆａｌｓｅ）である。それが真ならば、フローはステップ５４２へ進んで現エレメントが終端エレメントであることを表示し、該エレメントのためのエレメント終了タグが新しいダブル・リンクリストデータ構造に書き込まれる。そしてステップ５４４は、ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧを偽に設定する。
【００７４】
ステップ５４０，５４４の次に、ステップ５４６はＩＮＤＥＦ＿ＬＥＮ＿ＦＬＡＧが真であるか判定する。それが真ならば、フローは不定長フォーマットの処理のため図２６に示したプロセスＪへ進む。そうでなければ、フローはステップ５４８へ進み、エレメントスタックのトップエントリーのエレメント・レングスが０であるか判定される。このレングスが０でなければ、エレメントは固定長であるので、エレメントの全長は処理が終わっておらず、さらに処理するため図２８に示すプロセスＫへ進む。そうでなければ、エレメント・スタックのトップエントリーのレングスは０であり、エレメント・スタックのトップエントリーにある現エレメントは処理が終了し、ステップ５５０はエレメントスタックのトップエレメントの終了タグを新しいダブル・リンクリストデータ構造に書き込む。ステップ５５０より、フローは図２７のＬへ進む。
【００７５】
図２６に示したプロセスＪは不定長フォーマットの処理を扱う。ステップ５６０は入力ファイルにおける現在位置を変数ＦＰＯＳへセーブする。ステップ５６２は入力ファイルより次の２バイトを読み出す。ステップ５６４は、この２バイトの両バイトが０であるか判定する。そうであるならば、不定長コーディング・フォーマットの終わりを意味しているので、フローはステップ５６６に進み、処理されている現エレメントの終了タグがダブル・リンクリストデータ構造に書き込まれ、そしてフローは図２７のＬへ進む。終了フラグに達しないときには、フローはステップ５６４からステップ５６８へ進み、ステップ５６２で読み出されたファイルの最後の２バイトを処理できるように、入力ファイルのポインタが再び位置ＦＰＯＳを指すよう調整される。ステップ５６８よりフローは図２８のＫへ進む。図２７に示したプロセスＬにおいて、ステップ５７６は現エレメントが不定長フォーマットであって、かつ現エレメントの下にエントリーが存在するかを判定する。そうならば、ステップ５７８で、エレメント・スタック内の該下のレベルのレングス・エントリーが、現エレメントのレングス（これは負の値である）を該下のレベルのレングス・エントリーに加算することによって調整される。そしてステップ５８０はエレメント・スタックのトップエントリーをポップする。
【００７６】
ステップ５８２でエレメント・スタックが空であると判定し、かつ、ステップ５８４で処理すべきデータがまだあると判定したときには、フローはステップ５８６へ進んでダブル・リンクリストデータ構造から出力ファイルへデータがコピーされ、プロセスは終了する。エレメント・スタックが空ではないか処理すべきデータがまだあるならば、フローは図２８に示すプロセスＫへ進む。
【００７７】
図２８において、ステップ５９０はバイナリ入力ファイルの次のタグを読み出す。ステップ５９２は、そのタグがコメントであるか判定し、コメントであるときは現エレメントがコメントに設定され、フローは図２０に示すプロセスＢへ進む。該次のタグがコメントでなければ、フローはステップ５９２からステップ５９６へ進み、サブエレメントの有効性を確認するためにサブエレメントリンクリストがサーチされる。このステップは、現サブエレメントが処理されているエレメントの下に出現することが許されるか判定する。ステップ５９８がサブエレメントを有効でないと判定したときには、不正のサブエレメントであるのでステップ６００でエラーが表示されプロセスを抜け出す。ステップ５９８でサブエレメントが有効であると判定したときには、フローはステップ６０２へ進む。
【００７８】
ステップ６０２において、エレメント・スタック内のトップエレメントのアトリビュート数が０より大きいか調べられる。０より大きくないときには、サブエレメントはアトリビュートでないのでフローはプロセスＢへ進む。エレメント・スタックのトップエントリーにおけるアトリビュート数が０より大きいときは、フローはステップ６０４へ進みサブエレメントがアトリビュートであるか判定する。ステップ６０４でサブエレメントがアトリビュートでないと判定したならば、フローはプロセスＢへ進む。ステップ６０４でサブエレメントがアトリビュートであると判定したときには、ステップ６０６はエレメント・スタックのトップエントリーのエレメント情報を見つけるためダブル・リンクリストをサーチする。次にステップ６０８はアトリビュートをアトリビュート・バッファに格納する。そして、フローは図２５に示すプロセスＭへ進む。
【００７９】
図２９及び図３０は、図５に示したバイナリ・ファイルが図６に示したクリアテキスト・ファイルへ変換される時に作られるダブル・リンクリストデータ構造を示す。最初のダブル・リンクリストデータ構造７００は、字下げレベルが０であり、エレメントネームが！ＤＯＣＴＹＰＥであり、アトリビュートもデータも持たず、（ネクスト・ポインタが）ダブル・リンクリストデータ構造７１０を指す。ダブル・リンクリストデータ構造７１０は、字下げレベルが０であり、ＳＰＤＬとネームが付けられ、データフィールドにアトリビュートもデータも持たず、（バックポインタが）ダブル・リンクリストデータ構造７００を指し、（ネクストポインタが）次のダブル・リンクリストデータ構造７２０を指す。
【００８０】
ダブル・リンクリストデータ構造７２０は、（ネクスト・ポインタが）ダブル・リンクリストデータ構造７３０を指す。このダブル・リンクリストデータ構造７３０は、字下げレベルが１であり、ページセットのエレメントを持ち、アトリビュートＳＰＤＬＩＤを定義され、（ネクスト・ポインタが）ダブル・リンクリストデータ構造７４０を指す。ダブル・リンクリストデータ構造７４０は、字下げレベルが２のコメントであり、アトリビュートを持たないが、コメントの内容を含むデータを持つ。なお、ダブル・リンクリストデータ構造７４０のＤＡＴＡ＿ＨＥＡＤエントリーは、実際のデータを指すところのリンクリストデータ構造を指す。ダブル・リンクリストデータ構造７４０のＤＡＴＡ＿ＨＥＡＤエントリーにより指されたれたリンクリストデータ構造のネクストエントリーが次のリンクリストデータ構造を指すことがある。
【００８１】
ダブル・リンクリストデータ構造７４０は、（ネクストポインタが）図３０に示すダブル・リンクリストデータ構造７６０を指す。図３０に示すデータ構造は、図２９に示したデータ構造と同様に説明できる。なお、簡略化のため、ダブル・リンクリストデータ構造７８０とダブル・リンクリストデータ構造８００の間のデータ構造は省略されているが、本発明のプロセスを辿り、及び／または図６に示したクリアテキストの例をよく見ることにより、省略されたデータ構造を確認し得る。
【００８２】
図３１乃至図３５は、図５及び図６に示した例が処理される時のエレメントスタックを示す。エレメント・スタック内のポインタによって指されるサブエレメント・リンクリストは、一定のままであるので、図１１乃至図１４に示す同じゼネラルタイプのリンクリストとなろう。
【００８３】
バイナリＳＰＤＬファイルが本発明により処理される様子の例を示すため、図１８乃至図２８に示したフローチャートに戻る。本発明のプロセスは図１８から始まるが、入力ファイルと出力ファイルが特定されフローが図１９へ進んだと仮定する。ステップ４２２は図２９に示すダブル・リンクリストデータ構造７００を生成する。ステップ４２４は図２９に示したダブル・リンクリストデータ構造７１０を生成する。次にステップ４２６は、図５に示すファイルで最初に現われるエレメントであるエレメントタグバイト６１を読み出す。このエレメント６１はＰＡＧＥＳＥＴに対応しエレメントＲＥＳＤＥＦには対応しないので、フローはステップ４３０へ進み、図２９のダブル・リンクリスト７２０を生成する。そしてフローは図２０のプロセスＢへ進む。ステップ４４０は、ＰＡＧＥＳＥＴのようなエレメント・ネームやステップ４４０に列挙された他の全情報を含む、エレメント６１に関する情報を取得する。入力ファイルの次のバイトは５９であり、これはＰＡＧＥＳＥＴの固定長値である。したがって、フローはステップ４２２からステップ４４４、ステップ４４８と進み、図２１のステップ４６０へ進む。
【００８４】
図２１において、ステップ４６０は、エレメント・スタックにはエレメントが全くプッシュされていないので、エレメント・スタックが空であると判定する。ステップ４６４はサブエレメント・リンクリストがヌルでないと判定し、フローはステップ４６８へ進み、エレメント情報をエレメント・スタックへプッシュする。この時のエレメント・スタックは図３１に示す如きである。そしてフローは図２２に示すプロセスＤへ進む。
【００８５】
ＰＡＧＥＳＥＴのアトリビュート数は０より大きいので、フローはステップ４８０からステップ４８４へ進み、入力ファイルより次のＡＳＮ．１タグである０６が取り出される。０６はＰＡＧＥＳＥＴの適切なサブエレメントであるので、フローはステップ４８８から図２３に示したプロセスＧへ進む。ステップ５００はサブエレメントの情報を読み出し、ステップ５０２はサブエレメントがアトリビュートであると判定する。ＰＡＧＥＳＥＴエレメントは一つのアトリビュートを有し、ＰＡＧＥＳＥＴの最初のサブエレメントがアトリビュートであるから、このアトリビュートは順序通りであるので、フローはステップ５０８へ進み、アトリビュートデータはアトリビュート・バッファＡＴＴＲ＿ＢＵＦＦＥＲへ格納される。そしてフローは図２４に示すプロセスＨへ進む。
【００８６】
図２４において、ステップ５２０はエレメント・スタックのトップエントリーよりアトリビュートのレングスを差し引く。ＳＰＤＬＩＤのレングスは４バイトであるので、４に、レングス情報のバイト数、ＳＰＤＬＩＤのバイト数及びＰＡＧＥＳＥＴのバイト数を足した値が図３１に示したスタックより減じられる。最初のアトリビュートの処理が済んだのでステップ５２２はアトリビュート数を１だけ減らし、またＰＡＧＥＳＥＴはアトリビュートを１個しか持たないのでフローはステップ５２４からステップ５２８へ進み、エレメントの情報が図２９に示す新しいダブルリンクリストデータ構造７３０に格納される。ＰＡＧＥＳＥＴは図６の最初の字下げレベルであるので、ダブル・リンクリストデータ構造７３０のレベル番号エントリーは１に設定される。ステップ５２８より、フローは図２５に示すプロセスＩへ進む。
【００８７】
ＴＥＲＭＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧは偽（ｆａｌｓｅ）に初期化されているので、フローはステップ５４０からステップ５４６へ、そしてステップ５４８へと進み、エレメントスタックのトップエントリーのエレメント・レングスは０ではないと判定される。そしてフローは図２８に示すプロセスＫへ進む。
【００８８】
図２８において、ステップ５９０は入力ファイルより次のＡＳＮ．１タグを読み出すが、同タグは４４である。このタグはコメントタグであるので、ステップ５９４は現エレメントをコメントととし、フローは図２０に示すプロセスＢへ進む。
【００８９】
図２０において、ステップ４４０はエレメント・テーブルをサーチしてコメントに関する情報を取得し、ステップ４４８はコメントの固定長値を取得するが、この固定長値は１Ｆである。フローはステップ４６０に進み、エレメント・スタックが空でないことを確認し、ステップ４６２においてコメントのレングスがスタック内のＰＡＧＥＳＥＴのエレメントレングス・エントリーより差し引かれる。次にステップ４６４は、コメント・エレメントがサブエレメントを全く持たないので、サブエレメント・リンクリスト・ポインタがヌルであると判定する。ステップ４７４で、コメントに含まれる情報はデータバッファ・リンクリストデータ構造に格納される。次にステップ４７６は変数ＴＥＲＭＩＮＡＬ＿ＥＮＴＲＹ＿ＦＬＡＧを真に設定し、フローは図２４に示すプロセスＥへ進む。
【００９０】
図２４において、ステップ５２８はコメントの情報を図２９に示すダブル・リンクリストデータ構造７４０に格納する。そしてフローは図２５に示すプロセスＩへ進む。ステップ５４０１での判定結果はＹＥＳである。この変数は図２１のステップ４７６で真に設定されているからである。次にフローはステップ５４２に進み、エレメント終了タグが図３０に示すダブル・リンクリストデータ構造７６０に書き込まれる。フローはステップ５４６、ステップ５４８と進み、図２８に示すプロセスＫへ進む。
【００９１】
図２８のステップ５９０は入力ファイルより次のＡＳＮ．１タグを読み出すが、このタグはページセット・ボディに対応するＡ１である。そしてフローはステップ５９２からステップ５９６，５９８，６０２と進み、次に図２０に示すプロセスＢへ進む。
【００９２】
図２０において、ページセット・ボディの情報を取得するためエレメント・テーブルがサーチされる。次にフローは図２１に示すプロセスＣへ進み、ステップ４６２は図３１に示すスタック８５０内のＰＡＧＥＳＥＴエントリーのエレメント・レングス・エントリーから、ページセット・ボディ・エレメントのレングスを減じる。ステップ４６４はページセットボディのサブエレメント・リンクリストポインタがヌルでないと判定するので、フローはステップ４６８へ進み、ＰＡＧＥＳＥＴのエレメント情報をエレメント・スタックへプッシュする。これで、エレメント・スタックは図３２に示すようになる。
【００９３】
同様にして、図５に示すバイナリ・ファイルの残りの部分が本発明のフローチャートに従って処理されることにより、図３３乃至図３５に示すエレメント・スタックと図２９及び図３０に示すダブル・リンクリストデータ構造が得られる。フローチャートのこれ以上の追跡は、簡略化のため省略する。
【００９４】
図３６は本発明のプロセスを実行するために利用可能なワークステーション１０００の構成を示す。ワークステーション１０００はＣＰＵ９５０、ＲＡＭ９５２、ＲＯＭ９５４、キーボード９５８及びマウス９６０がつながれた入力コントローラ９５６を含む。印刷エンジンインターフェイス９６４は印刷エンジン９６２に直接接続され、印刷エンジン９６２はインターフェイス９６４により伝達されるイメージデータを表わすビデオ制御信号を受け取る。このワークステーションはさらに、ハードディスク９６８及びフロッピードライブ９７０とつながれたディスクコントローラ９７２、ネットワーク９８４（例えばＥｔｈｅｒｎｅｔ（登録商標）ネットワーク）との接続のための通信コントローラ９７４、外部ハードディスク９８０と例えばＳＣＳＩバスにより、またプリンタ９７８と例えばＲＳ−２３２Ｃケーブルにより接続されたＩ／Ｏコントローラ９７６を含む。ワークステーションはＣＲＴ９８６と接続されたディスプレイコントローラ９８２も含む。システムバス９６６はワークステーション内の各要素を接続する。
【００９５】
本発明のプロセスは図３６に示す記憶デバイスのどれに格納してもよい。さらに、本発明のプロセスの動作中に、プロセス中で生成され使用されるデータは図３６に示した記憶デバイスのどれに格納してもよい。
【００９６】
なお、本発明で使用されたデータ構造は、本願発明者による他の発明のいくつかで使用できる。これらの他の発明は本発明のフローチャートで使用されたデータフィールドより余分のデータフィールドを必要とするかもしれないので、本発明を構成するために各データ構造に示したフィールドの全ては必要でないかもしれない。さらに、ＳＰＤＬ規格は草案段階で発展中である。したがって、生成されたデータ構造の一部は、規格の変更によりもう必要でないフィールドを、あるいは、規格が変更される可能性の故に存在するフィールドを持っているかもしれない。
【００９７】
なお、付記するならば、下記方法及び装置は本発明の範囲に包含されるものである。
【００９８】
（１）ファイルのフォーマットを変換する方法で、次のステップを有する：
バイナリファイルを入力するステップ；
該バイナリファイルのエレメントをテキストフォーマットへ変換するステップ；
該エレメントの該テキストフォーマットを第１のバッファに書き込むステップ；
該エレメントのためにアトリビュートが必要とされるか確認するステップ；該バイナリファイルのサブエレメントが該エレメントのアトリビュートであるか、または該サブエレメントが該エレメントのアトリビュートでないか判定するステップ；
該サブエレメントをテキストフォーマットへ変換するステップ；
該サブエレメントが該エレメントのアトリビュートでないと判定され、かつ、該エレメントのためにアトリビュートが必要とされると確認された時に、次のステップを実行するステップ：
該エレメントの該サブエレメントの該テキストフォーマットを第２のバッファに書き込むステップ；
該必要とされるアトリビュートに出会うまで該バイナリファイルを処理するステップ；
該必要とされるアトリビュートをテキストフォーマットへ変換するステップ；
該必要とされるアトリビュートの該テキストフォーマットを該エレメントを格納している該第１バッファに書き込むステップ；
該サブエレメントがアトリビュートであると判定され、かつ、該第１のエレメントのためにアトリビュートが必要とされると確認された時に、次のステップを実行するステップ：
該サブエレメントの該テキストフォーマットを該第１バッファに書き込むステップ。
【００９９】
（２）前記（１）の方法において、
該エレメントの該サブエレメントの該テキストフォーマットを第２バッファに書き込むステップは、該エレメントの該サブエレメントの該テキストフォーマットを該第１バッファを参照する該第２バッファに書き込み、かつ該方法は、該サブエレメントが該エレメントのアトリビュートでないと判定された後に実行される次のステップをさらに有する：
該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該第２バッファから逆向きに辿って該第１バッファを見つけるステップ。
【０１００】
（３）前記（１）の方法において、該第２バッファは、該第１バッファを後方参照しかつ次のバッファを前方参照するダブルリンクリストであり、かつ該サブエレメントの該テキストフォーマットを該第２バッファに書き込むステップは、該サブエレメントの該テキストフォーマットを該ダブルリンクリストに書き込み、
該方法はさらに、該サブエレメントが該エレメントのアトリビュートではないと判定された後に実行される次のステップを有する：
該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該ダブルリンクリストから逆向きに辿って該第１バッファを見つけるステップ。
【０１０１】
（４）以下の手段を有するファイルのフォーマットを変換するための装置：
バイナリファイルを入力するための手段；
該バイナリファイルのエレメントをテキストフォーマットへ変換するための手段；
該エレメントの該テキストフォーマットを第１のバッファに書き込むための手段；
該エレメントのためにアトリビュートが必要とされるか確認するための手段；
該バイナリファイルのサブエレメントが該エレメントのアトリビュートであるか、または該サブエレメントが該エレメントのアトリビュートであるかを判定するための手段；
該サブエレメントを該テキストフォーマットへ変換するための手段；
該サブエレメントが該エレメントのアトリビュートでないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該エレメントの該サブエレメントの該テキストフォーマットを第２のバッファに書き込むための手段；
該サブエレメントが該エレメントのアトリビュートでないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該必要とされるアトリビュートに出会うまで該バイナリファイルを処理するための手段；
該サブエレメントが該エレメントのアトリビュートではないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該必要とされるアトリビュートを該テキストフォーマットへ変換するための手段；該サブエレメントが該エレメントのアトリビュートではないと判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むための手段；及び
該サブエレメントがアトリビュートであると判定されかつ該エレメントのためにアトリビュートが必要とされると確認された時に、該サブエレメントの該テキストフォーマットを該第１バッファに書き込むのための手段。
【０１０２】
（５）前記（４）の装置において：
該エレメントの該サブエレメントの該テキストフォーマットを該第２バッファに書き込むための手段は、該第１バッファを参照する該第２バッファに該エレメントの該サブエレメントの該テキストフォーマットを書き込み、かつ該装置はさらに次の手段を有する：
該サブエレメントが該エレメントのアトリビュートではないと判定された後、該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該第２バッファから逆向きに辿って該第１バッファを見つけるための手段。
【０１０３】
（６）前記（４）の装置において、該エレメントの該サブエレメントの該テキストフォーマットを該第２バッファに書き込むための手段は、該第１バッファを後方参照しかつ次のバッファを前方参照するダブルリンクリストであるところの該第２バッファに、該エレメントの該サブエレメントの該テキストフォーマットを書き込み、かつ該装置はさらに次の手段を有する：
該サブエレメントが該エレメントのアトリビュートでないと判定された後、該必要とされるアトリビュートの該テキストフォーマットを該エレメントを記憶している該第１バッファに書き込むステップを実行する前に、該ダブルリンクリストより逆向きに辿って該第１バッファを見つけるための手段。
【０１０４】
（７）ファイルのフォーマットを変換するための方法で次のステップを有する：
バイナリファイルを入力するステップ；
該バイナリファイルのエレメントをテキストフォーマットへ変換するステップ；
該エレメントの該テキストフォーマットを第１のバッファに書き込むステップ；
該エレメントの許容されるサブエレメントを記憶しているデータ構造を辿って調べることにより、該バイナリファイルの該エレメントのサブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが該エレメントの許容されないサブエレメントであるか判定するステップ；
該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時にエラーを表示するステップ；及び
該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時に、該バイナリファイルの後続部分をテキストフォーマットへ変換するステップ。
【０１０５】
（８）前記（７）の方法において、該判定のステップは、該エレメントの許容されるサブエレメントをそれぞれ記憶しているサブエレメントリンクリストデータ構造を辿って調べることにより、該エレメントの該サブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが該エレメントの許容されないサブエレメントであるか判定し、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つかるならば該サブエレメントは許容されると判定され、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つからなければ該サブエレメントは許容されないと判定される。
【０１０６】
（９）次の手段を有する、ファイルのフォーマットを変換する装置：
バイナリファイルを入力するための手段；
該バイナリファイルのエレメントをテキストフォーマットへ変換するための手段；
該エレメントの該テキストフォーマットを第１のバッファに書き込むための手段；
該エレメントの許容されるサブエレメントを記憶しているデータ構造を辿って調べることにより、該バイナリファイルの該エレメントのサブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが該エレメントの許容されないサブエレメントであるか判定するための手段；該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時にエラーを表示するための手段；及び
該サブエレメントが該エレメントの許容されないサブエレメントであると判定された時に、該バイナリファイルの後続部分を該テキストフォーマットへ変換するための手段。
【０１０７】
（１０）前記（９）の装置において、該判定のための手段は、該エレメントの許容されるサブエレメントをそれぞれ記憶しているサブエレメントリンクリストデータ構造を辿って調べることにより、該エレメントの該サブエレメントが該エレメントの許容されるサブエレメントであるか、または該サブエレメントが許容されないサブエレメントであるか判定し、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つかるならば該サブエレメントは許容されると判定され、該サブエレメントが該サブエレメントリンクリストデータ構造中に見つからなければ該サブエレメントは許容されないと判定される。
【０１０８】
（１１）固定長エンコーディングがネストされた不定長エンコーディングのフォーマットをバイナリからテキストへ変換する方法であり、該不定長エンコーディング及び該固定長エンコーディングは両方ともプリアンブル情報及びコンテント情報を含み、該方法は次のステップを有する：
バイナリファイルを入力するステップ；
該不定長エンコーディングの該プリアンブル情報を処理して該不定長エンコーディングの該プリアンブル情報のバイナリ表現をテキスト表現へ変換するステップ；
次のステップを実行することによって、該固定長エンコーディングを含む該不定長エンコーディングの該コンテント情報を処理するステップ：
該固定長エンコーディングの該プリアンブル情報を処理して該固定長エンコーディングのコンテント情報のバイト数を確認するステップ；
及び
該固定長エンコーディングのコンテント情報のバイナリ表現をテキスト表現へ変換することにより、該不定長エンコーディングの終わりを示すマーカーが存在するか判定することなく、該固定長エンコーディングのコンテント情報のバイト数が処理されるまでバイトを処理することによって該固定長エンコーディングの該コンテント情報を処理するステップ；
該固定長エンコーディングの該コンテント情報を処理した後、該固定長エンコーディングの該コンテント情報の後の該不定長エンコーディングのバイトを調べ該不定長エンコーディングの終わりを示すマーカーを捜すステップ；及び該固定長エンコーディングの該コンテント情報の後のバイトが該不定長エンコーディングの終わりを示すならば、該不定長エンコーディングの処理を終了させるステップ。
【０１０９】
（１２）前記（１１）の方法で、さらに次のステップを有する：
該固定長エンコーディングの該コンテント情報に続くバイトが該不定長エンコーディングの終わりを示さないならば、該固定長エンコーディングに続くバイトを、該不定長エンコーディング中にネストされた次のプロシージャとして処理するステップ。
【０１１０】
（１３）固定長エンコーディングがネストされた不定長エンコーディングのフォーマットをバイナリからテキストへ変換する方法であり、該不定長エンコーディング及び該固定長エンコーディングは両方ともプリアンブル情報及びコンテント情報を含み、該方法は次のステップを有する：
該不定長エンコーディングの該プリアンブル情報を処理して該プリアンブル情報のバイナリ表現をテキスト表現へ変換するステップ；
次のステップを実行することによって、該固定長エンコーディングを含む該不定長エンコーディングの該コンテント情報を処理するステップ：
該固定長エンコーディングの該プリアンブル情報を処理して該固定長エンコーディングの該コンテント情報のバイト数を確認し、該固定長エンコーディングの該コンテント情報のバイト数を一時的記憶手段に格納し、かつ、該固定長エンコーディングのバイナリ表現をテキスト表現へ変換するステップ；及び
該不定長エンコーディングの終わりを示すマーカーが該不定長エンコーディング中に存在するか判定することなく、該一時的記憶手段に記憶された該コンテント情報バイト数が処理されるまでバイトを処理することによって該固定長エンコーディングの該コンテント情報を処理し、該固定長エンコーディングの該コンテント情報が処理されている時に、該固定長エンコーディングの処理が済んだバイト数を該一時的記憶手段にカウントするステップ；
該固定長エンコーディングの該コンテント情報を処理した後、該固定長エンコーディングの該コンテント情報の後の該不定長エンコーディングのバイトを調べ該不定長エンコーディングの終わりを示すマーカーを捜すステップ；及び該固定長エンコーディングの該コンテント情報の後のバイトが該不定長エンコーディングの終わりを示すならば該不定長エンコーディングの処理を終了させるステップ。
【０１１１】
（１４）前記（１３）の方法において、該固定長エンコーディングの該コンテント情報の該バイト数を格納するステップは、そのレングス情報をスタックにプッシュし；かつ
該固定長エンコーディングの該コンテント情報を処理するステップは、該不定長エンコーディングの終わりを示すマーカーが該不定長エンコーディング中に存在するか判定することなく、該スタック上の該コンテントのバイト数が処理されるまでバイトを処理し、該固定長エンコーディングの該コンテント情報が処理されている時に、該固定長エンコーディングの処理の済んだバイト数を該スタックにカウントする。
【０１１２】
（１５）不定長エンコーディングがネストされた第１の固定長エンコーディングのフォーマットをバイナリからテキストへ変換する方法であり、該不定長エンコーディングは第２の固定長エンコーディングがネストされており、該不定長エンコーディング並びに該第１及び該第２の固定長エンコーディングはそれぞれプリアンブル情報及びコンテント情報を含み、該方法は次のステップを有する：
該第１固定長エンコーディングの該プリアンブル情報を処理し該プリアンブル情報をバイナリ表現からテキスト表現へ変換するステップ；
次のステップを実行することにより該第１固定長エンコーディングの該コンテント情報を処理するステップ：
該不定長エンコーディングの該プリアンブル情報を処理し、該不定長エンコーディングの該プリアンブル情報が処理されている時に、該不定長エンコーディングの該プリアンブル情報の処理されたバイト数を一時的記憶手段の第１のエントリーにカウントし、該不定長エンコーディングの該プリアンブル情報をバイナリ表現からテキスト表現へ変換するステップ；
次のステップを実行することにより該不定長エンコーディングの該コンテント情報を処理するステップ：
該第２固定長エンコーディングの該プリアンブル情報を処理して該第２固定長エンコーディングの該コンテント情報のバイト数を確認し、該第２固定長エンコーディングの該コンテント情報のバイト数を該一時的記憶手段の第２のエントリーに格納し、該第２固定長エンコーディングの該プリアンブル情報が処理されている時に、該第２固定長エンコーディングの処理されたバイト数を該一時的記憶手段の該第１エントリーにカウントし、該第２固定長エンコーディングのバイナリ表現をテキスト表現へ変換するステップ；及び
該不定長エンコーディングの終わりを示すマーカーが該エンコーディング中に存在するか判定することなく、該第２固定長エンコーディングの該コンテント情報のバイト数が処理されるまで該第２固定長エンコーディングを処理することによって該第２固定長エンコーディングの該コンテント情報を処理し、該第２固定長エンコーディングの該コンテント情報が処理されている時に、該第２固定長エンコーディングの処理されたバイト数を該一時的記憶手段の該第２エントリーにカウントするステップ；
該第２固定長エンコーディングの該コンテント情報を処理した後、該第２固定長エンコーディングの該コンテント情報の後の該エンコーディングのバイトを調べ、該不定長エンコーディングの終わりを示すバイトを捜すステップ；
該第２固定長エンコーディングの該コンテント情報に続くバイトが該不定長エンコーディングの終わりを示すならば、該不定長エンコーディングの処理を終了させるステップ；及び
該第１固定長エンコーディングのコンテントの後続バイトを、該第１固定長エンコーディングの全バイトが処理されるまで処理するステップ。
【０１１３】
【発明の効果】
以上、詳細に説明したところから理解されるように、本発明によれば、バイナリフォーマットをクリアテキストフォーマットへ変換する際に解決すべき前記したような諸課題を解決し、文書のバイナリフォーマットからクリアテキストフォーマットへの変換が可能になる。
【図面の簡単な説明】
【図１】バイナリ・エンコーディングの固定長フォーマット及び不定長フォーマットのネスティングの一例を示す図である。
【図２】ＩＳＯ／ＩＥＣ８８２５によるエンコーディングの構造を示す図である。
【図３】ＩＳＯ／ＩＥＣ８８２５によるアイデンティファイア・オクテットの構造を示す図である。
【図４】ＳＰＤＬエレメント状態遷移ダイヤグラムの部分図である。
【図５】バイナリ・エンコードのＳＰＤＬ文書サンプルの１６進表現を示す図である。
【図６】図５に示したバイナリ文書のクリアテキスト表現を示す図である。
【図７】図５に示したバイナリ・エレメントと図６に示したクリアテキスト・エレメントとの対応を示す図である。
【図８】ＡＳＮ．１タグ及び対応のクリアテキスト・エレメントを示すアプリケーション・テーブルを示す図である。
【図９】ＳＰＤＬ構造エレメントに関する情報を格納するために用いられるエレメント・テーブルを示すずである。
【図１０】エレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造の説明図である。
【図１１】図９に示したエレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造のサンプルを示す図である。
【図１２】図９に示したエレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造のサンプルを示す図である。
【図１３】図９に示したエレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造のサンプルを示す図である。
【図１４】図９に示したエレメント・テーブルにより指されるサブエレメント・リンクリストデータ構造のサンプルを示す図である。
【図１５】本発明の変換プロセスに用いられるエレメント・スタックを示す図である。
【図１６】各ラインのクリアテキスト表現を、出力ファイルに書き出されるまで記憶するため使用されるダブル・リンクリストデータ構造を示す図である。
【図１７】本発明に使用されるアトリビュート・バッファを示す図である。
【図１８】本発明で用いられるプロセスを記述したフローチャートである。
【図１９】本発明で用いられるプロセスを記述したフローチャートである。
【図２０】本発明で用いられるプロセスを記述したフローチャートである。
【図２１】本発明で用いられるプロセスを記述したフローチャートである。
【図２２】本発明で用いられるプロセスを記述したフローチャートである。
【図２３】本発明で用いられるプロセスを記述したフローチャートである。
【図２４】本発明で用いられるプロセスを記述したフローチャートである。
【図２５】本発明で用いられるプロセスを記述したフローチャートである。
【図２６】本発明で用いられるプロセスを記述したフローチャートである。
【図２７】本発明で用いられるプロセスを記述したフローチャートである。
【図２８】本発明で用いられるプロセスを記述したフローチャートである。
【図２９】図５に示されたバイナリ文書の変換中に生成されるダブル・リンクリストデータ構造の一部を示す図である。
【図３０】図５に示されたバイナリ文書の変換中に生成されるダブル・リンクリストデータ構造の一部を示す図である。
【図３１】図５に示された文書の変換中におけるエレメント・スタックのステータスを示す図である。
【図３２】図５に示された文書の変換中におけるエレメント・スタックのステータスを示すずである。
【図３３】図５に示された文書の変換中におけるエレメント・スタックのステータスを示す図である。
【図３４】図５に示された文書の変換中におけるエレメント・スタックのステータスを示す図である。
【図３５】図５に示された文書の変換中におけるエレメント・スタックのステータスを示す図である。
【図３６】本発明のハードウエア構成例を示すブロック図である。
【符号の説明】
２３０〜３３０サブエレメント・リンクリストデータ構造
３４０エレメントスタック
３６０ダブル・リンクリストデータ構造
３７４バックポインタ
３７６ネクストポインタ
３８０アトリビュートバッファ
７００〜８１０ダブル・リンクリストデータ構造
８５０エレメントスタック
９５６入力コントローラ
９５８キーボード
９６０マウス
９６２印刷エンジン
９６４印刷エンジンインターフェイス
９６６システムバス
９６８ハードディスク
９７０フロッピーディスク
９７２ディスクコントローラ
９７４通信コントローラ
９７６Ｉ／Ｏコントローラ
９７８プリンタ
９８０ハードディスク
９８２ディスプレイコントローラ
９８４ネットワーク[0001]
[Industrial applications]
The present invention relates to document format conversion, and more particularly, to converting a binary encoded document to a cleartext encoded document. The present invention still further provides a standard page description language in clear text encoding of a standard page description language document in binary encoding. documents Regarding the conversion to.
[0002]
This application is based on U.S. patent application Ser. No. 08 / 147,603 (received Nov. 4, 1993, "STANDARD PAGE DESCRIPTION LANGUAGE CLEARTEXT STRUCTUREGENETERATOR") and U.S. patent application Ser. No. 08 / 066,383 (May 1993). 21 days acceptance, "METHOD aND SYSTEM FOR PROCESSING MIXED BINARY LENGTH ENCODINGSCONTAINING DEFINITE aND INDEFINITE LENGTH FORMATS") and US patent application Ser. No. 08 / 006,416 (January 19, 1993, "METHOD aND SYSTEM TORECOGNIZE ENCODING TYPE IN DOCUMENT PROCESS NG LANGUAGE "), the three U.S. patent applications being filed in U.S. patent application Ser. No. 07 / 931,808, filed Aug. 11, 1992," A Method And System to Handy Dictionary Generation and Context. Declaration in a Document Processing Language "), which is incorporated by reference in its U.S. patent application Ser. No. 07 / 931,808, filed on Apr. 30, 1992," Method and Apparatus to ". "Manage Picture and Page for Document Processing", US patent application Ser. No. 07 / 876,251, Apr. 1992. 30th, "Method and System to Handle Inclusion of External Files into Document Documenting Language", and U.S. Patent Application No. 07 / 778,578, Oct. 17th, 1991, Oct. The above patent applications are incorporated herein by reference.
[0003]
[Prior art]
One standardized page description language (SPDL) has been proposed and is being developed as an international standard by the International Standards Organization (ISO). This proposal, one of whom is the present inventor, is currently being drafted in a section of the ISO. This draft is known as ISO / IEC DIS 10180 "Information Processing Text-Communication-Standard Page Description Language" and is available from the American National Standards Institute (ANSI) in New York and is hereby incorporated herein by reference. Be incorporated.
[0004]
Standard Page Description Language (SPDL) is a hierarchically structured page description language. According to this structured hierarchy, when a part of a document is printed, it is not necessary to check formatting commands that may affect the part over the entire document. To print a desired portion, only the portion of the document that is higher in the hierarchy than the portion to be printed need be processed.
[0005]
Another advantage of SPDL is that SPDL conforms to the Standard Generalized Markup Language (SGML) defined in ISO 8879: 1986. This makes it possible to describe and comprehensively link the document structure. Multiple files, once linked in SGML, can be seamlessly transferred from one platform to another without using a conversion utility and without compromising the structural format.
[0006]
SPDL is ASN. 1 is based on the Basic Encoding Rules. ASN. A full description of No. 1 can be found in Douglas Steedman, "ASN. 1, The Tutorial and Reference" (1990), which is incorporated herein by reference.
[0007]
Cleartext languages are a type of human-readable computer language. An example of a non-clear text language would be the binary encoding of a document. This is because the contents of the document cannot be easily understood by a human even when the document in the binary or hexadecimal expression is viewed. One major advantage of binary-encoded documents is that documents represented in binary require significantly less storage space than equivalent clear-text documents. This allows a reduction in the storage space of the binary document and a faster transmission time. However, compared to a clear text encoded document, it is difficult to edit and understand a binary encoded document unless special software is used.
[0008]
Thus, as described above, there may be advantages and disadvantages to both clear text and binary encoding of a document, and you may want to convert a document from one format to another.
[0009]
[Problems to be solved by the invention]
It is an object of the present invention to provide a means for converting a binary encoded document to a clear text encoded document.
[0010]
It is another object of the present invention to provide a means for converting a binary encoded standard page description language document into an equivalent clear text encoded standard page description language document.
[0011]
Due to the format required for binary SPDL documents, a simple look-up procedure cannot be performed to convert a binary encoded document to a clear text encoded document. The content represented by the various binary symbols depends on the location of the binary symbols in the SPDL document.
[0012]
Another issue that must be addressed by the present invention is to manage the length of each of the binary encoded processes. SPDL is a hierarchically structured page description language, where the beginning of each hierarchical level indicates whether the level is encoded in fixed-length or undefined-length format, and the fixed-length binary encoding Sometimes it indicates the length of the encoding.
[0013]
Another problem addressed by the present invention is that the order of certain elements in binary encoding must be changed in clear text encoding. Therefore, it is necessary to know the encoding order required in the clear text SPDL format.
[0014]
[Means for Solving the Problems]
The means for solving the above-mentioned object or problem will be described more specifically. In order to perform the conversion from binary to clear text, the present invention firstly uses an application table to obtain an ASN. One tag is searched to determine the clear text name of this binary tag. Once the clear text name is determined, further information about the element can be retrieved from the element table. An element in the element table can have a sub-element, which is referenced by a pointer in the element table that points to a sub-element linked list.
[0015]
After the required information about the element is obtained, an entry is pushed onto the element stack with various fields for managing the information used in the conversion process. This element stack is very useful for processing fixed-length and indefinite-length formats of binary coding.
[0016]
When the binary element is being translated, the attribute value is stored in the attribute buffer. Prior to generating the output file, each converted clear text line is written to a double linked list data structure as the file is being converted. When the entire file is converted and written to the double linked list data structure, the information of the double linked list data structure is written to the output file.
[0017]
[Action]
The double linked list data structure is effectively used for handling out of order attributes. Elements can include attributes and sub-elements. Typically, in the case of clear text SPDL, attributes must appear immediately after the element and before the appearance of any sub-elements. However, in binary SPDL encoding, sub-elements may appear before attributes.
[0018]
The present invention uses the attribute buffer and the double linked list data structure to solve the above inappropriate attribute problem. In the present invention, objects that appear hierarchically below elements are collectively referred to as sub-elements. The sub-element for an element is either an attribute of the element or an actual sub-element. In order for the attributes to be appropriate, they should appear immediately after the element. If a sub-element appears after an element before all of the attributes have appeared, then the subsequent attributes are considered inappropriate. The double linked list data structure has an entry for storing attribute information of the element. If a non-attribute sub-element appears below an element before all of the attributes have been processed, a new double-linked list is created by the double-linked list data structure of the parent element. Refers to the data structure. Inappropriate attributes will appear after processing sub-elements of the parent element. From the most recently generated double linked list data structure, the double linked list data structure is traced backwards until the parent element double linked list data structure is reached. Then, the attribute information of the attribute sub-element is written in the attribute entry of the double linked list data structure of the parent element. In this way, inappropriate attributes are processed efficiently.
[0019]
【Example】
Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings. In the drawings, the same reference numeral indicates the same or corresponding part.
[0020]
Referring to FIG. 1 of the accompanying drawings, there is shown an example of nesting of fixed length and undefined length formats for a binary encoded document. FIG. 1 can be thought of as showing one data stream or document data stream to be processed. Rows 1 through 16 and 17 through 19 are the two highest coding levels of coding, but within rows 1 through 16 there are nested codings. The content of the encoding of the rows 1 to 16 is a fixed length of 400 bytes. Among these 400 bytes, there is one undefined length structure in rows 4 to 13 first. The undefined-length content in rows 4 to 13 is a fixed-length coding of 248 bytes and 40 bytes. In addition to the undefined length encoding consisting of 400 bytes of content in rows 4-13, there is a fixed length encoding of rows 14-16 containing 100 bytes of content. Lines 17-19 of FIG. 1 contain a 250 byte long fixed length encoding.
[0021]
The term "nesting of fixed-length and variable-length formats" means that a variable-length encoding has as its content one variable-length encoding and one fixed-length encoding, that is, a combination of these two encodings. Means that you can do it. This means that the fixed-length encoding starts before the variable-length encoding ends. The above terms apply equally to fixed-length encodings, including variable-length encodings. That is, indefinite-length encoding can begin before fixed-length encoding ends. Furthermore, any number of any type of encoding can be nested within one encoding.
[0022]
One problem arises with the handling of nested fixed-length encoding and indefinite-length encoding when the encoding as shown in FIG. 1 is being processed. The example shown in FIG. 1 is a simple case. Nesting of fixed-length and undefined-length formats can be much deeper. Thus, the processing system may have to manage many hierarchical levels of undefined and fixed length formats.
[0023]
To check the end of the variable length encoding, use ASN. It is not enough to look for the end flag or marker for an undefined length encoding, such as 000H on line 13 used in one encoding. This is because the contents in rows 9 and 12 may include 000H as data and image data. Therefore, the present invention looks for the end of variable length encoding 000H after processing the nested fixed length encoding. The end of indefinite-length encoding should come after the nested routines in fixed-length format.
[0024]
By the way, ASN. 2 shows the structure of binary encoding according to the basic encoding rules defined in ISO / IEC8824. The encoding starts with one or more identifier octets, followed by one or more length octets, followed by a content octet.
[0025]
The structure of the identifier octet as defined by ISO / IEC 8824 is shown in FIG. The first two bits of this identifier octet indicate the class of encoding. The possible encoding classes defined by bits 8 and 7 shown in FIG. 3 are four classes: universal, application, content-specific, and private. ASN. A full description of encoding by 1 can be found in ISO / IEC 8824 and ISO / IEC 8825, both incorporated herein by reference. However, an understanding of the various classes of encoding is not required to understand the operation of the present invention, and so, for the sake of brevity, no further details are given.
[0026]
Bit 6 shown in FIG. 3 determines whether the encoding is primitive or constructed. Primitive means that no other encoding is nested within the encoding, and compound means that another encoding is nested within the encoding. Bits 5-1 shown in FIG. 3 relate to the tag number. When the tag number exceeds 31, since bits 5 to 1 are not enough to represent the same number, the tag number is encoded in the subsequent identifier octet. A thorough understanding of the various tag numbers is not necessary for understanding the operation of the present invention, and will be omitted for brevity.
[0027]
The identifier octet and the length octet can be considered as preamble information, and the content octet can be considered as content information. The text information obtained when the identifier information is converted to text format is a clear text start tag followed by a clear text representation of the content information, and if necessary or required, it is then cleared. Followed by an end-of-text tag.
[0028]
It is believed that the above description is sufficient for one of ordinary skill in the art to understand the basics of binary SPDL encoding. However, a more detailed and complete description of the process of binary encoding can be found in co-pending U.S. patent application Ser. be able to. While the primary concern and process of the present application is to convert a file from a binary representation to a clear text representation, the process described in the related application above relates primarily to the presentation of documents by printers, CRTs, etc. Is what you do.
[0029]
The present invention uses an element table and a sub-element link list to manage information of various SPDL elements. Since SPDL is a hierarchically structured page description language, it is necessary to determine the hierarchical structure in SPDL in order to generate information of an element table and a sub-element link list.
[0030]
In order to determine the order of the SPDL hierarchy, the present inventor has created an SPDL element state transition diagram as shown in FIG. 4 using the description of the SPDL element included in the draft standard. FIG. 4 illustrates the SPDL structure elements using a tree structure, and also shows the attributes for the various SPDL elements by indicating labeled attribute arc arrows that exit from one element and return to the same element. FIG. From this state transition diagram, the inventor of the present application was able to generate an element table and a sub-element link list used in the present invention.
[0031]
The first element of the state transition diagram is SPDL 152. There are two possible elements that can appear below the SPDL element. That is, a document element 154 and a resource definition (resource definition) element 156. The resource definition element 156 is shown as having attributes of a resource attribute, an SPDLID attribute, and a function attribute. Attributes may have fixed values or values entered by the user.
[0032]
In FIG. 4, the terminal or bottom element in a particular hierarchical structure is marked with an asterisk, and the previously defined element is marked with a plus sign. A terminal element can exist at the lowest level of a particular hierarchical structure, but no other elements can exist. The SPDL element state transition diagram shown in FIG. 4 is not complete, and some of the SPDL structural elements are omitted for simplicity. For example, a resource specification 164, an external declaration 172, an information declaration 174, a resource definition 176, a resource declaration 178, a DPI declaration 180, a context (cptext) declaration 182, a setup procedure (set-up procedures) 186 There are structural elements that come below.
[0033]
Below the document structure element 154 are a page set element 158 and a picture element 160. Below the pageset 158 are a pageset body 166 and a prologue 172. As shown in FIG. 4, the picture element 160 may also appear below the page set body 166. The picture element 160 has a content type attribute and an SPDL ID. The SPDL elements that can appear below the picture element 160 are the prolog 172 and the picture body 168. A token sequence 170 can appear below the picture body 168. A dictionary generator 184 that appears below the prolog 172 can have a dictionary generator element 188 with a size attribute below it. The SPDL elements that can appear under dictionary 188 are dictionary ID 190, name 194, and token sequence 192.
[0034]
FIG. 5 shows a typical binary SPDL document in hexadecimal representation. A clear text document equivalent to the document shown in FIG. 5 is shown in FIG. When the present invention is used, the document shown in FIG. 5 can be input and converted into the format shown in FIG. The details of FIGS. 5 and 6 will be better understood after describing the operation of the present invention on the documents shown in FIGS.
[0035]
FIG. 7 illustrates how the document shown in FIG. 5 corresponds to the document shown in FIG. As can be seen from FIG. 7, reference numeral 61 denotes a page set as an element. 59 after 61 indicates the length of this page set. The SPDL ID in this page set is ASN. This is represented by one tag 06. The length of this SPDL ID is 4. The actual SPDL ID “ISO / IED 10180 // SPDL” is represented by “28 CF 44 00”.
[0036]
Next, in FIG. It can be seen that one tag 44 corresponds to a comment. The length of this comment is 1F. The content of this comment is “SPDL ID = PublicObject ID value”. Next, it can be seen that A1 represents a psbody, also called a page set body. The rest of FIG. 7 can be understood similarly. Therefore, a complete description of the correspondence in FIG. 7 is omitted for simplification.
[0037]
FIG. 8 shows an application table used in the present invention. This application table contains the ASN. The byte value of one tag (identifier octet) and the name (name) of the corresponding clear text application element are stored. For example, ASN. 40H of one tag corresponds to the clear text element "name". Also, ASN. It can be seen that 61H and 62H of one tag correspond to elements of a page set (pageset) and a picture (picture), respectively. Of course, the complete application table used in the present invention is a known ASN. One tag and a known element name will be stored. ASN. 1 tag can be easily known from known literature. A complete list of each tag is not provided.
[0038]
FIG. 9 shows the SPDL element table used in the present invention. The first column of this element table is the element name or the element's clear text tag. The next two columns indicate whether the start and end tags are optional or required. A hyphen indicates that a tag is required, and 0 indicates that the tag is optional. In the embodiment of the present invention disclosed here, the start tag and the end tag of each element are always used. Of course, it is also possible to use the start and end tag entries of the element table and omit the tag when they are optional.
[0039]
The fourth column in the element table indicates whether the element is a primitive or a constructed. Primitive means that no other encodings are nested in the content, and compound means that other encodings are nested in the content. Although the present invention does not specifically refer to the fourth column, this primitive / composite information is included in the element table because it may be used in other related inventions.
[0040]
The fifth column of the element table stores the element declaration. This element declaration is a description of the characteristics of the element. More specifically, the element declaration pertains to properties for the element name of the element and properties for handling substructure elements (if any). For example, DOCTYPE, NO DECLARATION, OCTET STRING, and PRINTABLE STRING are first type element declarations. CHOICE, SEQUENCE, SEQUENCE OF CHOICE are a second type of element declaration. The DOCTYPE declaration is a special type declaration and is used only for the DOCTYPE structure element. The CHOICE declaration indicates that the user can select any one of the sub-elements under the element. The SEQUENCE declaration indicates that the sub-elements that appear below the element must appear in a particular order, and that this order cannot be changed.
[0041]
The SEQUENCE OF CHOICE declaration causes the selection of two or more dependent structure elements by repeating the CHOICE declaration. A NO DECLARATION declaration means that the element has only one dependent structure element.
[0042]
The OCET STRING declaration indicates that the element is an 8-bit byte character string. The PRINTABLE STRING declaration indicates that the element is a printable string.
[0043]
When a declaration is implicit, it means that the declaration does not need to be explicitly stated, as it is determined based on the tags that appear below. Details of this feature can be found in ASN. Since it can be known from publicly known documents related to encoding used in SPDL, such as SPDL, it is omitted for simplicity.
[0044]
Other declarations are used in other SPDL document types, but details of these declarations are omitted for simplicity of description. Details of these can be found in the public literature on SPDL. The present invention can use element declarations to ensure that the syntax of a binary SPDL document does not violate SPDL encoding requirements.
[0045]
The sixth column of the element table indicates the number of attributes of the element. Attributes describe various characteristics of the element, but attributes specific to the element can be found in the sub-element linked list.
[0046]
The seventh column of the element table indicates the number of sub-elements of the element. This number of sub-elements indicates the number of various sub-elements that can appear below the element. The last column of the element table is a pointer to a sub-element linked list data structure that stores information about sub-elements that can appear below the element.
[0047]
FIG. 10 shows a sub-element linked list data structure 200 pointed to by a pointer 202 corresponding to any of the pointers in the element table shown in FIG. The first entry 204 of this sub-element linked list data structure 200 is the ASN. 1 tag, which is the binary representation of the sub-element. The entry 206 of the sub-element linked list data structure 200 is a sub-element declaration and stores the same declaration information as the element declaration described with respect to the element table.
[0048]
The entry 208 of the sub-element linked list data structure 200 contains the ASN. The clear text sub-element name corresponding to one tag 204 is stored.
[0049]
Entry 210 stores the sub-element type. Possible sub-element types are attribute, optional, default, or terminating, and combinations of these four types are also allowed. In practicing the present invention, if the type of sub-element is 4 types, it is represented using 4 bits. If none of the four sub-element types described above match, the sub-element type can be left blank.
[0050]
Field 212 stores the sequence number of the sub-element, and this sequence number is the number of the sub-element linked list data structure. For example, the first sub-element for an element has sequence number 1 and the linked list data structure pointed to by the first linked list data structure of a certain sub-element (second sub-element) has sequence number 2.
[0051]
The last field 214 of the sub-element linked list data structure is a pointer to the next sub-element linked list data structure. If an element has a number of different sub-elements appearing below it in a hierarchical structure, each sub-element has its own linked list data structure. These sub-element linked list data structures are linked to each other by a pointer 214 which points to a subsequent sub-element linked list data structure of an element. The last sub-element linked list data structure points to null.
[0052]
FIG. 11 shows sub-element linked list data structures 230, 240, 250 for the page set element. ASN. For the first sub-element. One tag is 06, which corresponds to the SPDL ID element. Since there is no declaration for SPDL ID, SPDL ID is an attribute. Since this SPDL ID is the first sub-element, it points to the prolog which is the second sub-element. This prologue sub-element linked list data structure points to the PSBODY sub-element linked list data structure 250.
[0053]
The fields of the sub-element linked list data structure for the picture element shown in FIG. 12, the PSBODY element shown in FIG. 13, and the PICBODY element shown in FIG. 14 are the same as the fields of the linked list data structure described for the page set element. Can be described as follows.
[0054]
At the time of writing, the SPDL standard has not yet been completed at the draft stage. In the future, it may be necessary to add a "flags" entry to the sub-element linked list data structure that is used when the element or sub-element declaration is a sequence. However, this flag is not included in the illustrated sub-element linked list data structure because it is not needed at this time.
[0055]
FIG. 15 shows an element stack 340 used by the present invention in the process of converting a binary file to a clear text SPDL file. Field 342 of element stack 340 stores the element name, which is a clear text representation of the element being processed. Field 344 is an element declaration. Field 346 is used to process attributes of the element. After processing each attribute of the element, field 346 is decremented by one to manage the processed attributes of the element. Field 348 is used to manage the level number of each hierarchical level of the document and to manage the indentation level in the clear text SPDL file.
[0056]
The INDEF flag 350 and the ELEMENT LENGTH field 352 are used to manage the length of the binary element. "1" in the INDEF flag 350 indicates that the binary element has an undefined length format. Element length field 352 is used for counting that byte when a binary encoding is being processed. The pointer 354 points to a sub-element link list similar to the link lists shown in FIGS.
[0057]
The indef flag and element length field of the element stack 340 shown in FIG. 15 are described in pending U.S. patent application Ser. No. 08 / 066,383, filed May 21, 1993, "METHOD AND SYSTEM FOR PROCESSINGMIXEDED." BINARY LENGTH ENCODING CONTAINING DEFINETE AND INDEPITE LENGTH FORMATS "), which is incorporated herein by reference. Other features of the element stack include the element stack described in pending U.S. patent application Ser. No. 08 / 147,603, filed Nov. 4, 1993, "STANDARD PAGE DESCRIPTATION LANGUAGE CLEARTEXT STRUCTURE GENERATOR". The patent application is incorporated herein by reference.
[0058]
The double linked list data structure 360 shown in FIG. 16 is used to manage the information after the clear text conversion. Each time a binary element is processed and converted, information for that element is stored in a double linked list data structure. After the conversion from binary to clear text is completed, the respective information of the double linked list data structure is copied to an output file similar to the document shown in FIG. This double linked list is useful for processing elements that may have a different order in the binary representation than in the clear text representation.
[0059]
Double linked list data structure 360 is pointed to by pointer 362. The pointer 362 corresponds to the “next” pointer of the immediately preceding double linked list data structure if the double linked list data structure is not the first double linked list data structure for the file being converted. . If the double linked list data structure is the first double linked list data structure of the file being converted, the pointer 362 may be a default value and the pointer 362 may be used by the system to refer to the first data structure. Not just. The field level number 364 indicates the indentation level of the element. Element name 368 indicates the clear text name of the element. Entry 368 may be a pointer to a memory area that stores the name. Field 370 stores the attribute information of the element, when it exists. Field 370 may be a pointer to another memory location that stores attribute information.
[0060]
Field 372 stores data that may be used by the element. For example, if the element is a comment, this data field would store the text of the comment. This data field may be a pointer to another memory location that stores the actual data. Field 374 is a back pointer, which points to the previous double linked list data structure, if any. If no previous double linked list data structure exists, this backpointer points to null. The next pointer 376 points to the next double linked list data structure, if one exists. When the next double linked list data structure does not exist, the next pointer 376 points to null.
[0061]
FIG. 17 shows the attribute buffer 380 used in the present invention. The attribute buffer 380 is used to temporarily store attribute information of the element during processing of the element.
[0062]
Figures 18-28 illustrate the process used by the present invention to convert a binary SPDL file to a clear text SPDL file. Step 402 in FIG. 18 determines an input file name and an output file name by analyzing an input command line. Step 404 determines whether the input file exists. If the input file does not exist, flow proceeds to step 406, where an error due to the absence of the input file is displayed and the process exits. If the input file exists, the flow proceeds to step 408, and determines whether the output file has been specified. If the output file has not been identified, a default filename is assigned to the output file in step 410. Step 412 determines whether the input file is an SPDL binary file. This determination can be made by examining the beginning of the file to see if it contains a bit indicating that it is a binary SPDL file. A more detailed description of how to determine whether a file is a binary SPDL file can be found in co-pending U.S. patent application Ser. No. 08 / 006,416 ("METHOD AND SYSTEM TO RECOGNIZING ENCODING TYPE IN DOCUMENT PROCESSING LANGUAGE"). The application is incorporated herein by reference. If step 412 determines that the input file is not a binary SPDL file, step 414 indicates that the format of the input file is incorrect and the process ends. If the input file is a binary SPDL file, flow proceeds to process A shown in FIG. It should be noted that the examples given in FIGS. 5, 6 and 7 are based on a draft international standard, whereas US patent application Ser. No. 08 / 006,416 is based on a later version. Has not yet been published in final form. However, "28 CF 44 00" means binary SPDL encoding in both versions.
[0063]
Step 420 of FIG. 19 initializes the element stack, which merely reserves memory for the stack. Steps 422 and 424 write the first two lines of the clear text file to the double linked list data structure. Since the first two lines of the clear text SPDL file are always DOCTYPE and SPDL, these two lines need to be written at the beginning of each SPDL file.
[0064]
Step 426 gets the tag from the input file, and step 428 examines the tag to determine if it is RESDEF. When the first tag is not RESDEF, the SPDL encoding rules require that the third line of the clear text encoding be a document element. If the first element tag is RESDEF, the third line of the clear text encoding need not be a document element. From steps 428 and 430, the flow proceeds to process B shown in FIG.
[0065]
Step 440 of FIG. 20 searches the element table for the element corresponding to the binary tag, and requires information about the element tag, such as a clear text element name, and whether the start and end tags are optional. Or information such as whether the element is a primitive or a composite, the number of attributes of the element, the number of sub-elements of the element, and a pointer to a sub-element link list of the element. In step 442, the next byte indicating the length of the element is read from the input file. When the length octet of the encoding is binary 10000000, its length is indefinite. The end of indefinite length encoding is indicated by 0000H in the contents octet. If step 444 determines that the encoding is undefined length, step 446 sets INDEF_LEN_FLAG to true, indicating that the encoding is in undefined length format. If it is determined in step 444 that the encoding is not in the variable length format, the flow proceeds to step 448, where the value of the fixed length encoding is determined. From steps 448 and 446, the flow proceeds to step C shown in FIG.
[0066]
In FIG. 21, step 460 determines whether the element stack is empty. If it is not empty, in step 462, it is necessary to reduce the number of bytes of the tag to be processed, the bytes used for the tag, and the length of the tag from the top entry of the element stack. When the length type of the current tag is fixed length, this fixed length is also reduced. In most cases, the tag is one byte and the length is one byte, so two bytes are subtracted from the length field of the top entry of the element stack.
[0067]
From steps 460 and 462, flow proceeds to step 464, where it is determined whether the sub-element linked list pointer is null. If the sub-element linked list pointer is null, there are no sub-elements in the element, so the element is a terminal element, and flow proceeds to step 474 where the data for the terminal element is stored in the corresponding double linked list. The data is stored in the buffer pointed to by the pointer 372 of the data structure 360. Flow proceeds to step 476, where TERMINAL_ENTRY_FLAG is set to true. From step 476, the flow proceeds to process E shown in FIG. 24, where the element information is stored in a new double linked list.
[0068]
If it is determined in step 464 that the sub-element linked list pointer is not null, then there is a sub-element of the element, and the flow proceeds to step 468 to start processing the sub-element information. Step 468 pushes the element information obtained in step 440 onto the element stack. Flow proceeds from step 468 to process D shown in FIG.
[0069]
In FIG. 22, step 480 determines whether the number of attributes (stored in the element stack) is greater than zero. If the number of attributes is not greater than 0, step 482 sets the attribute buffer ATTR_BUFFER to null and the flow proceeds to E shown in FIG. If the number of attributes is greater than 0, the attributes must be processed, so flow proceeds from step 480 to step 484, where the next ASN. Read one tag. Next, step 486 searches the sub-element linked list for its ASN. Check if one tag is a valid tag for a sub-element or attribute of the current element. The sub-element is the correct ASN. If it is one sub-element, the flow proceeds to process G shown in FIG. If the element being processed is not a suitable sub-element, flow proceeds to step 490, where it is determined whether the tag is a comment. If the tag is not a comment, step 492 indicates an error and exits the process because the sub-element is not appropriate for the element. If the tag is a comment, the tag is written back to the input file for processing as one element, and the flow returns to process B in field 20.
[0070]
The process G shown in FIG. 23 handles the processing of the correct sub-element, but starts from step 488 in FIG. In step 500 of FIG. 23, the ASN. Get information about sub-elements, such as 1 tag value, sub-element declaration, sub-element name, sub-element type, sub-element sequence number, next pointer to next sub-element linked list data structure. Step 502 examines the sub-element type to determine if the sub-element is an attribute. If the sub-element is an attribute, step 508 stores the attribute data in attribute buffer ATTR_BUFFER and flow proceeds to process H shown in FIG. If it is determined in step 502 that the sub-element type is not an attribute, the flow proceeds to step 504. Step 504 indicates that no attributes follow. An element's attributes should appear immediately after the element and before the appearance of any sub-elements of the element. If it is determined in step 480 that the number of attributes is greater than 0, the flow reaches step 502, and the sub-element should be an attribute (although it need not be an attribute). If the sub-element is not an attribute, the attributes following the current sub-element will be inappropriate. The present invention neatly arranges such attributes when they subsequently appear, according to steps 606 and 608 of the flowchart shown in FIG. After step 504, step 506 writes the inappropriate tag back to the input file, and flow proceeds to process E of FIG. 24 for the next processing.
[0071]
The process H of FIG. 24 handles the processing of a sub-element that is an attribute. Step 520 of FIG. 24 reduces the number of attributes from the top entry of the element stack. Step 522 decrements the number of attributes in the element stack by one. Step 524 determines whether the number of attributes in the element stack is greater than zero. If the number of attributes is greater than 0, another attribute must be processed and the flow proceeds to step 526. Step 526 stores the new one-line character in the attribute buffer, and flow proceeds to process F shown in FIG. 22 for processing of the remaining attributes.
[0072]
If it is determined in step 524 that the number of attributes is greater than 0, the flow proceeds to step 528, in which all information on the processing element including the element name, level number, attribute buffer, data information, next pointer, and previous pointer is new. Stored in a double linked list data structure. From step 528, the flow proceeds to process I shown in FIG.
[0073]
Step 540 determines whether TERMINAL_ENTRY_FLAG is true. TERMINAL_ENTRY_FLAG has been set to true in step 476 of FIG. If this flag is not set, the default value of TERMINAL_ENTRY_FLAG is false. If it is true, flow proceeds to step 542, indicating that the current element is a terminating element, and the element end tag for that element is written to the new double linked list data structure. Then, step 544 sets TERMINAL_ENTRY_FLAG to false.
[0074]
Following steps 540 and 544, step 546 determines whether INDEF_LEN_FLAG is true. If it is true, the flow proceeds to process J shown in FIG. 26 for processing of undefined length format. Otherwise, flow proceeds to step 548, where it is determined whether the element length of the top entry of the element stack is zero. If this length is not 0, the element has a fixed length, so the entire length of the element has not been processed, and the process proceeds to process K shown in FIG. 28 for further processing. Otherwise, the length of the top entry of the element stack is 0, the current element at the top entry of the element stack has finished processing, and step 550 sets the end tag of the top element of the element stack to a new double link. Write to list data structure. From step 550, the flow proceeds to L in FIG.
[0075]
Process J shown in FIG. 26 handles processing of an undefined length format. Step 560 saves the current position in the input file to a variable FPOS. Step 562 reads the next two bytes from the input file. Step 564 determines whether both of these two bytes are zero. If so, the flow proceeds to step 566 because it indicates the end of the undefined length coding format, the end tag of the current element being processed is written to the double linked list data structure, and the flow is terminated. Proceed to L in FIG. If the end flag has not been reached, flow proceeds from step 564 to step 568, where the input file pointer is again adjusted to point to position FPOS so that the last two bytes of the file read in step 562 can be processed. . From step 568, the flow proceeds to K in FIG. In the process L shown in FIG. 27, a step 576 determines whether or not the current element has an undefined format and an entry exists below the current element. If so, at step 578, the lower level length entry in the element stack is determined by adding the current element length (which is a negative value) to the lower level length entry. Adjusted. Step 580 then pops the top entry on the element stack.
[0076]
If step 582 determines that the element stack is empty, and step 584 determines that there is more data to process, flow proceeds to step 586 where data is transferred from the double linked list data structure to the output file. Copied and the process ends. If the element stack is not empty or there is more data to process, flow proceeds to process K shown in FIG.
[0077]
In FIG. 28, step 590 reads the next tag in the binary input file. A step 592 determines whether the tag is a comment. If the tag is a comment, the current element is set to a comment, and the flow proceeds to the process B shown in FIG. If the next tag is not a comment, flow proceeds from step 592 to step 596, where the sub-element linked list is searched to confirm the validity of the sub-element. This step determines whether the current sub-element is allowed to appear below the element being processed. If step 598 determines that the sub-element is not valid, it is an incorrect sub-element and an error is displayed at step 600 and the process exits. If it is determined in step 598 that the sub-element is valid, the flow proceeds to step 602.
[0078]
In step 602, it is checked whether the number of attributes of the top element in the element stack is greater than zero. If not, the flow proceeds to process B since the sub-element is not an attribute. If the number of attributes in the top entry of the element stack is greater than zero, flow proceeds to step 604 to determine whether the sub-element is an attribute. If it is determined in step 604 that the sub-element is not an attribute, the flow proceeds to process B. If step 604 determines that the sub-element is an attribute, step 606 searches the double linked list to find element information for the top entry in the element stack. Next, step 608 stores the attribute in the attribute buffer. Then, the flow proceeds to process M shown in FIG.
[0079]
FIGS. 29 and 30 show a double linked list data structure created when the binary file shown in FIG. 5 is converted to the clear text file shown in FIG. The first double linked list data structure 700 has an indentation level of 0 and an element name of! DOCTYPE, has no attributes or data, and points to the double linked list data structure 710 (with the next pointer). Double linked list data structure 710 has an indentation level of 0, is named SPDL, has no attributes or data in the data fields, points to double linked list data structure 700 (with a back pointer), The next pointer points to the next double linked list data structure 720.
[0080]
Double linked list data structure 720 points to double linked list data structure 730 (with the next pointer). The double linked list data structure 730 has an indentation level of 1, has a page set element, is defined with an attribute SPDL ID, and points to the double linked list data structure 740 (with a next pointer). The double linked list data structure 740 is a comment with an indentation level of 2 and has no attribute, but has data including the content of the comment. The DATA_HEAD entry of the double linked list data structure 740 indicates a linked list data structure that indicates actual data. The next entry of the linked list data structure pointed to by the DATA_HEAD entry of the double linked list data structure 740 may point to the next linked list data structure.
[0081]
The double linked list data structure 740 points to the double linked list data structure 760 shown in FIG. 30 (with the next pointer). The data structure shown in FIG. 30 can be described similarly to the data structure shown in FIG. Note that for simplicity, the data structure between the double linked list data structure 780 and the double linked list data structure 800 has been omitted, but the process of the present invention has been followed and / or the clear shown in FIG. A close look at the example text can confirm the omitted data structure.
[0082]
FIGS. 31 to 35 show element stacks when the examples shown in FIGS. 5 and 6 are processed. The sub-element linked list pointed to by the pointer in the element stack will remain constant and will be the same general type linked list shown in FIGS.
[0083]
Returning to the flowcharts shown in FIGS. 18 to 28 to show an example of how a binary SPDL file is processed according to the present invention. The process of the present invention begins at FIG. 18, but assumes that the input and output files have been identified and the flow has proceeded to FIG. Step 422 generates the double linked list data structure 700 shown in FIG. Step 424 generates the double linked list data structure 710 shown in FIG. Next, step 426 reads the element tag byte 61, which is the first element appearing in the file shown in FIG. Since this element 61 corresponds to PAGESET and does not correspond to element RESDEF, the flow proceeds to step 430 to generate the double linked list 720 of FIG. Then, the flow proceeds to process B in FIG. Step 440 obtains information about element 61, including the element name, such as PAGESET, and all other information listed in step 440. The next byte in the input file is 59, which is the fixed length value of PAGESET. Accordingly, the flow proceeds from step 422 to steps 444 and 448, and then proceeds to step 460 in FIG.
[0084]
In FIG. 21, step 460 determines that the element stack is empty because no elements have been pushed onto the element stack. Step 464 determines that the sub-element linked list is not null, and flow proceeds to step 468 where the element information is pushed onto the element stack. The element stack at this time is as shown in FIG. Then, the flow proceeds to process D shown in FIG.
[0085]
Since the number of attributes of the PAGESET is greater than 0, the flow proceeds from step 480 to step 484, where the next ASN. 06, which is one tag, is extracted. Since 06 is an appropriate subelement of PAGESET, flow proceeds from step 488 to process G shown in FIG. Step 500 reads the information of the sub-element, and step 502 determines that the sub-element is an attribute. Since the PAGESET element has one attribute and the first subelement of the PAGESET is an attribute, the attributes are in order, so the flow proceeds to step 508, where the attribute data is stored in the attribute buffer ATTR_BUFFER. Then, the flow proceeds to process H shown in FIG.
[0086]
In FIG. 24, step 520 subtracts the length of the attribute from the top entry of the element stack. Since the length of the SPDL ID is 4 bytes, a value obtained by adding 4 to the number of bytes of the length information, the number of bytes of the SPDL ID, and the number of bytes of the PAGESET is reduced from the stack shown in FIG. Since the processing of the first attribute has been completed, step 522 reduces the number of attributes by one, and since PAGESET has only one attribute, the flow proceeds from step 524 to step 528, and the element information is changed to the new double shown in FIG. It is stored in the link list data structure 730. Since PAGESET is the first indentation level in FIG. 6, the level number entry in double linked list data structure 730 is set to one. From step 528, the flow proceeds to process I shown in FIG.
[0087]
Since TERMNAL_ENTRY_FLAG has been initialized to false, flow proceeds from step 540 to step 546 and then to step 548, where it is determined that the element length of the top entry of the element stack is not zero. Then, the flow proceeds to process K shown in FIG.
[0088]
In FIG. 28, step 590 is to execute the next ASN. One tag is read, but the tag is 44. Since this tag is a comment tag, step 594 makes the current element a comment, and the flow proceeds to process B shown in FIG.
[0089]
In FIG. 20, a step 440 searches the element table to obtain information about the comment, and a step 448 obtains a fixed length value of the comment. The fixed length value is 1F. Flow proceeds to step 460, which verifies that the element stack is not empty, and in step 462, the length of the comment is subtracted from the element length entry of the PAGESET in the stack. Next, step 464 determines that the sub-element linked list pointer is null because the comment element has no sub-elements. At step 474, the information contained in the comment is stored in a data buffer linked list data structure. Next, step 476 sets the variable TERMINAL_ENTRY_FLAG to true, and the flow proceeds to process E shown in FIG.
[0090]
In FIG. 24, a step 528 stores comment information in the double link list data structure 740 shown in FIG. Then, the flow proceeds to process I shown in FIG. The determination result in step 5401 is YES. This is because this variable is set to true in step 476 of FIG. Next, the flow proceeds to step 542, where the element end tag is written into the double linked list data structure 760 shown in FIG. The flow proceeds to steps 546 and 548, and proceeds to process K shown in FIG.
[0091]
In step 590 of FIG. 28, the next ASN. One tag is read, and this tag is A1 corresponding to the page set body. Then, the flow proceeds from step 592 to steps 596, 598, and 602, and then proceeds to process B shown in FIG.
[0092]
In FIG. 20, an element table is searched to obtain information on a page set body. Next, the flow proceeds to process C shown in FIG. 21, and step 462 subtracts the length of the page set body element from the element length entry of the PAGESET entry in the stack 850 shown in FIG. Since step 464 determines that the sub-element linked list pointer of the page set body is not null, flow proceeds to step 468 where the PAGESET element information is pushed onto the element stack. The element stack is now as shown in FIG.
[0093]
Similarly, the rest of the binary file shown in FIG. 5 is processed according to the flowchart of the present invention, whereby the element stack shown in FIGS. 33 to 35 and the double linked list data shown in FIGS. 29 and 30 are obtained. The structure is obtained. Further tracking of the flowchart is omitted for simplicity.
[0094]
FIG. 36 shows the configuration of a workstation 1000 that can be used to perform the process of the present invention. The workstation 1000 includes an input controller 956 to which a CPU 950, a RAM 952, a ROM 954, a keyboard 958 and a mouse 960 are connected. Print engine interface 964 is connected directly to print engine 962, which receives video control signals representing image data transmitted by interface 964. The workstation further includes a disk controller 972 coupled to a hard disk 968 and a floppy drive 970, a communication controller 974 for connection to a network 984 (eg, an Ethernet network), an external hard disk 980 and a SCSI bus, for example. It includes an I / O controller 976 connected to the printer 978 by, for example, an RS-232C cable. The workstation also includes a display controller 982 connected to the CRT 986. A system bus 966 connects each element in the workstation.
[0095]
The process of the present invention may be stored on any of the storage devices shown in FIG. Further, during operation of the process of the present invention, data generated and used in the process may be stored on any of the storage devices shown in FIG.
[0096]
The data structure used in the present invention can be used in some of the other inventions by the present inventor. Since these other inventions may require extra data fields than the data fields used in the flowchart of the present invention, not all of the fields shown in each data structure may be necessary to make up the present invention. unknown. Furthermore, the SPDL standard is under development at the draft stage. Thus, some of the generated data structures may have fields that are no longer needed due to changes in the standard, or fields that are present due to the possibility that the standard will change.
[0097]
It should be noted that the following method and apparatus are included in the scope of the present invention.
[0098]
(1) A method of converting a file format, comprising the following steps:
Inputting a binary file;
Converting the elements of the binary file into a text format;
Writing the text format of the element to a first buffer;
Determining whether an attribute is required for the element; determining whether a sub-element of the binary file is an attribute of the element, or whether the sub-element is not an attribute of the element;
Converting the sub-element to a text format;
Performing the following steps when the sub-element is determined not to be an attribute of the element and it is determined that an attribute is required for the element:
Writing the text format of the sub-element of the element to a second buffer;
Processing the binary file until the required attributes are encountered;
Converting the required attributes to a text format;
Writing the text format of the required attribute to the first buffer storing the element;
Performing the following steps when the sub-element is determined to be an attribute and it is determined that an attribute is required for the first element:
Writing the text format of the sub-element to the first buffer.
[0099]
(2) In the method of the above (1),
Writing the text format of the sub-element of the element to a second buffer, writing the text format of the sub-element of the element to the second buffer with reference to the first buffer, and the method comprises: It further comprises the following steps performed after it is determined that the sub-element is not an attribute of the element:
Tracing back from the second buffer to find the first buffer before performing the step of writing the text format of the required attribute to the first buffer storing the element.
[0100]
(3) In the method of (1), the second buffer is a double-linked list that refers back to the first buffer and forwards reference to the next buffer, and sets the text format of the sub-element to the second buffer. 2 writing to the buffer includes writing the text format of the sub-element to the double linked list;
The method further comprises the following steps performed after it is determined that the sub-element is not an attribute of the element:
Tracing back from the double linked list to find the first buffer before performing the step of writing the text format of the required attribute to the first buffer storing the element.
[0101]
(4) An apparatus for converting a file format having the following means:
Means for inputting a binary file;
Means for converting the elements of the binary file into a text format;
Means for writing the text format of the element to a first buffer;
Means for determining whether an attribute is required for the element;
Means for determining whether a sub-element of the binary file is an attribute of the element or the sub-element is an attribute of the element;
Means for converting the sub-element to the text format;
Means for writing the text format of the sub-element of the element to a second buffer when the sub-element is determined not to be an attribute of the element and an attribute is determined to be required for the element ;
Means for processing the binary file until the required attribute is encountered when the sub-element is determined not to be an attribute of the element and an attribute is determined to be required for the element;
Means for converting the required attribute to the text format when the sub-element is determined not to be an attribute of the element and the attribute is determined to be required for the element; When the element is determined not to be an attribute of the element and the attribute is determined to be required for the element, the text format of the required attribute is stored in the first one that stores the element. Means for writing to the buffer; and
Means for writing the text format of the sub-element to the first buffer when the sub-element is determined to be an attribute and the attribute is determined to be required for the element.
[0102]
(5) In the apparatus of the above (4):
Means for writing the text format of the sub-element of the element to the second buffer, writing the text format of the sub-element of the element to the second buffer referencing the first buffer, and the apparatus Also has the following means:
After determining that the sub-element is not an attribute of the element, prior to performing the step of writing the text format of the required attribute to the first buffer storing the element, the second Means for tracing backward from the buffer to find said first buffer.
[0103]
(6) In the apparatus according to (4), the means for writing the text format of the sub-element of the element to the second buffer includes a double buffer that refers back to the first buffer and forward-references a next buffer. Write the text format of the sub-element of the element to the second buffer, which is a linked list, and the apparatus further comprises:
After determining that the sub-element is not an attribute of the element, prior to performing the step of writing the text format of the required attribute to the first buffer storing the element, the double-linked list Means for tracing more backwards to find said first buffer.
[0104]
(7) A method for converting the format of a file, comprising the following steps:
Inputting a binary file;
Converting the elements of the binary file into a text format;
Writing the text format of the element to a first buffer;
By tracing through a data structure that stores the allowed sub-elements of the element, the sub-element of the element of the binary file is a permitted sub-element of the element, or the sub-element is Determining if it is an unacceptable sub-element of the element;
Indicating an error when the sub-element is determined to be an unacceptable sub-element of the element; and
Converting the subsequent portion of the binary file to a text format when the sub-element is determined to be an unacceptable sub-element of the element.
[0105]
(8) In the method of the above (7), the step of determining is performed by tracing a sub-element linked list data structure that stores each of the allowable sub-elements of the element, thereby obtaining the sub-element of the element. Is a permitted sub-element of the element, or the sub-element is a non-permissible sub-element of the element, and if the sub-element is found in the sub-element linked list data structure, the sub-element Is determined to be permitted, and if the sub-element is not found in the sub-element linked list data structure, it is determined that the sub-element is not permitted.
[0106]
(9) A device for converting the format of a file having the following means:
Means for inputting a binary file;
Means for converting the elements of the binary file into a text format;
Means for writing the text format of the element to a first buffer;
By tracing through a data structure storing the allowed sub-elements of the element, the sub-element of the element in the binary file is an allowed sub-element of the element, or the sub-element is Means for determining whether the element is an unacceptable sub-element of the element; means for indicating an error when the sub-element is determined to be an unacceptable sub-element of the element; and
Means for converting a subsequent portion of the binary file to the text format when the sub-element is determined to be an unacceptable sub-element of the element.
[0107]
(10) In the apparatus according to (9), the means for the determination is performed by tracing a sub-element linked list data structure that stores each of allowable sub-elements of the element, thereby determining the element of the element. Determine whether the sub-element is an allowed sub-element of the element or the sub-element is an unacceptable sub-element, and if the sub-element is found in the sub-element linked list data structure, the sub-element is If it is determined to be allowed, and if the sub-element is not found in the sub-element linked list data structure, it is determined that the sub-element is not allowed.
[0108]
(11) A fixed-length encoding is a method of converting a nested variable-length encoding format from binary to text, wherein both the variable-length encoding and the fixed-length encoding include preamble information and content information. With the steps of:
Inputting a binary file;
Processing the preamble information of the variable length encoding to convert a binary representation of the preamble information of the variable length encoding to a text representation;
Processing the content information of the variable length encoding including the fixed length encoding by performing the following steps:
Processing the preamble information of the fixed-length encoding to check the number of bytes of the content information of the fixed-length encoding;
as well as
By converting the binary representation of the fixed-length encoding content information to a text representation, the number of bytes of the fixed-length encoding content information can be processed without determining whether there is a marker indicating the end of the variable-length encoding. Processing the content information of the fixed length encoding by processing the bytes until:
After processing the content information of the fixed-length encoding, examining bytes of the variable-length encoding after the content information of the fixed-length encoding to search for a marker indicating the end of the variable-length encoding; and If the byte after the content information indicates the end of the variable-length encoding, the processing of the variable-length encoding is terminated.
[0109]
(12) The method according to (11), further including the following steps:
If the byte following the content information of the fixed-length encoding does not indicate the end of the variable-length encoding, treat the byte following the fixed-length encoding as the next procedure nested in the variable-length encoding.
[0110]
(13) A fixed-length encoding is a method of converting a nested variable-length encoding format from binary to text, wherein both the variable-length encoding and the fixed-length encoding include preamble information and content information. With the steps of:
Processing the preamble information in the variable length encoding to convert a binary representation of the preamble information to a text representation;
Processing the content information of the variable length encoding including the fixed length encoding by performing the following steps:
Processing the preamble information of the fixed-length encoding to check the number of bytes of the content information of the fixed-length encoding, storing the number of bytes of the content information of the fixed-length encoding in a temporary storage means; Converting a fixed-length encoding binary representation to a text representation; and
By processing bytes until the number of content information bytes stored in the temporary storage means has been processed without determining whether a marker indicating the end of the variable length encoding is present in the variable length encoding. Processing the content information of the fixed-length encoding, and when the content information of the fixed-length encoding is being processed, counting the number of bytes processed by the fixed-length encoding in the temporary storage means;
After processing the content information of the fixed-length encoding, examining bytes of the variable-length encoding after the content information of the fixed-length encoding to search for a marker indicating the end of the variable-length encoding; and Terminating the processing of the variable-length encoding if the byte after the content information indicates the end of the variable-length encoding.
[0111]
(14) In the method of (13), the step of storing the number of bytes of the content information of the fixed-length encoding includes pushing the length information onto a stack; and
The step of processing the content information of the fixed-length encoding includes processing the number of bytes of the content on the stack without determining whether a marker indicating the end of the variable-length encoding is present in the variable-length encoding. When the content information of the fixed-length encoding is being processed, the number of bytes that have been processed by the fixed-length encoding is counted in the stack.
[0112]
(15) A method for converting the format of the first fixed-length encoding in which the unfixed-length encoding is nested from binary to text, wherein the unfixed-length encoding includes the nested second fixed-length encoding, and And the first and second fixed-length encodings include preamble information and content information, respectively, and the method includes the following steps:
Processing the preamble information of the first fixed length encoding and converting the preamble information from a binary representation to a text representation;
Processing the content information of the first fixed length encoding by performing the following steps:
The preamble information of the unfixed-length encoding is processed, and when the preamble information of the unfixed-length encoding is being processed, the number of processed bytes of the preamble information of the unfixed-length encoding is stored in a first storage means of the temporary storage means Counting the entries and converting the preamble information of the variable length encoding from a binary representation to a text representation;
Processing the content information of the variable length encoding by performing the following steps:
The preamble information of the second fixed length encoding is processed to check the number of bytes of the content information of the second fixed length encoding, and the number of bytes of the content information of the second fixed length encoding is stored in the temporary storage means. And the number of processed bytes of the second fixed-length encoding is stored in the first entry of the temporary storage means when the preamble information of the second fixed-length encoding is being processed. Counting and converting the binary representation of the second fixed length encoding to a text representation;
Processing the second fixed-length encoding until the number of bytes of the content information of the second fixed-length encoding is processed without determining whether a marker indicating the end of the unfixed-length encoding is present in the encoding. Processing the content information of the second fixed-length encoding, and when the content information of the second fixed-length encoding is being processed, stores the number of processed bytes of the second fixed-length encoding in the temporary storage means. Counting to said second entry of
After processing the content information of the second fixed length encoding, examining a byte of the encoding after the content information of the second fixed length encoding, and searching for a byte indicating an end of the unfixed length encoding;
Terminating the processing of the variable-length encoding if the byte following the content information of the second fixed-length encoding indicates the end of the variable-length encoding; and
Processing subsequent bytes of the content of the first fixed length encoding until all bytes of the first fixed length encoding have been processed.
[0113]
【The invention's effect】
As will be understood from the above description, according to the present invention, it is possible to solve the above-described problems to be solved when converting a binary format to a clear text format, and to clear a document from a binary format. Conversion to text format is possible.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an example of nesting of a fixed-length format and an indefinite-length format of binary encoding.
FIG. 2 is a diagram illustrating a structure of encoding according to ISO / IEC 8825;
FIG. 3 is a diagram showing a structure of an identifier octet according to ISO / IEC 8825.
FIG. 4 is a partial view of an SPDL element state transition diagram.
FIG. 5 illustrates a hexadecimal representation of a binary encoded SPDL document sample.
FIG. 6 is a diagram illustrating a clear text representation of the binary document illustrated in FIG. 5;
7 is a diagram showing a correspondence between the binary element shown in FIG. 5 and the clear text element shown in FIG. 6;
FIG. 8: ASN. FIG. 6 is a diagram showing an application table showing one tag and a corresponding clear text element.
FIG. 9 illustrates an element table used to store information about SPDL structural elements.
FIG. 10 is an explanatory diagram of a sub-element linked list data structure pointed to by an element table.
FIG. 11 is a diagram showing a sample of a sub-element linked list data structure pointed to by the element table shown in FIG. 9;
12 is a diagram showing a sample of a sub-element linked list data structure pointed to by the element table shown in FIG. 9;
FIG. 13 is a diagram showing a sample of a sub-element linked list data structure pointed to by the element table shown in FIG. 9;
14 is a diagram showing a sample of a sub-element linked list data structure pointed to by the element table shown in FIG. 9;
FIG. 15 is a diagram showing an element stack used in the conversion process of the present invention.
FIG. 16 illustrates a double linked list data structure used to store a clear text representation of each line until it is written to an output file.
FIG. 17 is a diagram showing an attribute buffer used in the present invention.
FIG. 18 is a flowchart describing the process used in the present invention.
FIG. 19 is a flowchart describing the process used in the present invention.
FIG. 20 is a flowchart describing the process used in the present invention.
FIG. 21 is a flowchart describing the process used in the present invention.
FIG. 22 is a flowchart describing the process used in the present invention.
FIG. 23 is a flowchart describing the process used in the present invention.
FIG. 24 is a flowchart describing the process used in the present invention.
FIG. 25 is a flowchart describing the process used in the present invention.
FIG. 26 is a flowchart describing the process used in the present invention.
FIG. 27 is a flowchart describing the process used in the present invention.
FIG. 28 is a flowchart describing the process used in the present invention.
FIG. 29 is a diagram showing a part of a double linked list data structure generated during the conversion of the binary document shown in FIG. 5;
FIG. 30 is a diagram showing a part of a double linked list data structure generated during the conversion of the binary document shown in FIG. 5;
FIG. 31 is a diagram showing the status of the element stack during the conversion of the document shown in FIG. 5;
FIG. 32 is a diagram showing the status of the element stack during the conversion of the document shown in FIG. 5;
FIG. 33 is a diagram showing the status of the element stack during the conversion of the document shown in FIG. 5;
FIG. 34 is a diagram showing the status of the element stack during the conversion of the document shown in FIG. 5;
FIG. 35 is a diagram showing the status of the element stack during the conversion of the document shown in FIG. 5;
FIG. 36 is a block diagram illustrating a hardware configuration example of the present invention.
[Explanation of symbols]
230-330 Sub-element / Link list data structure
340 element stack
360 Double linked list data structure
374 back pointer
376 next pointer
380 Attribute buffer
700 to 810 Double linked list data structure
850 element stack
956 Input Controller
958 keyboard
960 mouse
962 print engine
964 Print Engine Interface
966 System bus
968 hard disk
970 floppy disk
972 Disk Controller
974 Communication controller
976 I / O controller
978 Printer
980 Hard Disk
982 Display Controller
984 Network

Claims

A file format converter for converting a binary-encoded document file (binary file) to a clear text-encoded document file (text file),
Means for inputting a binary file,
Means for converting the elements of the binary file into a text format;
Means for writing the text format of the element to a first buffer;
Means for determining whether attributes are required for the element,
Means for determining whether a sub-element of the binary file is an attribute of the element or the sub-element is an attribute of the element;
Means for converting the sub-element to the text format;
Means for writing the text format of the sub-element of the element to a second buffer when the sub-element is determined not to be an attribute of the element and an attribute is determined to be required for the element ,
Means for processing the binary file until the required attribute is encountered when the sub-element is determined not to be an attribute of the element and the attribute is determined to be required for the element;
Means for converting the required attribute to the text format when the sub-element is determined not to be an attribute of the element and the attribute is determined to be required for the element;
When it is determined that the sub-element is not an attribute of the element and it is determined that an attribute is required for the element, the text format of the required attribute is stored in the element storing the element. Means for writing to a first buffer; and when the sub-element is determined to be an attribute and the attribute is determined to be required for the element, the text format of the sub-element is stored in the first buffer. Means for writing to the
A format conversion device comprising:

The format conversion device according to claim 1,
Means for writing the text format of the sub-element of the element to the second buffer, writing the text format of the sub-element of the element to the second buffer referencing the first buffer;
And, after the sub-element is determined not to be an attribute of the element, performing a step of writing the text format of the required attribute to the first buffer storing the element. Means for finding the first buffer by tracing backward from the second buffer before performing the format conversion.

2. The format conversion apparatus according to claim 1, wherein the means for writing the text format of the sub-element of the element to the second buffer refers to the first buffer backward and the next buffer forward. Writing the text format of the sub-element of the element to the second buffer, which is a list, and the format conversion device determines that the required text after the sub-element is not an attribute of the element. Prior to performing the step of writing the text format of the attribute to the first buffer storing the element, further comprising means for tracing backward from the double linked list to find the first buffer. A format converter characterized by the above-mentioned.

A Four mat conversion device file to be converted from the binary encoding document file (binary file) to the clear text encoding document files (text files),
Means for inputting a binary file,
Means for converting the elements of the binary file into a text format;
Means for writing the text format of the element to a first buffer;
By tracing through a data structure that stores the allowed sub-elements of the element, the sub-element of the element of the binary file is a permitted sub-element of the element, or the sub-element is Means for determining whether the element is an unacceptable sub-element of the element,
Means for indicating an error when the sub-element is determined to be an unacceptable sub-element of the element, and means for displaying the binary file when the sub-element is determined to be an unacceptable sub-element of the element Means for converting the subsequent part into the text format;
A format conversion device comprising:

5. The format conversion apparatus according to claim 4, wherein the means for determining the sub-elements of the element by tracing a sub-element linked list data structure storing each of the permitted sub-elements of the element. Determine whether the element is an allowed sub-element of the element or the sub-element is an unacceptable sub-element, and if the sub-element is found in the sub-element linked list data structure, the sub-element is allowed A format conversion apparatus, wherein if the sub-element is not found in the sub-element linked list data structure, the sub-element is determined to be unacceptable.