JP4098838B2 - 文書フォーマット変換方法 - Google Patents
文書フォーマット変換方法 Download PDFInfo
- Publication number
- JP4098838B2 JP4098838B2 JP09471895A JP9471895A JP4098838B2 JP 4098838 B2 JP4098838 B2 JP 4098838B2 JP 09471895 A JP09471895 A JP 09471895A JP 9471895 A JP9471895 A JP 9471895A JP 4098838 B2 JP4098838 B2 JP 4098838B2
- Authority
- JP
- Japan
- Prior art keywords
- tag
- binary
- stack
- spdl
- encoding
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Document Processing Apparatus (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は文書のフォーマット変換の方法に係り、より具体的には、テキストエンコード文書（textual encoded document）をバイナリエンコード文書（binary encoded document）へ変換する方法に関する。特に本発明は、クリアテキストエンコードの標準ページ記述言語文書（clear text encoded Standard Page Description Language document）からバイナリエンコードの標準ページ記述言語文書への変換に関する。本発明は、文書をサイズを縮小したフォーマットへ変換することよりデータ圧縮機能をも達成するものである。
【０００２】
【従来の技術】
１つの標準化ページ記述言語が提案され、国際標準化機構（ＩＳＯ）で国際規格として開発中である。この提案は、本願発明者の一人もその関与者であるが、現在、ＩＳＯの１セクションに草案として提出されている。この草案は、ＩＳＯ／ＩＥＣ ＤＩＳ １０１８０ ”ＩＮＦＯＲＭＡＴＩＯＮ ＰＲＯＣＥＳＳＩＮＧ−ＴＥＸＴ ＣＯＭＭＵＭＩＣＡＴＩＯＮ−ＳＴＡＮＤＡＲＤ ＰＡＧＥ ＤＥＳＣＲＩＰＴＩＯＮ ＬＡＮＧＵＡＧＥ”として知られており、ニューヨークの米国規格協会（”ＡＮＳＩ”）で入手可能である。
【０００３】
標準ページ記述言語（”ＳＰＤＬ”）は階層的に構造化されたページ記述言語である。この構造化された階層によれば、文書の一部分の印刷をする場合に、当該部分に影響する可能性のあるフォーマット用コマンドを文書全体にわたっては調べる必要がなくなる。所望の部分を印刷するのに、その印刷したい部分より階層が上の文書の部分だけを処理すれば足りる。
【０００４】
ＳＰＤＬのもう１つの利点は、ＳＰＤＬがＩＳＯ ８８７９：１９８６ に定義された標準一般化マークアップ言語（Standard Generalized Markup Language，”ＳＧＭＬ”）に準拠していることである。このことにより、文書構造を包括的に記述し結び付けることが可能になる。複数のファイルは、ＳＧＭＬで結びつけられたならば、変換ユーティリティを用いる事なく、かつ構造フォーマットを損なうことなく、あるプラットフォームから他のプラットフォームへ切れ目なく移動できる。
【０００５】
ＳＰＤＬは、ＡＳＮ．１に述べられているベーシック・エンコーディング規則（Basic Encoding Rules）に準拠している。ＡＳＮ．１に関する完全な解説は、Douglas Steedman著”ＡＳＮ．１，The Tutorial and Reference”（１９９０年）に詳しい。
【０００６】
クリアテキスト（clear text）言語は、人間が読むことのできるコンピュータ言語の一種である。ノンクリアテキスト（non−clear text）言語の一例をあげるならば、文書のバイナリ・エンコーディング（binary encoding）であろう。２進もしくは１６進表現の文書を見ても、人間には文書内容を容易には理解できないからである。バイナリ・エンコード文書の１つの主要な利点として、２進表現の文書は同等のクリアテキスト形式の文書に比べて必要とする記憶スペースが非常に少ない事がある。このことがバイナリ文書の記憶スペースの減少及び伝送時間の高速化を可能にする。しかしクリアテキスト・エンコードの文書に比べ、特殊なソフトウエアを用いないとバイナリ・エンコードの文書を編集すること、理解することが困難である。
【０００７】
したがって、前述のように文書のクリアテキスト・エンコーディングにもバイナリ・エンコーディングにも長所と短所があるので、文書を一方のフォーマットから他方のフォーマットへ変換したいことがあろう。
【０００８】
【発明が解決しようとする課題】
本発明の目的は、クリアテキスト・エンコードの文書をバイナリ・エンコードの文書へ変換する方法を提供することである。詳しくは、クリアテキスト・エンコードの標準ページ記述言語文書を等価なバイナリ・エンコードの標準ページ記述言語文書へ変換する方法を提供することである。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、本発明によるフォーマット変換方法の骨子は、ＣＰＵが、ＳＰＤＬクリアテキストデータを入力するステップ；入力されたＳＰＤＬクリアテキストデータのエレメントのタグが開始タグである場合は、そのタグのバイナリエンコードの記述に追加の部分が存在するか否かを判定するステップ；追加の部分が存在すると判定された場合に、スタックのトップエントリーに記憶されているバイナリエンコードの記述が追加の部分であるか否かを判定するステップ；スタックのトップエントリーに記憶されているバイナリエンコードの記述が追加の部分であると判定された場合に、その追加の部分が、入力されたエレメントのタグにおける追加の部分と同じであるか否か判定するステップ；同じでないと判定された場合に、スタックのトップエントリーに記憶されているタグのバイナリエンコードの記述に基づいて、バイナリデータを作成してトップエントリーをポップし、次に、入力されたエレメントのタグについて、追加の部分を入れたエントリーをスタックに追加し、さらにバイナリエンコードの記述で常に出現する必要がある部分を入れたエントリーをスタックに追加するステップ；同じであると判定された場合に、入力されたタグに対するバイナリエンコードの記述で常に出現する必要がある部分を入れたエントリーのみをスタックに追加するステップ；入力されたＳＰＤＬクリアテキストデータのエレメントのタグが終了タグである場合は、スタックのトップエントリーに記憶されているタグのバイナリエンコードの記述に基づいて、バイナリデータを作成してトップエントリーをポップするステップ；を実行するものである。
【００１０】
本発明による上記目的を達成するための手段の理解をより容易にするため、後記実施例との関連を考慮して少しく具体的にさらに説明する。
【００１１】
バイナリＳＰＤＬ文書に要求されるフォーマットのゆえに、及び、クリアテキスト表現とバイナリ表現との間に１対１の対応関係がないため、発明者はクリアテキスト・エンコード文書をバイナリ・エンコード文書に変換するために単純なルックアップ（look−up）プロシージャを行なうことは不可能であると判断した。様々なバイナリシンボル（binary symbol）の表わす内容は、ＳＰＤＬ文書中におけるバイナリシンボルのロケーションに依存する。
【００１２】
本発明が扱わなければならないもう１つの課題は、バイナリエンコードされたプロセスそれぞれの長さを管理することである。ＳＰＤＬは階層的に構造化されたページ記述言語であり、バイナリ・エンコーディングの各階層レベルの始まり部分は、該レベルが固定長フォーマットまたは不定長フォーマットのいずれでエンコードされているかを示し、かつ、固定長バイナリ・エンコーディングが存在する時にはエンコーディングの長さを示す。本発明が扱うもう一つの課題は、クリアテキスト・エンコーディングにおける特定のエレメントの順序がバイナリ・エンコーディングでは変更されなければならないという事である。したがって、クリアテキストＳＰＤＬフォーマットにおいて要求されるエンコーディング順序を知る必要がある。また、特定のクリアテキストエレメントは、該エレメントのテキスト表現の前に現われるエレメントによって、異なったバイナリ表現をとることがある。
【００１３】
本発明は、クリアテキストからバイナリへの変換を遂行するが、その遂行のために長さ制御スタック（length control stack）を使用してエレメントをその変換中に管理する。この長さ制御スタックによって、各階層レベルの長さがそのレベルの完了まで分からなくとも、クリアテキストからバイナリへの変換を実行できる。
【００１４】
クリアテキストタグ（tag）は、エレメントテーブル（element table）に格納される。このエレメントテーブルは、エレメントの下に出現可能なサブエレメントに関する情報を管理するために用いられるサブエレメント連結リスト（sub−elemtnt linked list）データ構造を指示するポインタを持っている。このサブエレメント連結リストデータ構造は、その第１エントリーとして、１個以上のＡＳＮ．１タグを記憶するＡＳＮ．１ ＴＡＧＳ エントリーを持っている。ＡＤＤＩＴＩＯＮＡＬ ＡＳＮ．１ ＴＡＧ フィールドはポインタを格納し、このポインタはヌル（null）を指すか、または、付加的なＡＳＮ．１タグが必要となきはそれを指す。
【００１５】
クリアテキスト・タグ ＳＴＲＣＴＩＤ を処理する場合、当該タグに対するバイナリ表現は該クリアテキストＳＴＲＣＴＩＤに関するパラメータによって異なる。ＳＴＲＣＴＩＤのどのバイナリ表現を用いるべきか決定するためには、クリアテキストＳＰＤＬ文書の一部を実際に処理する必要がある。このことは、その文書が単にあるフォーマットから他のフォーマットへ変換されるだけで、プレゼンテーション（presentation）装置によりプレゼンテーションするための処理が行なわれない場合でも、そうである。しかし、文書をプレゼンテーションするための処理は、変換プロセスの前でも後でも可能である。ＳＴＲＣＴＩＤエレメントを処理するため、各種階層レベルを管理するピクチャー／ページセット（picture／pageset）スタックが用いられる。ピクチャー／ページセットスタックの各エントリーは、少なくともページセットレベル及びピクチャーレベルを含む１つのデータ構造を指示する。また、このデータ構造内に、ＳＴＲＣＴＩＤ 連結リストデータ構造を指すポインタがある。このデータ構造は構造ＩＤを表示するエレメント、構造タイプ、及び次の構造ＩＤ連結リストデータ構造へのポインタを含む。
【００１６】
変換プロセス中に、クリアテキスト表現の各種ＳＰＤＬエレメントのアトリビュートの順序がバイナリ表現に要求される順序と違うことがある。したがって、エレメントそれぞれに対するアトリビュートを管理するため、一時的アトリビュートバッファ（temporary attribute buffer）データ構造が使用される。１つのエレメントの全アトリビュートが一時的アトリビュートバッファ連結リストに書き込まれた後、一時的アトリビュートバッファ連結リストは、アトリビュートを適切な順序、すなわち当該エレメントのサブエレメント連結リストデータ構造内での順序に対応した順序にするように、並べ替えられる。
【００１７】
【作用】
以上に述べたように、本発明のフォーマット変換方法によれば、クリアテキスト・エンコード文書（例えばＳＰＤＬ文書）を入力することにより、それと等価なバイナリ・エンコード文書（ＳＰＤＬ）を生成することが可能である。
【００１８】
【実施例】
以下、添付図面を参照し、本発明の実施例を説明する。なお、添付図面中の複数の図面にわたって、同一の参照数字は同一部または対応部を示すものである。
図１に、バイナリエンコード文書に対する固定長及び不定長フォーマットのネスティング（nesting）の一例が示されている。図１は、生成されるべき１つのデータストリームもしくは文書データストリームを表わすと考えることができる。行１〜行１６及び行１７〜行１９は最高階層レベルの２つのエンコーディングであるが、行１〜行１６内にはネストされたエンコーディングがある。行１〜行１６のエンコーディングのコンテント（content）は４００バイトの固定長である。これら４００バイト内において、まず行４〜行１３に１つの不定長構造がある。この行４〜行１３の不定長コンテント内に、２４８バイト及び４０バイトの固定長コーディングがある。行４〜行１３の４００バイトのコンテントからなる不定長エンコーディングに加えて、１００バイトのコンテントを含む行１４〜行１６の固定長エンコーディングがある。図１の行１７〜行１９には、２５０バイト長の固定長エンコーディングが含まれる。
【００１９】
”固定長フォーマットと不定長フォーマットのネスティング”なるタームは、ある不定長エンコーディングが、そのコンテントとして、１つの不定長エンコーディングと１つの固定長エンコーディング、あるいは、これら２つのエンコーディングの組合せを持つことができる、ということを意味する。このことは、その固定長エンコーディングが、その不定長エンコーディングが終わる前に始まることを意味する。上記タームは不定長エンコーディングを含む固定長エンコーディングにも同様に当てはまる。すなわち、不定長エンコーディングは固定長エンコーディングが終わる前に開始可能である。さらに、１つのエンコーディング内に、任意数の任意タイプのエンコーディングをネストできる。
【００２０】
図１から分かるように、バイナリエンコーディングの長さを、そのコンテントが現われる前にエンコードする必要がある。したがって、長さ計算が可能であるためには、その前にコンテントをクリアテキストからバイナリ表現へ変換しておく必要がある。しかし、不定長エンコーディングが図１の行４〜行１３のエンコーディングのような不定長エンコーディングの時には、その長さを知っている必要はない。行１３にあるエンコーディング”０００Ｈ”は不定長エンコーディングの長さを示す。
【００２１】
本発明のフローチャートは、固定長バイナリエンコーディングへの変換を示している。しかし、本発明は不定長エンコーディングをカバーすることをも意図しており、これは、不定長エンコーディングの初めに、知られている適当な不定長エンコーディングタグ（tag）を挿入し、かつ、その不定長エンコーディングの終わりに適当な終了情報（”０００Ｈ”）を挿入することにより、容易に達成される。
【００２２】
さて、ＡＳＮ．１に要求されるエンコーディングであるが、図２はＩＳＯ／ＩＥＣ８８２４に定義されたベーシック・エンコーディング規則に従ったバイナリエンコーディングの構造を示している。このエンコーディングは１個以上のアイデンティファイア・オクテット（identifier octet）で始まり、１個以上の長さオクテット（length octet）が続き、これにコンテント・オクテット（contents octet）が続く。
【００２３】
ＩＳＯ／ＩＥＣ ８８２４で定義されたアイデンティファイア・オクテットの構造が図３に示されている。このアイデンティファイア・オクテットの初めの２ビットはエンコーディングのクラス（class）を表わす。図３に示されたビット８及びビット７で定義される可能なエンコーディング・クラスはユニバーサル（universal）、アプリケーション（application）、コンテント・スペシフィック（content−specific）、及びプライベート（private）の４つである。ＡＳＮ．１のエンコーディングの完全な解説は、ＩＳＯ／ＩＥＣ ８８２４及びＩＳＯ／ＩＥＣ ８８２５（いずれも引用によって本明細書に組み込まれる）に見られる。しかし、本発明の作用を理解するのに、様々なクラスのエンコーディングに関する理解は必要としないので、これ以上の詳細説明は簡略化のため省略する。
【００２４】
図３に示したビット６は、エンコーディングがプリミティブ（primitive）であるか複合（constructed）であるかを決定する。プリミティブとは現エンコーディング内にネストされたエンコーディングが全然存在しないことを意味し、複合とは現エンコーディング内にほかのエンコーディングがネストされていることを意味する。図３に示されているビット５〜ビット１は、タグの番号に関するものである。タグの番号が３１を超えるときには、ビット５〜ビット１は同番号を表現するには足りないので、アイデンティフアイア・オクテットの最後の５ビットは１１１１１に設定され、後続のアイデンティファィア・オクテットで該タグの番号をエンコードする。様々なタグ番号の完全な理解は、本発明の作用を理解するために必要とされないので、簡略化のため省略する。
【００２５】
アイデンティファイア・オクテット及び長さオクテットはプリアンブル（preamble）情報と考えることができ、コンテント・オクテットはコンテント情報と考えることができる。
【００２６】
当業者にとっては、以上の説明でバイナリＳＰＤＬエンコーディングの基本を理解するのに十分であると考えられる。しかし、バイナリ・エンコーディングの処理に関するより詳細かつ完全な説明は、同時係属米国特許出願第０８／０６６，３８３号（”ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＰＲＯＣＥＳＳＩＮＧ ＭＩＸＥＤ ＢＩＮＡＲＹ ＬＥＮＧＴＨ ＥＮＣＯＤＩＮＧ ＣＯＮＴＡＩＮＩＮＧ ＤＥＦＩＮＩＴＥ ＡＮＤ ＩＮＤＥＦＩＮＩＴＥ ＬＥＮＧＴＨ ＦＯＲＭＡＴＳ”）に見ることができる。しかし、本出願の主要な関心事及び処理はファイルをクリアテキストからバイナリ表現へ変換することであるのに対し、上記関連出願に述べられている処理は主としてプリンタ、ＣＲＴ等による文書の出力（presentation）に関係するものである。
【００２７】
本発明は各種ＳＰＤＬエレメントの情報を管理するためにエレメントテーブル（element table）とサブエレメント連結リスト（sub−element linked list）データ構造を用いる。ＳＰＤＬは階層的に構造化されたページ記述言語であり、エレメントテーブル及びサブエレメント連結リストの情報を生成するためにＳＰＤＬの階層構造を確定する必要があった。
【００２８】
ＳＰＤＬの階層秩序を確定するため、発明者は、規格草案に含まれているＳＰＤＬエレメントの記述を用い、図４に示すようなＳＰＤＬエレメント状態遷移ダイヤグラムを作成した。図４は、ＳＰＤＬ構造エレメントの階層構造を、それに包含されているツリー構造を用いて説明し、また１つのエレメントから出て同じエレメントに戻るラベル付けしたアトリビュート用円弧矢印を示すことにより、各種ＳＰＤＬエレメントに対するアトリビュートを説明する。この状態遷移ダイヤグラムより、発明者は本発明に用いられるエレメント・テーブルとサブエレメント連結リストを生成することができた。
【００２９】
状態遷移ダイヤグラムの最初のエレメントはＳＰＤＬ１５２である。このＳＰＤＬエレメントの下に出現できる２つの可能なエレメントがある。文書エレメント１５４とリソース定義（resource definition）エレメント１５６である。このリソース定義エレメント１５６はリソース・アトリビュート、ＳＰＤＬ ＩＤアトリビュート及びファンクション（function）アトリビュートというアトリビュートを持つ如く示されている。アトリビュートは固定値を持つことも、ユーザによって入力された値を持つこともできる。
【００３０】
図４において、特定の階層構造における終端（terminal）エレメントつまり最も下のエレメントはアスタリスクが付けられており、また、前に定義済みのエレメントはプラス記号が付けられている。特定の階層構造の最低レベルには終端エレメントが存在できるが、他のエレメントは存在できない。
【００３１】
図４に示したＳＰＤＬエレメント状態遷移ダイヤグラムは完全なものではなく、簡略化のためにＳＰＤＬ構造エレメントの一部が省略されている。例えば、リソース・スペシフィケーション（specification）１６４、上位エレメントとして外部宣言（external declaration）を持つ構造ＩＤエレメント１９６、情報宣言１７４、リソース定義１７６、リソース宣言１７８、ＤＰＩ宣言１８０、コンテキスト（context）宣言１８２、セットアップ（set−up）プロシージャ１８６の下に来る構造エレメントがある。
【００３２】
文書構造エレメント１５４の下にページセット（pageset）エレメント１５８とピクチャー（picture）エレメント１６０がある。ページセット１５８の下にページセットボディ（ｂｏｄｙ）１６６とプロローグ（ｐｒｏｌｏｇｕｅ）１７２がある。図４に示されるように、ピクチャーエレメント１６０はページセットボディ１６６の下に出現することも可能である。ピクチャーエレメント１６０はコンテント表現のアトリビュート（前記関連出願においてコンテント・タイプと呼ばれたもの）とＳＰＤＬ ＩＤとを有する。ピクチャーエレメント１６０の下に出現可能なＳＰＤＬエレメントはプロローグ１７２とピクチャーボディ１６８である。トークン（token）シーケンス１７０は、ピクチャーボディ１６８の下に出現可能である。プロローグ１７２の下に出現する辞書ジェネレータ（dictionarygenerator）１８４の下に、サイズのアトリビュートを持つ辞書ジェネレータエレメント１８８が出現可能である。辞書１８８の下に出現可能なＳＰＤＬエレメントは、辞書ＩＤ１９０、ネーム（ｎａｍｅ）１９４及びトークンシーケンス１９２である。
【００３３】
なお、図４はＳＰＤＬに対する最近の変更を反映しておらず、また、ＳＴＲＣＴＩＤエレメントが出現可能な場所が２９ある。図４は背景情報として用意されたもので、当業者によれば、ＳＰＤＬに関する文献及び情報を利用し、精密な最新のＳＰＤＬエレメント状態遷移ダイヤグラムを作成できるであろう。しかし、状態遷移ダイヤグラムがどのようなものかの一例として図４が用意された。
【００３４】
図５は、典型的なバイナリＳＰＤＬ文書を１６進表現で示している。図５に示された文書と等価なクリアテキスト文書が図６に示されている。本発明を作用させると、図６に示した文書を入力して図５に示した形式へ変換することができる。なお、図５，図６及び図７はＳＰＤＬ規格の前の草案に合わせたものであるので、エレメントネームの中には最新草案に入っているエレメントネームと違うものがあるかもしれない。しかし、これは問題ではない。図５及び図６の目的は、クリアテキスト文書とバイナリ文書との間の対応関係を説明することだからである。本発明の作用を説明した後ならば、もっとよく図５及び図６の詳細が理解されよう。
【００３５】
図７は、図５に示された文書が図６に示された文書とどのように対応するかを説明するものである。図７より分かるように、６１はエレメントであるページセットを表わしている。６１の後の５９は、このページセットの長さ（ｌｅｎｇｔｈ）を表わしている。このページセット内に、ＡＳＮ．１タグ０６により表わされたＳＰＤＬ ＩＤがある。このＳＰＤＬ ＩＤの長さは４である。実際のＳＰＤＬ ＩＤは”ＩＳＯ/ＩＥＤ １０１８０//ＳＰＤＬ”であり、”２８ ＣＦ ４４ ００”によって表わされている。
【００３６】
次に、図７において、ＡＳＮ．１タグ４４がコメントに対応することが分かる。このコメントの長さは１Ｆである。このコメントの内容は”ＳＰＤＬ ＩＤ＝Public Object ＩＤ value ”である。次に、Ａ１はページセットボディとも呼ばれるところのｐｓｂｏｄｙを表わすことが分かる。図７の残りの部分も、同様に理解することができる。したがって、図７における対応関係の完全な説明は簡略化のため省略する。
【００３７】
図８は、クリアテキスト入力ファイルをバイナリ出力ファイルへ変換するために用いられる概念的構成を示す。クリアテキストデータ２０２はパーサー（parser）２０４によって文法解析される。この文法解析（parsing）は普通の公知メカニズムによって遂行されるので、その説明は簡略化のため省略する。
【００３８】
解析されたクリアテキストデータは、クリアテキスト−バイナリ・トランスレータ（translator）２０６及びＳＰＤＬ構造プロセッサ２０８へ送られる。クリアテキスト−バイナリ・トランスレータはＳＰＤＬ構造に関する特定の情報を知る必要があり、この情報はＳＰＤＬ構造プロセッサ２０８より与えられる。ＳＰＤＬ構造プロセッサは、ＳＰＤＬ規格案の新しい草案では構造アイデンティフィケーション（ＳＴＲＣＴＩＤクリアテキストタグ）とも呼ばれる外部宣言を管理するために利用され、また構造ＩＤ及び構造タイプを管理するために利用される。クリアテキスト−バイナリ・トランスレータ２０６は、ファイルのバイナリ表現をバイナリデータ２１０として出力する。
【００３９】
図９は図８のＳＰＤＬ構造プロセッサ２０８により文書を実際に処理するために用いられるデータ構造を示している。図９に示したデータ構造の利用法に関しては、米国特許出願第０７／８７６，２５１号（１９９２年４月３０日受理，”ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＴＯ ＨＡＮＤＬＥ ＩＮＣＬＵＳＩＯＮ ＯＦ ＥＸＴＥＲＮＡＬ ＦＩＬＥＳ ＩＮＴＯ Ａ ＤＯＣＵＭＥＮＴ ＰＲＯＣＥＳＳＩＮＧ ＬＡＮＧＵＡＧＥ”及び米国特許出願第０７／８７６，６０１号（１９９２年４月３０日受理，”ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＴＯ ＭＡＮＡＧＥ ＰＩＣＴＵＲＥ ＡＮＤ ＰＡＧＥＳＥＴＦＯＲ ＤＯＣＵＭＥＮ ＰＲＯＣＥＳＳＩＮＧ”に完全に述べられている。なお、これら出願（本出願はその一部継続出願である）は、処理中に取り込まれるべき外部ファイルに関するＳＰＤＬ構造エレメントである外部宣言に言及している。しかし、ＳＰＤＬ規格の新草案は、外部宣言中のエレメントＥＸＴＩＤの代わりに構造エレメントＳＴＲＣＴＩＤをエレメントネームに指定しているが、本出願の図９に示された並びに米国特許出願第０７／８７６，２５１号及び第０７／８７６，６０１号に示された各種データ構造により遂行される機能は同様である。さらに、同時係属米国特許出願第０８／０８７，５７１号（１９９３年７月２日受理，”ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＴＯ ＨＡＮＤＬＥ ＣＯＮＴＥＸＴ ＯＦＩＮＴＥＲＰＲＥＴＡＴＩＯＮ ＩＮ Ａ ＤＯＣＵＭＥＮＴ ＰＲＯＣＥＳＳＩＮＧ ＬＡＮＧＵＡＧＥ”に述べられている、より進歩した処理メカニズムを、構造及びコンテントの処理のために利用することもできる。
【００４０】
図９のピクチャー／ページセットスタック２２０は、文書の様々な階層レベルの管理のために利用される。文書の最初の階層レベルはピクチャー／ページセットスタック２２０のポインタ２２４に対応し、このポインタ２２４は連結リストデータ構造２２６を指す。このデータ構造２２６はページセットレベル（pageset level）２２８及びピクチャーレベル（picturelevel）２３０を管理するために利用される。また、データ構造２２６は、構造ＩＤ連結リストデータ構造２４２を指す外部宣言（externl declaration）ポインタ２３２を含む。このデータ構造２４２はＳＴＲＣＴＩＤタグに関連した構造ＩＤ及び構造タイプを管理するために利用され、外部宣言でも参照される。ＳＰＤＬ構造の処理期間に、ある階層レベルの処理中にもう１つのＳＴＲＣＴＩＤエレメントが出現すると、追加の構造ＩＤ連結リストデータ構造が、データ構造２２６と、外部宣言ポインタ２３２により前に指示されていたデータ構造との間に挿入される。例えば、外部宣言ポインタ２３２が構造ＩＤ連結リストデータ構造２５０を指していて、ＳＰＤＬ文書中に次のＳＴＲＣＴＩＤ構造エレメントが出現すると、構造ＩＤ連結リストデータ構造２４２がデータ構造２２６とデータ構造２５０の間に挿入されることになる。
【００４１】
文書の次の階層レベルが出現した時に、追加のエントリー２２２がピクチャー／ページセットスタック２２０にプッシュされる。また、新しいデータ構造２３４が生成され、このデータ構造２３４は外部宣言ポインタ２３２と同一の外部宣言ポインタ２４０を持つ。
【００４２】
図１０は、本発明の変換プロセスに利用される一時的アトリビュートバッファ（temporary attribute buffer）データ構造を示す。アトリビュートとはエレメントのサブエレメントであり、当該エレメントの属性を定義する。ＳＰＤＬクリアテキストにおけるアトリビュートの出現順序は、変換後のバイナリ文書に要求されるアトリビュート順序と異なることがある。クリアテキスト文書の各アトリビュートの処理変換時に、アトリビュートは一時的アトリビュートバッファデータ構造に書き込まれる。１つのエレメントに対して連続したアトリビュートが出現した時に追加の一時的アトリビュートバッファデータ構造２７０が生成され、このデータ構造２７０は前に生成された一時的アトリビュートバッファデータ構造のnextポインタにより指し示される。１つのエレメントに対する全アトリビュートの変換が終了すると、一時的アトリビュートバッファデータ構造の連結リストがバイナリ文書に要求される順序と比較され、順序に違いがあるときには、一時的アトリビュートバッファデータ構造は正しい順序に並べ替えられる。最初の一時的アトリビュートバッファデータ構造は、一時的アトリビュートポインタ２７２により指示される。一時的データ構造２７０はアトリビュートネーム（attribute name）のエントリー２７４とアトリビュート値（value）のエントリー２７６を有する。図１３乃至図１８に示したサブエレメント連結リストデータ構造に関連して、アトリビュートの例を説明する。
【００４３】
図１１に示したエレメントテーブルは、本発明の変換プロセスに利用される。変換されるべきファイルの１つのクリアテキスト（clear text）タグもしくはエレメントが出現する都度、このタグをエレメントテーブル２８０の第１カラムで調べる。図１１に示したクリアテキストタグの例は、！ＤＯＣＫＴＹＰＥ，ＳＰＤＬ，ＰＩＣＴＵＲＥ，ＰＩＣＴＢＤＹ，ＴＫＮＳＥＱＮである。
【００４４】
エレメントテーブル２８０の第２カラムは、ＡＳＮ．１表記法（notation）に関連したエレメント宣言に関するものである。このエレメント宣言はエレメントの属性の記述である。より具体的に言えば、エレメント宣言はエレメントの属性、及び、従属構造エレメントがあれば、その扱いに関するものである。各種宣言の例は、無宣言（ＮＯＮＥ）、オクテットストリング（octet string）、印刷可能ストリング、選択（choice）、シーケンス（sequence）、選択シーケンス（sequence of choice）、暗黙シーケンス（implicit sequence）である。なお、あらゆるクリアテキストタグ、各エレメント宣言及びクリアテキストタグに関する他の情報の全てを含む完全なエレメントテーブルは、ＳＰＤＬ規格案等の公知資料に見ることができ、また、それら資料を使って作成することができる。
【００４５】
本発明は、エンコーディングのシンタックスがＳＰＤＬエンコーディング条件に違反しないように、エレメント宣言を使用できる。
【００４６】
エレメントテーブル２８０の第３カラムは、エレメントに関するアトリビュート数を示す。前述のように、アトリビュートはエレメントに関する特定の特徴を記述するために用いられる。アトリビュート数のカラムにおいて、疑問符は該クリアテキストタグのためにアトリビュートがいくつ必要であるか分からないことを示し、０は該タグのためのアトリビュートがないことを示し、１は該タグのためにアトリビュートが１個あることを示す、等々である。
【００４７】
エレメントテーブル２８０の第４カラムは、該エレメントの下に出現できる各種サブエレメントの個数を示す。例えば、！ＤＯＣＴＹＰＥのエレメントもしくはクリアテキストタグの直ぐ下に出現できるサブエレメントは、１個だけである。ＳＰＤＬタグの下には、２５の異なったタイプのサブエレメントが出現可能である。
【００４８】
エレメントテーブル２８０の第５カラムは、サブエレメント連結リストへのポインタである。これらの連結リストは、エレメントの下に出現可能なサブエレメントに関する情報を記憶している。ＴＫＮＳＥＱＮタグは、どのようなサブエレメントもその下に出現しないので、そのサブエレメント連結リストデータ構造へのポインタはヌル（null）を指す。
【００４９】
図１２はサブエレメント連結リストデータ構造２８２を示す。これらのデータ構造は、図１１に示したエレメントテーブル内のサブエレメントへのポインタによって指示または参照でき、あるいは、別のサブエレメント連結リストデータ構造のnextポインタにより参照できる。
【００５０】
図１２に示したサブエレメント連結リストデータ構造２８２の第１フィールド２８４は、１つのサブエレメントのバイナリ表現を含む１つ以上のＡＳＮ．１タグを記憶する。第２フィールド２８５は、該サブエレメントのクリアテキスト表現を記憶する。第３フィールドはタイプ（type）フィールド２８６であり、サブエレメントのタイプを示す。このタイプは１つのタグもしくはアトリビュートであり、これはＡＴＴと略されることがある。
【００５１】
シーケンス番号エントリー２８７は、順序がバイナリエンコーディングで重要である場合に、サブエレメントがエレメント後のどこに出現しなければならないかを示す。例えば、シーケンス番号が１の場合、サブエレメントがエレメントの後に出現すれば、それはエレメント後に最初に出現するサブエレメントでなければならない。
【００５２】
フィールド２８８は、追加ＡＳＮ．１タグへのポインタを格納する。一定のＳＰＤＬエレメントは２つ以上のバイナリタグを必要とし、これらのエレメントについては、ポインタ２８８は追加ＡＳＮ．１タグ２８９を指す。それ以外のエレメントについては、ポインタ２８８はヌルを指す。
【００５３】
同じエレメントに関する一定の複数のサブエレメントは、同じ追加ＡＳＮ．１タグを持つという点で関連付けられる。この追加ＡＳＮ．１タグは、関連したサブエレメント中の１つが最初に変換された時に出現しなければならないが、同じ追加ＡＳＮ．１タグを持つ後続の関連サブエレメントの後には出現してはならない。しかし、サブエレメント連結リストの第１フィールドであるＡＳＮ．１フィールドは、サブエレメントの表現のために常に出現する。サブエレメント連結リストデータ構造の追加ＡＳＮ．１タグフィールドに関係するのが、図１９に示す長さ制御スタック（length control stack）中にある追加タグ（additionaltag）フラグである。この追加タグフラグは、長さ制御スタック中の追加タグであるエントリーについてはyesである。そうでなければ、追加タグフラグはnoである。図１９に示した長さ制御スタックに関するこれ以上の説明は、フローチャートと関連させて行なう。
【００５４】
サブエレメント連結リストデータ構造２８２の最後のエントリーは、次のサブエレメント連結リストデータ構造を指すnextポインタ２９０である。１つのエレメントに対し２つ以上のサブエレメントが存在するときには、各サブエレメントはそれ固有のサブエレメント連結リストデータ構造を持ち、その最初のサブエレメント連結リストデータ構造のｎｅｘｔポインタは２番目のサブエレメントのサブエレメント連結リストデータ構造を指す。
【００５５】
図１３は、！ＤＯＣＴＹＰＥエレメントのためのサブエレメント連結リストデータ構造を示す。このサブエレメントはＳＰＤＬタグであり、ＳＰＤＬのＡＳＮ．１表現は２８Ｈである。ＳＰＤＬは！ＤＯＣＴＹＰＥのための唯一のサブエレメントであるので、シーケンス番号は１である。２８Ｈは１つのタグであるので、追加ＡＳＮ．１タグポインタはヌルを指す。！ＤＯＣＴＹＰＥエレメントに対するサブエレメントは１つしかないので、このサブエレメントのためのサブエレメント連結リストデータ構造のnextポインタもヌルを指す。
【００５６】
ＳＰＤＬエレメントは、図１４から分かるように、１つ目のページセット、２つ目のピクチャーというサブエレメントを持つ。これらサブエレメントはデータ構造３２０，３３０にそれぞれ格納されている。
【００５７】
ピクチャーエレメントの１番目のサブエレメントＣＯＮＴＲＥＰは、コンテント表現を示すもので、かってＳＰＤＬ規格の前草案でコンテントタイプと呼ばれた。このサブエレメントは図１５に示したデータ構造３４０に格納されている。このピクチャーエレメントの２番目のサブエレメントはＰＩＣＴＢＤＹであり、その情報はデータ構造３５０に格納されている。
【００５８】
なお、ＳＰＤＬエレメント及びピクチャーエレメントについては、２９個及び４個の可能なサブエレメントがそれぞれ存在することは図１１に示したエレメントテーブルに見られるとおりであるが、これらのサブエレメントのそれぞれは簡略にするため図１４及び図１５には示されなかった。しかし、これらのサブエレメント連結リストデータ構造は、ＳＰＤＬに関する公知情報を利用すれば誰でも作成可能である。
【００５９】
図１６は、ＰＩＣＴＢＤＹエレメントに対して可能なサブエレメントを示す。１番目の可能なサブエレメントはデータ構造３６０に格納されたＰＲＯＬＯＧＵＥ（プロローグ）である。プロローグを表現するには２つのタグが必要であるので、ＡＳＮ．１タグフィールドは６８Ｈであり、追加ＡＳＮ．１タグポインタはＡ０Ｈタグ３６８を指す。ＰＩＣＴＢＤＹエレメントに対する他のサブエレメントは、サブエレメント連結リスト３７０内のＳＴＲＣＴＩＤ、データ構造３８０内のＰＩＣＴＵＲＥ、データ構造３８２内のＴＫＮＳＥＱＮ（トークンシーケンス）、及び再び出現するデータ構造３８４内のＳＴＲＣＴＩＤである。
【００６０】
図１６から分かるように、ＰＩＣＴＢＤＹエレメントの下のＳＴＲＣＴＩＤサブエレメントは２つの異なったバイナリ表現を持つことができる、すなわち、１つ目はデータ構造３７０による Ａ０ ６Ｅ ４１ であり、２つ目はデータ構造３８４による Ａ１ ６Ｅ ４１ である。これらの異なったバイナリ表現は、変換されるべき文書に出現するＳＴＲＣＴＩＤクリアテキストタグの特殊な情報（ＳＰＤＬ規格の前の草案で外部宣言とも呼ばれたもの）に依存する。様々なＳＴＲＣＴＩＤサブエレメントの用法のより完全な説明は、フローチャートに関連して述べる。
【００６１】
図１７は及び図１８はＰＲＯＬＯＧＵＥエレメントのためのサブエレメント連結リストを示す。図１７に示したデータ構造３９６の最後のフィールドから出る線は、図１８に示したデータ構造３９８を指す。図１７及び図１８は、ＳＰＤＬに関する公知情報を用いて作成されたが、ＰＲＯＬＯＧＵＥエレメントの下には非常に多数のサブエレメントが出現可能であるので、サブエレメント連結リストの完全な図ではなく、データ構造４０８で終わっている。しかし、必要ならば、ＳＰＤＬ関連情報の公知資料を用いて完全なＰＲＯＬＯＧＵＥサブエレメント連結リストデータ構造を作成できる。
【００６２】
図１９は、ＳＰＤＬクリアテキスト文書がバイナリへ変換される時に利用される長さ制御スタック４２０を示す。最初に処理されるエレメントは、スタックのボトムにあって、通常、ＳＰＤＬタグである。クリアテキストタグは、第１カラムすなわちエレメントネームに出現する。スタックの第２カラムはＡＳＮ．１タグ値で、これはクリアテキストエレメントネームのバイナリ表現である。スタックの第３カラムはバッファカウント（count）で、バッファポインタにより指示されるバッファ４２２内の現在のバイト数を示す。追加タグフラグは、長さ制御スタックに記憶されているタグがサブエレメント連結リストデータ構造からの追加ＡＳＮ．１タグであることを示す。この情報は、後のサブエレメントに対し追加ＡＳＮ．１タグが存在するときに、それがクリアテキストエレメントのバイナリ表現に使用されるべきか判定するため該後のサブエレメントを処理する時に利用される。
【００６３】
さて、図２０乃至図２１に示したフローチャートを参照し、本発明の動作を説明する。図２０において、プロセスはステップ５００から始まり、ステップ５０２で構造パーサーを呼び出す。文法解析（parsing）が行なわれるが、これは公知の普通の文法解析メカニズムによってなされるので、その説明は簡略化のため省略する。図２０には３つの異なったプロセスがあり、これらを処理されているクリアテキストタグのタイプに応じて呼び出すことができる。処理されているタグがコメント（comment）タグであってコメントの始まりならば、ステップ５０６で図２１に示されているコメント（comment）プロセッサが呼び出される。変換されるタグがトークンシーケンス開始（begin）タグならば、フローはステップ５０８からステップ５１０へ進み、ステップ５１０で図２２に示されているトークンシーケンスプロセッサを呼び出す。処理すべき他の有効なタグがあれば、フローはステップ５１２からステップ５１４へ進み、図２７に示されているタグ（tag）プロセッサを呼び出す。ステップ５１２で処理すべき有効なタグがないと判定したときには、プロセスはステップ５１６で終了しエラーを表示する。
【００６４】
図２０には、処理の正常終了で終わるステップが含まれていないことに注意されたい。本発明の全体プロセスは図３０で終了する。図３０はＳＰＤＬ終了ルーチンを示しているが、これについては後述する。また、ステップ５０６，５１０，５１４は様々なプロセッサに言及するが、図に示したものは１つのプロセスを実行するためのフローチャートである。したがって、それらプロセスを実行する独立の物理プロセッサを持つ必要はなく、言及したプロセッサは概念的な機能要素である。
【００６５】
図２１に示されるコメントプロセッサは、コメントタグの処理を扱う。図２１において、ステップ５２２はコメントタグの最後まで入力データがスキップされることを示す。したがって、コメント情報は実際にはクリアテキストからバイナリへ変換されない。コメントはＳＰＤＬ文書の実際の処理に必要でないからである。しかし、コメント内の情報を保存したいときには、コメントプロセッサがその役割の実行を終了した後に図２７に示したタグプロセッサにコメントタグを処理させることによって、コメント情報をスキップしないでバイナリに変換することも可能である。ステップ５２４からフローは図２０のプロセスへ戻り、次の構造エレメントの文法解析のためにステップ５０２で構造パーサーが再度呼び出される。
【００６６】
図２０において、ステップ５０８とステップ５１０により図２２に示されたトークンシーケンスプロセッサが呼び出される。トークンシーケンスは文書のコンテントを含む構造エレメントである。図２２において、ステップ５５２が図２３に示された長さ制御スタックセットアップルーチン（後述）を呼び出す。次にステップ５５４で、トークンシーケンス構造エレメント内に含まれているコンテントを文法解析するコンテントパーサー（content parser）が呼び出される。この文法解析も普通の文法解析メカニズムにより遂行されるので、その説明は簡略化のため省略する。
【００６７】
ステップ５５６では、トークンシーケンスの終わりが検出されたか判定する。検出されていなければ、ステップ５６４で該トークンシーケンスを調べ、それが有効であるか判定する。有効でなければ、ステップ５６６でエラーコードが返される。該トークンシーケンスが有効ならば、ステップ５６８で該トークンシーケンスをバイナリ表現へ変換する。そしてステップ５７０で、そのバイナリ表現を長さ制御スタックに利用されるバッファに格納する。ステップ５７０からフローはステップ５５４へ戻る。トークンシーケンス終了タグが検出されたとステップ５５６で判定したときには、ステップ５５８で入力ポインタを、該トークンシーケンス終了タグの次のエレメントを指すように設定する。このポインタは、クリアテキスト入力ファイルの次に処理すべきエレメントを指示する。次にステップ５６０で、図２６に示された終了タグルーチンを呼び出す。このルーチンはトークンシーケンスエレメントの終了タグを処理するために用いられる。そして、ステップ５６２でフローは図２０へ戻る。
【００６８】
図２３、図２４及び図２５は”長さ制御スタックセットアップ（set−up）ルーチン”を示す。このルーチンは、１つの新しいクリアテキストタグが変換されようとするたびに、図１９に示した長さ制御スタックをセットアップするために利用される。この長さ制御スタックセットアップルーチンにおいて、Ｃurrent−Ｔagはエレメントテーブルを調べるために利用され、Ｔag−Ｒead−Ｉnはサブエレメント連結リストを調べるために利用され、Ｐrevious−Ｔagは処理されるタグの親エレメント（Ｔag−Ｒead−Ｉn）を格納するために用される。
【００６９】
長さ制御スタックセットアップルーチンが呼び出された後、図２３のステップ６０２で、変換しようとする新しいエレメント（Ｔag−Ｒead−Ｉn）が、処理されたばかりのエレメント（Ｃurrent−Ｔag）により指し示されるサブエレメント連結リストに見つかるか判定する。見つからないときには、変換しようとする該新エレメントは処理されたばかりのエレメントの適切なサブエレメントでないので、ステップ６０４でエラーが表示される。該新エレメントが適切なエレメントであるときには、ステップ６０６でＰrevious−Tag＝Ｃurrent−Ｔagに設定する。そしてステップ６０８で、Ｃurrent−Ｔagをたった今読み込まれたタグ（Ｔag−Ｒead−Ｉn）と等しい内容に設定する。
【００７０】
ステップ６１０で、Ｃurrent−Ｔagを格納しているサブエレメント連結リストの追加ＡＳＮ．１タグポインタがヌルを指すか判定する。該ポインタがヌルを指すか否かによって、異なる処理が実行される。該タグがヌルを指さないときには、フローは図２４に示されるプロセスＡＡへ進む。該タグがヌルを指すときには、図２４に示される各ステップと図２５の上部分は実行されず、フローは図２５に示されるＣＣへ進む。
【００７１】
該追加ＡＳＮ．１タグポインタがヌルを指さない場合、該ポインタにより指される追加ＡＳＮ．１タグが存在するので、フローは図２４に示されるプロセスＡＡへ進む。
【００７２】
図２４において、ステップ６２０で長さ制御スタックのトップエントリーの追加タグフラグがyesであるか判定する。yesでなければ、図２４のステップ６２２〜ステップ６３６を省くことができるので、フローは図２５に示されるプロセスＢＢへ進む。
【００７３】
長さ制御スタックのトップにある追加タグフラグがyesでないときには、フローはステップ６２２へ進み、ここで長さ制御スタックのトップエントリーのＡＳＮ．１タグが追加ＡＳＮ．１タグポインタに指されるタグと等しいか調べられる。等しければ、該追加ＡＳＮ．１タグに対し実行すべき処理はないので、サブエレメント連結リストのトップエントリーに格納されているＡＳＮ．１タグ（１つ又は複数）を処理するため、フローは図２５に示されるプロセスＣＣへ進む。長さ制御スタックのトップにあるＡＳＮ．１タグが該サブエレメント連結リストデータ構造の追加ＡＳＮ．１タグポインタにより指される追加ＡＳＮ．１タグと等しくなければ、該追加ＡＳＮ．１タグを処理する必要があるので、フローはステップ６２４へ進む。
【００７４】
ステップ６２４で、スタックのトップのバッファカウントを下のエントリーのバッファカウントに加える。ステップ６２６で、スタックのトップにあるＡＳＮ．１タグ値のバイト数を下のエントリーのバッファカウントに加える。ステップ６２８で、スタックのトップのバッファカウントのＡＳＮ．１ ＢＥＲ長さエンコーディングのバイト数を、下のエントリーのバッファカウントに加える。ステップ６３０で、スタックのトップのＡＳＮ．１タグ値を下のエントリーのバッファへ追加（アペンド）する。ステップ６３２で、スタックのトップのバッファを下のエントリーのバッファへ追加し、ステップ６３６で長さ制御スタックのトップエントリーをポップして捨てる。
【００７５】
図２５において、ステップ６４０で長さ制御スタックのトップに新しいエントリーを追加する。ステップ６４３で、この新しいエントリーのために１つのバッファを割り当て、スタックのトップエントリーのバッファポインタを該新バッファを指すように設定する。ステップ６４４で、追加ＡＳＮ．１タグポインタにより指される追加ＡＳＮ．１タグをスタックのトップに入れる。次に、ステップ６４６で、Ｐrevious−Ｔag（処理されるサブエレメントのエレメントのクリアテキストＳＰＤＬネーム）を長さ制御スタックのトップエントリーのエレメントネームフィールドに書き込む。ステップ６４８でスタックのトップエントリーのバッファカウントを０に設定し、ステップ６５０でスタックのトップエントリーの追加タグフラグをyesに設定する。
【００７６】
図２３及び図２４のＣＣ及びステップ６５０の次に、ステップ６５２でサブエレメントのＡＳＮ．１タグの処理を始める。ステップ６５２に初めて来た時は、処理されるべきサブエレメントのＡＳＮ．１タグがあるであろうから、フローはステップ６５４へ進む（長さ制御スタックのトップに１つのエントリーを追加する）。ステップ６５６でサブエレメント連結リストよりＡＳＮ．１タグを取得する。ステップ６５８で、該ＡＳＮ．１タグをスタックのトップエントリーに入れる。ステップ６６０で、スタックのトップエントリーのバッファを割り当て、スタックのトップエントリーのポインタを当該バッファを指すように設定する。ステップ６６２で、Ｃurrent−Ｔagをスタックのトップエントリーのエレメントネームに入れる。ステップ６６４でスタックのトップエントリーのバッファカウントを０に設定し、ステップ６６６で、現在処理されているタグは追加タグではなくサブエレメント連結リストの第１フィールドに格納されているタグであるので、スタックのトップエントリーの追加タグフラグをｎｏに設定する。ステップ６６６よりフローはステップ６５２に戻り、サブエレメント連結リストのトップフィールドのＡＳＮ．１タグの全部が処理されるまでステップ６５２〜６６６のループが実行される。これらＡＳＮ．１タグ全部が処理されると、フローは呼び出したプロセスへ戻る。
【００７７】
図２６は、クリアテキスト終了タグに達した時に長さ制御スタックの処理及び調整をするために用いられる”終了タグルーチン”を示す。開始すると、ステップ７０８でスタックのトップにあるエレメントネームが終了タグであるか判定する。終了タグでなければ、エラーがあるのでエラーメッセージが出される。終了タグであれば、フローはステップ７１０へ進む。
【００７８】
ステップ７０８でスタックのトップにあるエレメントネームが終了タグであると判定した場合、ステップ７１０で長さ制御スタックのトップエントリーのバッファカウントを、長さ制御スタックのトップエントリーより１つ下のバッファカウントエントリーへ加える。ステップ７１２で、ＡＳＮ．１タグのバイト数を下のエントリーのバッファカウントへ加える。次にステップ７１６で、スタックのトップエントリーのバッファの長さに関する長さ情報を表現するのに必要なバイト数を下のエントリーに加える。次にステップ７１８で、ＡＳＮ．１タグを下のエントリーのバッファに追加する。次にステップ７２０において、スタックのトップのバッファカウントの長さが下のエントリーのバッファへ加えられる。そして、ステップ７２４で、スタックのトップエントリーのバッファの内容が下のエントリーのバッファに追加される。ステップ７２６で長さ制御スタックよりトップエントリーをポップする。ステップ７２８で、長さ制御スタックのトップにあるエレメントネームが終了タグであるか判定する。終了タグであるならば、フローはステップ７１０へ戻って当該終了タグのための処理を繰り返す。終了タグでなければ、フローはステップ７３０へ進み、Ｃurrent−Ｔagは長さ制御スタックのトップにあるエレメントネームと同じに設定される。そして、フローは呼び出したプロセスに戻る。
【００７９】
図２７は”タグプロセッサ”により実行されるプロセスを説明するフローチャートを含んでいる。このプロセスは図２０のステップ５１４により呼び出される。このプロセスは、コメントタグ及びトークンシーケンスタグ以外の全てのタグの処理のために用いられる。ステップ７５０で、処理されるクリアテキストタグが！ＤＯＣＴＹＰＥであるか調べる。！ＤＯＣＴＹＰＥであるときには、図２８に示された”！ＤＯＣＴＹＰＥプロセッサ”がステップ７５２により呼び出される。ステップ７５６でＳＰＤＬ開始コマンドがあるか判定する。あるならば、図２９に示される”ＳＰＤＬ開始ルーチン”がステップ７５８により呼び出される。ステップ７６２でＳＰＤＬ終了タグがあるか判定する。あるならば、フローはステップ７６４へ進み図３０に示される”ＳＰＤＬ終了ルーチン”を呼び出す。つぎにステップ７６８で、処理されるエレメントが終了タグであるか判定する。終了タグならば、フローはステップ７７４へ進み、その終了タグネームが長さ制御スタックのトップにあるエレメントネームであるか判定する。そうでないときには、スタックのトップのエレメントはたった今終了したエレメントに対応しなければならないのであるから、ステップ７７６でエラーメッセージが表示されプロセスは終了する。終了タグがスタックのトップにあるならば、フローはステップ７７８へ進み、図２６に示される”終了タグルーチン”を呼び出す。
【００８０】
タグが終了タグでないとステップ７６８で判定したときには、ステップ７７０で図３１に示される”開始タグルーチン”を呼び出す。これらルーチンのどれかが図２７で呼び出された後、フローは図２７に戻り、続いてステップ７５４，７６０，７７２又は７８０によって呼び出したプロセスへ戻される。
【００８１】
図２８は、図２７のステップ７５２から呼び出される”！ＤＯＣＴＹＰＥプロセッサ”によって実行されるプロセスのフローチャートを示す。図２８において、ステップ７８２でクリアテキスト！ＤＯＣＴＹＰＥエレメントの次のストリングを、スペースのようなセパレータを無視して取得する。ステップ７８４で、当該ストリングを大文字に変換した後、それが”ＳＰＤＬ”であるか調べる。”ＳＰＤＬ”でないときには、ＳＰＤＬの後に”！ＤＯＣＴＹＰＥ”エレメントが続かなければならないので、エラーがある。”ＳＰＤＬ”であるときには、ステップ７８８で入力ファイルのポインタを当該”！ＤＯＣＴＹＰＥ”の次を指すように設定する。次に、ステップ７９０で、カレント（current）エレメント＝！ＤＯＣＴＹＰＥタグに設定する。なお、最初のエレメントが！ＤＯＣＴＹＰＥである場合には長さ制御ルーチンは呼び出されない。
【００８２】
図２９は、図２７のステップ７５８により呼び出される”ＳＰＤＬ開始ルーチン”を示す。このルーチンはＳＰＤＬ開始タグを処理する。まず、ステップ８０２で、ＳＰＤＬエレメントに対する１つのエントリーをスタックに生成するため、図２３に示される”長さ制御スタックセットアップルーチン”を呼び出す。次に、ステップ８０４で、長さ制御スタックのトップエレメントのＡＳＮ．１タグとして２８Ｈを書き込む。これは外部エレメントであるＡＳＮ．１タグ ＵＮＩＶＥＲＳＡＬ ８ に対応する。これはＳＰＤＬのために必要なタグである。次に、長さ制御スタックのトップエントリーのバッファに７エレメントが書き込まれようとしているので、スタックのトップエレメントのバッファカウントエントリーは７に設定される。次にステップ８０８は、１６進表現の ０６ ０５ ２８ ＣＦ （これはテキスト表現の”Ｏbject Ｉdentifier ＩＳＯ／ＩＥＣ （１） ＳＴＡＮＤＡＲＤ （０）１０１８０ ０”に相当する）を、長さ制御スタックのトップエントリーのバッファに書き込む。最後にステップ８１０でフローは図２７へ戻る。
【００８３】
図３０は、図２７のステップ７６４により呼び出される”ＳＰＤＬ終了ルーチン”により実行されるプロセスのフローチャートを示す。図３０において、ステップ８２２で、長さ制御スタックのトップにあるエレメントネームが”ＳＰＤＬ”であるか判定する。”ＳＰＤＬ”でないときには、スタックのトップにあるエレメントは終了エレメントでなければならないのであるから、エラーがある。したがって、ステップ８２４でエラーメッセージが表示される。”ＳＰＤＬ”であるときには、ステップ８２６で、このＳＰＤＬエレメントのＡＳＮ．１タグ（＝２８Ｈ）が出力ファイルに書き込まれる。この出力ファイルは、バイナリフォーマットに変換された最終文書を格納する。次にステップ８２８で、ＡＳＮ．１のベーシックエンコーディング規則（Ｂasic Ｅncoding Ｒules）に従って、長さ制御スタックのトップエントリーのバッファカウントを長さ値（length value）に変換し、この情報を出力ファイルに書く。最後に、ステップ８３０で、長さ制御スタックのトップエントリーより指されたバッファの情報が出力バッファに書かれる。したがって、ファイルの全情報が変換され所望の出力ファイルへ書き込まれたので、ステップ８３２で当該プロセスは終了となる。
【００８４】
図３１乃至図３３は”開始タグルーチン”を示す。このルーチンは！ＤＯＣＴＹＰＥ、ＳＰＤＬ、コメント、トークンシーケンス以外の一般的なクリアテキストタグが変換される時に必ず実行される。図３１において、ステップ９５４で新たに処理しようとするエレメントが、処理されたばかりのエレメントのサブエレメント連結リスト中に見つかるか判定する。見つからない時には、この新しいエレメントは前エレメントの適切なサブエレメントではないので、ステップ９５６でエラーメッセージが出される。該エレメントが適切なエレメントであるときには、フローはステップ９５８へ進み、該クリアテキストタグが”ＳＴＲＣＴＩＤ”であるか判定する。そうであるならば、ステップ９６０で図３４に示される”ＳＴＲＣＴＩＤプロセッサ”が呼び出される。”ＳＴＲＣＴＩＤ”でないときには、フローはステップ９５８からステップ９６４へ進み、図２３に示される”長さ制御スタックセットアップルーチン”を呼び出す。
【００８５】
次に、ステップ９６６は処理されているエレメントがアトリビュートを持っているか判定する。持っているならば、フローは図３２に示されるプロセスＡへ進む。アトリビュートがないときには、フローはステップ９６８へ進み、エレメント宣言が空であるか判定する。空エレメント宣言は、開始タグと終了タグとの間にデータがない時に出現する。この場合、その終了タグは省かれなければならない。
【００８６】
エレメント宣言が空であるときには、フローはステップ９７０へ進み、終了タグパラメータ＝開始タグとして、図２６に示される”終了タグルーチン”を呼び出す。エレメントタグが空でないときには、ステップ９７４で、エレメントのための何等かのデータ（すなわち、エレメントの開始タグに続くデータ）があるか判定する。データがなければ、ステップ９７６でフローは呼び出したプロセスへ戻る。
【００８７】
ステップ９７８で、データをバイナリフォーマットへエンコードする必要があるか判定する。必要があれば、フローはステップ９８０へ進み、データをバイナリへ変換する。バイナリへエンコードする必要が常にあるかも知れない。しかし、ある種のデータがエンコード／変換される必要がない場合やＳＰＤＬ規格が変わる場合に備えて、ステップ９７８が入れられている。
【００８８】
次にステップ９８２で、データを長さ制御スタックのトップのバッファへ入れる。ステップ９８４で、長さ制御スタックのトップエントリーのバッファ中のバイト数をカウントし、該バイト数を長さ制御スタックのバッファカウントに書き込む。そして、ステップ９８６でフローは呼び出したプロセスに戻る。
【００８９】
図３２は、アトリビュートがあると判定される時に図３１により呼び出されるプロセスＡを示す。図３２おいて、ステップ１０００はアトリビュートネームとアトリビュート値を取得する。ステップ１００２は、そのアトリビュートネームが、エレメントテーブルの現在エレメント位置により指される連結リスト中にあるか判定する。存在しないときには、アトリビュートは適切なサブエレメントではないので、ステップ１００４はプロセスを終わらせてエラーメッセージを表示する。
【００９０】
次にステップ１００６で、アトリビュートネームが”notation”であるか判定する。そうならば、図２３に示される長さ制御スタックセットアップルーチンが呼び出され、フローは図３３に示されるプロセスＣへ進む。アトリビュートネームが”notation”であるときには、このアトリビュートは開始タグと終了タグの間のデータタイプを指定する。例えば、オブジェクトアイデンティファイア（Ｏbject Ｉdentifier）が”ｎ１．ｎ２．ｎ３．．．．”とエンコードされたとき（ｎ１，ｎ２，ｎ３．．．はクリアテキストエンコーディングでは１０進表現である）、バイナリエンコーディング（ＢＥＲ）は別のエンコーディングスキームを用いる。したがって、ｎ１．ｎ２．ｎ３．．．はバイナリフォーマットへ変換されなければならない。
【００９１】
アトリビュートネームが”notation”でないときには、フローはステップ１０１０へ進み、図１０に示したような一時的アトリビュートバッファデータ構造からなる一時的アトリビュートバッファ連結リストの最後に、一つの一時的アトリビュートバッファデータ構造を挿入する。次にステップ１０１２で、アトリビュート値をクリアテキストからバイナリへ変換する必要があるか判定する。例えば、クリアテキストのアトリビュートがＣＯＮＴＲＥＰで、その値が”ＩＳＯ／ＩＥＣ”であると、この値は ０６ ０６ ２８ ＣＦ ４４ ００ ０２ ００ と変換される。これは１バイトずつの変換ではなく、アトリビュート全体が調べられ、バイナリの等価な値へ変換されるもので、各テキスト文字を個別に変換するものではない。
【００９２】
アトリビュート値を変換する必要があるときには、ステップ１０１４でアトリビュート値をバイナリへ変換する。次にステップ１０１６で、アトリビュート値及びアトリビュートネームを、新しく生成された一時的アトリビュートバッファデータ構造（ステップ１０１０により生成された）に格納する。次にステップ１０１８で、ほかに処理すべきアトリビュートがあるか判定する。あるときには、フローは図３２の上部に示されるプロセスＡへ進む。そうでなければ、図３５に示される”アトリビュート終了ルーチン”がステップ１０２０で呼び出され、そしてフローは図３１に示されるプロセスＢへ戻る。
【００９３】
図３３において、ステップ１０３０では、処理されているエレメントの開始タグと終了タグの間のデータを取得し、入力情報のポインタを、該終了タグの後のエレメントを指すように設定する。ステップ１０３２でアトリビュート値が”ＯＢＪＩＤ”であるか判定する。そうであるならば、フローはステップ１０３４へ進み、長さ制御スタックのトップにある値を０６Ｈ（これはＡＳＮ．１オブジェクトアイデンティファィアである）に設定する。つぎに、ステップ１０３６で、ステップ１０３０において得られたデータを、バイナリエンコーディングに変換し、フローは図３３に示されるプロセスＤへ進む。ステップ１０３８で、アトリビュート値が”ＥＮＶＮＭ”であるか判定する。そうならば、フローはステップ１０４０へ進み、長さ制御スタックのトップにあるタグ値を４３Ｈ（これはＡＳＮ．１アプリケーション３である）に設定する。そして、フローはプロセスＤへ進む。
【００９４】
ステップ１０４２で、アトリビュート値が”ＰＵＢＩＤ”であるか判定する。そうでなければ、値”ＰＵＢＩＤ”が期待されるとのエラーのメッセージであるから、ステップ１０４４でエラーを表示する。ステップ１０４６において、パブリックアイデンティファイア（public identifier）が対応するオブジェクトアイデンティファィアを持つか判定される。持っていれば、フローはステップ１０３４へ進む。持っていなければ、ステップ１０４８で長さ制御スタックのトップにあるタグ値をＡＳＮ．１アプリケーション１（これはバイナリで４２Ｈと表わされる）に設定する。
【００９５】
次にステップ１０５０で、ステップ１０３０において得られたデータを、長さ制御スタックのトップエントリーのバッファにコピーする。ステップ１０５２で、バッファバイトサイズをカウントし、このカウント値を長さ制御スタックのトップエントリーのバッファカウントエントリーに入れる。次にステップ１０５４で、図２６の”終了タグルーチン”を適当な終了タグに関して２度呼び出す。このルーチンが２度呼び出されるのは、長さ制御スタックルーチンが２回呼び出される（図３１のステップ９６４と図３２のステップ１００８）ことに対応するためである。そして、ステップ１０５６で、フローは呼び出したプロセスへ戻る。
【００９６】
図３４は、図３１のステップ９６０で呼び出される”ＳＴＲＣＴＩＤプロセッサ”を示す。図示のプロセスは、クリアテキストタグ”ＳＴＲＣＴＩＤ”を処理するために用いられる。ＳＴＲＣＴＩＤエレメントに対するバイナリ表現は、変換されるべきファイル中の前に出現するエレメントによって変わることがあるので、ＳＴＲＣＴＩＤエレメントのための特殊なルーチンがある。例えば、図１６はＰＩＣＴＢＤＹエレメントのためのサブエレメント連結リストデータ構造を示している。図１６において、データ構造３７０及びデータ構造３８４は共にＳＴＲＣＴＩＤサブエレメントのためのものである。図３４に示したフローチャートは、図１６に示したＳＴＲＣＴＩＤエレメントのどれが処理中に用いられるか判断するために利用される。
【００９７】
図３４において、ステップ１０８０で変換中のエレメントからＳＴＲＣＴＩＤデータを取得する。ステップ１０８０で取得されるＳＴＲＣＴＩＤデータの例は、ピクチャー、ページセット、トークンシーケンス、Ｐictbdy、プロローグである。ＳＴＲＣＴＩＤデータは、どのタイプの情報が外部リソース中に含まれているかを示す。この情報は、図１６のＳＴＲＣＴＩＤに対しどのＡＳＮ．１タグが用いられるかの判断を助けるために利用される。
【００９８】
次に、ステップ１０８２で、ピクチャー／ページセットスタックのトップエントリーにより指示されたデータ構造の外部宣言ポインタにより指された連結リスト中のＳＴＲＣＴＩＤを探す（図９参照）。図９に示したデータ構造は、変換すべき文書の実際の処理（変換プロセスではない）の間に生成される。図９に示したデータ構造の生成及び処理は、特許査定された米国特許出願第０７／８７６，２５１号（１９９２年４月３０日受理、”Ｍethod and Ｓystem to Ｈandle Ｉnclusion of Ｅxternal Ｆiles Ｉnto a Ｄocument Ｐrocessing Ｌanguage”に詳細に述べられている。
【００９９】
次にステップ１０８４で、図９に示した構造ＩＤ連結リストデータ構造のいずれかの中の構造ＩＤが、変換されるべきＳＴＲＣＴＩＤクリアテキストエレメントに対応するか判定する。対応しないときは、エラーがあるので、ステップ１０８６でプロセスを終了させる。対応するときには、ステップ１０８８で該エレメントの構造タイプを対応する構造ＩＤ連結リストデータ構造から取得する。構造タイプが得られると、ステップ１０９０でカレント（current）エレメントのサブエレメント連結リストをトレースし、ＳＴＲＣＴＩＤ連結リストデータ構造中に見つかった構造タイプを見つける。例えば、図９に示した連結リスト中の構造タイプがピクチャーであると判定された場合、該ピクチャーに対応するＳＴＲＣＴＩＤを見つけるべくサブエレメント連結リストリストがトレースされる。
【０１００】
構造タイプがサブエレメント連結リスト中に見つからないときには、フローはステップ１０９２からステップ１０９４へ進みプロセスを終了させる。構造タイプが見つかったときには、ステップ１０９６でサブエレメント連結リストのトレースを、ＳＴＲＣＴＩＤが見つかるまで続ける。したがって、ステップ１０９０では構造エレメントを確定し、そしてステップ１０９６で該構造エレメントの後の最初のＳＴＲＣＴＩＤを求める。
【０１０１】
次にステップ１０９８で、図２３に示したステップ６０６からの”長さ制御スタックセットアップルーチン”を呼び出す。次にステップ１１００で、フローは呼び出したプロセスへ戻る。
【０１０２】
図３５は”アトリビュート終了ルーチン”を示す。このルーチンは、図３１及び図３２に示したプロセスで始まったアトリビュートの変換処理を終了させるために用いられる。図３５において、ステップ１１２０で一時的アトリビュートバッファ連結リストがカレント（current）エレメントのためのサブエレメント連結リストのアトリビュートと同じ順序であるか判定する。同じ順序でないときには、ステップ１１２２で一時的アトリビュートバッファ連結リストを、サブエレメント連結リストのアトリビュートと同じ順序を持つように並べ替える。同じ順序のときには、順序を並べ替える必要がないので、フローはステップ１１２０から直ちにステップ１１２４へ進み、一時的アトリビュートバッファデータ構造中のアトリビュート全部が処理されたか判定する。ステップ１１２４が初めて呼び出される時には、アトリビュートの全部は処理されていないので、フローはステップ１１２８へ進み一時的アトリビュートバッファ連結リストデータ構造中の最初のアトリビュートのアトリビュートネームを取得する。ステップ１１３０で、図２３に示された”長さ制御スタックセットアップルーチン”を呼び出す。ステップ１１３２で、バイナリのアトリビュート値を長さ制御スタックのトップエントリーのバッファに入れる。ステップ１１３４で、バッファのバイトサイズをカウントし、そのサイズを長さ制御スタックのトップエントリーのバッファカウントに書き込む。ステップ１１３６は図２６に示された”終了タグルーチン”を呼び出し、フローはステップ１１２４へループバックする。アトリビュート全部が処理されると、フローは呼び出したプロセスへ戻る。そうでなければ、ステップ１１２８〜１１３６が繰り返される。
【０１０３】
図３６は、本発明のプロセスを実行するために利用できるワークステーション１２００の構成を示す。ワークステーション１２００はＣＰＵ１２０２、ＲＡＭ１２０４、ＲＯＭ１２０６、キーボード１２１０及びマウス１２１４と接続された入力コントローラ１２０８を含む。印刷エンジンインターフェイス１２１６が印刷エンジン１２１８に接続され、印刷エンジン１２１８は該インターフェイス１２１６によって伝送される画像データのビデオ制御信号を受信する。ワークステーション１２００はさらに、ハードディスク１２２４及びフロッピーディスク１２２６と接続されたデスクコントローラ１２２２、ネットワーク１２３０（例えばＥthernet（登録商標）ネットワーク）に接続するための通信コントローラ１２２８、Ｉ／Ｏコントローラ１２３２を含む。Ｉ／Ｏコントローラ１２３２は、例えばＳＣＳＩバスにより外部のハードディスク１２３６と接続され、例えばＲＳ−２３２ケーブルによってプリンタ１２３４と接続される。ワークステーション１２００は、ＣＲＴ１２４０と接続されるディスプレイコントローラ１２３８も含む。システムバス１２２０はワークステーション内部の各要素を接続する。
【０１０４】
本発明のプロセスは、図３６に示した記憶装置中のどれに格納してもよい。さらに、本発明のプロセスの実行中に、生成されるデータ及び処理に利用されるデータは図３６に示した記憶装置中のどれに格納してもよい。ＣＰＵ１２０２は本発明のプロセスの実行をするために利用できる。
【０１０５】
図３７は、本発明の変換プロセスの実行例に用いられる典型的なＳＰＤＬ文書を示す。行１は！ＤＯＣＴＹＰＥエレメントを含んでいる。行２はＳＰＤＬエレメントを含んでいる。行３はアトリビュート”コンテント表現”を持つピクチャーエレメントを含んでいる。行４はＰＩＣＴＢＤＹエレメントを含んでおり、行５はそのプロローグを含んでいる。図３７に示した文書のこれ以上の説明は、これらエレメントがよく知られたＳＰＤＬエレメントであり説明は必要でないので、簡略化のため省略する。
【０１０６】
図３８乃至図６１は、図３７に示した文書例の処理時の長さ制御スタックを示す。図３８において、図３７の行２にあるＳＰＤＬ開始タグが図２９に示したフローチャートに従って処理される。図３９において、ピクチャー開始エレメントが処理され、スタックは図示のようになる。なお、図３８乃至図６１において、３つのハイフン（−−−）は何等かのバイトシーケンスを指す。ハイフンを含む正確なバイトシーケンスは、添付図面に含まれかつ明細書中で述べられたフローチャートを使って決定できるが、簡単にするため省略されている。図３９において、３つのハイフンは図３８のポインタにより指されたものと同じシーケンスの可能性がある。図４０乃至図４５は、図３７の文書例の処理がさらに進んだ時点のスタックを示す。図４６、及び文書例の処理中のスタックを示す他の図において、ｘ，ｙ，ｘｙ，ｙｙ等々の変数はバイト値を表わす。正確なバイト値は、フローチャートを追跡し図３７に示した各種パラメータの値を求めることによって決定できる。図４６において、Ｃurrent−ＴagはＰＲＯＬＯＧＵＥエレメントである。図５０は、外部宣言データ構造へのポインタを持つピクチャー／ページセットスタックデータ構造の例と、その外部宣言データ構造を示す。図５０において、１３０２はピクチャー／ページセットスタックを表わし、１３０４は外部宣言データ構造へのポインタを持つデータ構造を表わし、１３０６は外部宣言データ構造を表わす。ファイルがクリアテキストからバイナリへ変換中であるとしても、図５０に示すデータ構造は、単に１対１変換の実行ではなく、変換される文書の一部を実際に処理するためには必要である。これは構造タイプ（図５０において、１３０６は構造ＩＤ ＭＹＰＩＣＴのピクチャーである）を確認する必要があるからである。図５０は本発明の処理に用いられるデータ構造の一例に過ぎないもので、当然、図示されない他のものが用いられてもよいが、簡略にするため省略されている。
【０１０７】
図５１において、Ｃurrent−ＴagはＰＲＯＬＯＧＵＥである。図５２においては、Ｔag−Ｒead−ＩnはＳＴＵＰＰＲＣであり、Ｃurrent−ＴagはＳＴＵＰＰＲＣであり、Ｐrevious−ＴagはＰＲＯＬＯＧＵＥである。図５７において、Ｃurrent−ＴagはＰＩＣＴＢＤＹである。図５８において、Ｔag−Ｒead−ＩnはＳＴＲＣＴＩＤであり、外部宣言データのデータはＭＹＰＩＣＴ（不図示）である。これは次のＳＴＲＣＴＩＤを取り出すために利用される。Ｃurrent−ＴagはＳＴＲＣＴＩＤであり、Ｐrevious−ＴagはＰＩＣＴＢＤＹである。処理は図５９乃至図６１に示すデータ構造を利用して続く。
【０１０８】
【発明の効果】
以上の説明から理解されるように、本発明によれば、クリアテキスト・エンコーディングからバイナリ・エンコーディングへの変換における課題を解決し、クリアテキスト・エンコーディング文書からバイナリ・エンコーディング文書への変換、より特定的に言えば、クリアテキスト・エンコーディングＳＰＤＬ文書からバイナリ・エンコーディングＳＰＤＬ文書への変換を実行するための効果的な方法を実現することができる。
【図面の簡単な説明】
【図１】 バイナリ・エンコーディングに対する固定長フォーマット及び不定長フォーマットのネスティングの一例を示す図である。
【図２】 ＩＳＯ／ＩＥＣ ８８２５ によるエンコーディングの構造を示す図である。
【図３】 ＩＳＯ／ＩＥＣ ８８２５ によるアイデンティファイア・オクテットの構造を示す図である。
【図４】 ＳＰＤＬエレメント状態遷移ダイヤグラムの部分図である。
【図５】 バイナリエンコードＳＰＤＬ文書の見本の１６進表現を示す図である。
【図６】 図５に示したバイナリ文書のクリアテキスト表現を示す図である。
【図７】 図５に示したバイナリエレメントと図６に示したクリアテキストエレメントとの間の対応を示す図である。
【図８】 クリアテキスト文書をバイナリ文書へ変換するために利用される要素の概念図である。
【図９】 ＳＴＲＣＴＩＤエレメントのバイナリ表現のためにどのバイナリ表現を用いるかを決定するため、ＳＰＤＬ構造プロセッサがＳＴＲＣＴＩＤエレメントの処理に利用するデータ構造を示す図である。
【図１０】 バイナリ変換された文書中のアトリビュートの順序が適切であることを保証するために利用される一時的アトリビュートバッファデータ構造を示す図である。
【図１１】 各クリアテキストタグのための各種パラメータの格納に利用されるエレメントテーブルを示す図である。
【図１２】 サブエレメント連結リストデータ構造のフィールドを示す図である。
【図１３】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１４】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１５】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１６】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１７】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１８】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１９】 文書の各階層レベルの変換を管理するために利用される長さ制御スタックを示す図である。
【図２０】 変換プロセスのために用いられるフローチャートを示す図である。
【図２１】 コメントプロセッサに用いられるプロセスを示す図である。
【図２２】 トークンシーケンスプロセッサに用いられるプロセスのフローチャートを示す図である。
【図２３】 長さ制御スタックを初期化するために用いられる長さ制御スタックセットアップルーチンを示す図である。
【図２４】 長さ制御スタックを初期化するために用いられる長さ制御スタックセットアップルーチンを示す図である。
【図２５】 長さ制御スタックを初期化するために用いられる長さ制御スタックセットアップルーチンを示す図である。
【図２６】 終了タグルーチンのフローチャートを示す図である。
【図２７】 タグプロセッサにより利用されるフローチャートを示す図である。
【図２８】 ＤＯＣＴＹＰＥプロセッサにより利用されるフローチャートを示す図である。
【図２９】 ＳＰＤＬ開始ルーチンのフローチャートを示す図である。
【図３０】 ＳＰＤＬ終了ルーチンのフローチャートを示す図である。
【図３１】 開始タグルーチンのフローチャートを示す図である。
【図３２】 開始タグルーチンのフローチャートを示す図である。
【図３３】 開始タグルーチンのフローチャートを示す図である。
【図３４】 ＳＴＲＣＴＩＤプロセッサのフローチャートを示す図である。
【図３５】 アトリビュート終了ルーチンのプロセスを示す図である。
【図３６】 本発明の典型的なハードウエア構成を示す図である。
【図３７】 バイナリへ変換可能な典型的なクリアテキストＳＰＤＬ文書を示す図である。
【図３８】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図３９】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４０】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４１】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４２】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４３】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４４】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４５】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４６】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４７】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４８】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４９】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５０】 外部宣言データ構造へのポインタを持つピクチャー／ページセットスタックデータ構造の例と、その外部宣言データ構造を示す図である。
【図５１】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５２】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５３】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５４】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５５】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５６】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５７】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５８】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５９】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図６０】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図６１】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【符号の説明】
２０２ ＳＰＤＬクリアテキストデータ
２０４ パーサー
２０６ クリアテキスト−バイナリトランスレータ
２０８ ＳＰＤＬ構造プロセッサ
２１０ バイナリデータ
２２０ ピクチャー／ページセットスタック
２３４，２２６，２４２，２５０ 連結リストデータ構造
２７０ 一時的アトリビュートバッファデータ構造
２８０ エレメントテーブル
２８２ サブエレメント連結リストデータ構造
２８９ 追加ＡＳＮ．１タグ
３１０ サブエレメント連結リストデータ構造
320，330 サブエレメント連結リストデータ構造
340，350 サブエレメント連結リストデータ構造
360，370，380，382，384 サブエレメント連結リストデータ構造
368，378，381，383，385 追加ＡＳＮ．１タグ
386，388，390，392，394，396 サブエレメント連結リストデータ構造
387，389，391，393，394，396 追加ＡＳＮ．１タグ
398，400，402，404，406，408 サブエレメント連結リストデータ構造
399，401，403，405，407，409 追加ＡＳＮ．１タグ
４２０ 長さ制御スタック
４２２ バッファ
１２００ ワークステーション
１２０２ ＣＰＵ
１２０４ ＲＡＭ
１２０６ ＲＯＭ
１２０８ 入力インターフェイス
１２１０ キーボード
１２１４ マウス
１２１６ 印刷エンジンインターフェイス
１２１８ 印刷エンジン
１２２０ システムバス
１２２２ ディスクコントローラ
１２２４ ハードディスク
１２２６ フロッピードライブ
１２２８ 通信インターフェイス
１２３０ ネットワーク
１２３２ Ｉ／Ｏコントローラ
１２３４ プリンタ
１２３６ ハードディスク
１２３８ ディスプレイコントローラ
１２４０ ＣＲＴ
【産業上の利用分野】
本発明は文書のフォーマット変換の方法に係り、より具体的には、テキストエンコード文書（textual encoded document）をバイナリエンコード文書（binary encoded document）へ変換する方法に関する。特に本発明は、クリアテキストエンコードの標準ページ記述言語文書（clear text encoded Standard Page Description Language document）からバイナリエンコードの標準ページ記述言語文書への変換に関する。本発明は、文書をサイズを縮小したフォーマットへ変換することよりデータ圧縮機能をも達成するものである。
【０００２】
【従来の技術】
１つの標準化ページ記述言語が提案され、国際標準化機構（ＩＳＯ）で国際規格として開発中である。この提案は、本願発明者の一人もその関与者であるが、現在、ＩＳＯの１セクションに草案として提出されている。この草案は、ＩＳＯ／ＩＥＣ ＤＩＳ １０１８０ ”ＩＮＦＯＲＭＡＴＩＯＮ ＰＲＯＣＥＳＳＩＮＧ−ＴＥＸＴ ＣＯＭＭＵＭＩＣＡＴＩＯＮ−ＳＴＡＮＤＡＲＤ ＰＡＧＥ ＤＥＳＣＲＩＰＴＩＯＮ ＬＡＮＧＵＡＧＥ”として知られており、ニューヨークの米国規格協会（”ＡＮＳＩ”）で入手可能である。
【０００３】
標準ページ記述言語（”ＳＰＤＬ”）は階層的に構造化されたページ記述言語である。この構造化された階層によれば、文書の一部分の印刷をする場合に、当該部分に影響する可能性のあるフォーマット用コマンドを文書全体にわたっては調べる必要がなくなる。所望の部分を印刷するのに、その印刷したい部分より階層が上の文書の部分だけを処理すれば足りる。
【０００４】
ＳＰＤＬのもう１つの利点は、ＳＰＤＬがＩＳＯ ８８７９：１９８６ に定義された標準一般化マークアップ言語（Standard Generalized Markup Language，”ＳＧＭＬ”）に準拠していることである。このことにより、文書構造を包括的に記述し結び付けることが可能になる。複数のファイルは、ＳＧＭＬで結びつけられたならば、変換ユーティリティを用いる事なく、かつ構造フォーマットを損なうことなく、あるプラットフォームから他のプラットフォームへ切れ目なく移動できる。
【０００５】
ＳＰＤＬは、ＡＳＮ．１に述べられているベーシック・エンコーディング規則（Basic Encoding Rules）に準拠している。ＡＳＮ．１に関する完全な解説は、Douglas Steedman著”ＡＳＮ．１，The Tutorial and Reference”（１９９０年）に詳しい。
【０００６】
クリアテキスト（clear text）言語は、人間が読むことのできるコンピュータ言語の一種である。ノンクリアテキスト（non−clear text）言語の一例をあげるならば、文書のバイナリ・エンコーディング（binary encoding）であろう。２進もしくは１６進表現の文書を見ても、人間には文書内容を容易には理解できないからである。バイナリ・エンコード文書の１つの主要な利点として、２進表現の文書は同等のクリアテキスト形式の文書に比べて必要とする記憶スペースが非常に少ない事がある。このことがバイナリ文書の記憶スペースの減少及び伝送時間の高速化を可能にする。しかしクリアテキスト・エンコードの文書に比べ、特殊なソフトウエアを用いないとバイナリ・エンコードの文書を編集すること、理解することが困難である。
【０００７】
したがって、前述のように文書のクリアテキスト・エンコーディングにもバイナリ・エンコーディングにも長所と短所があるので、文書を一方のフォーマットから他方のフォーマットへ変換したいことがあろう。
【０００８】
【発明が解決しようとする課題】
本発明の目的は、クリアテキスト・エンコードの文書をバイナリ・エンコードの文書へ変換する方法を提供することである。詳しくは、クリアテキスト・エンコードの標準ページ記述言語文書を等価なバイナリ・エンコードの標準ページ記述言語文書へ変換する方法を提供することである。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、本発明によるフォーマット変換方法の骨子は、ＣＰＵが、ＳＰＤＬクリアテキストデータを入力するステップ；入力されたＳＰＤＬクリアテキストデータのエレメントのタグが開始タグである場合は、そのタグのバイナリエンコードの記述に追加の部分が存在するか否かを判定するステップ；追加の部分が存在すると判定された場合に、スタックのトップエントリーに記憶されているバイナリエンコードの記述が追加の部分であるか否かを判定するステップ；スタックのトップエントリーに記憶されているバイナリエンコードの記述が追加の部分であると判定された場合に、その追加の部分が、入力されたエレメントのタグにおける追加の部分と同じであるか否か判定するステップ；同じでないと判定された場合に、スタックのトップエントリーに記憶されているタグのバイナリエンコードの記述に基づいて、バイナリデータを作成してトップエントリーをポップし、次に、入力されたエレメントのタグについて、追加の部分を入れたエントリーをスタックに追加し、さらにバイナリエンコードの記述で常に出現する必要がある部分を入れたエントリーをスタックに追加するステップ；同じであると判定された場合に、入力されたタグに対するバイナリエンコードの記述で常に出現する必要がある部分を入れたエントリーのみをスタックに追加するステップ；入力されたＳＰＤＬクリアテキストデータのエレメントのタグが終了タグである場合は、スタックのトップエントリーに記憶されているタグのバイナリエンコードの記述に基づいて、バイナリデータを作成してトップエントリーをポップするステップ；を実行するものである。
【００１０】
本発明による上記目的を達成するための手段の理解をより容易にするため、後記実施例との関連を考慮して少しく具体的にさらに説明する。
【００１１】
バイナリＳＰＤＬ文書に要求されるフォーマットのゆえに、及び、クリアテキスト表現とバイナリ表現との間に１対１の対応関係がないため、発明者はクリアテキスト・エンコード文書をバイナリ・エンコード文書に変換するために単純なルックアップ（look−up）プロシージャを行なうことは不可能であると判断した。様々なバイナリシンボル（binary symbol）の表わす内容は、ＳＰＤＬ文書中におけるバイナリシンボルのロケーションに依存する。
【００１２】
本発明が扱わなければならないもう１つの課題は、バイナリエンコードされたプロセスそれぞれの長さを管理することである。ＳＰＤＬは階層的に構造化されたページ記述言語であり、バイナリ・エンコーディングの各階層レベルの始まり部分は、該レベルが固定長フォーマットまたは不定長フォーマットのいずれでエンコードされているかを示し、かつ、固定長バイナリ・エンコーディングが存在する時にはエンコーディングの長さを示す。本発明が扱うもう一つの課題は、クリアテキスト・エンコーディングにおける特定のエレメントの順序がバイナリ・エンコーディングでは変更されなければならないという事である。したがって、クリアテキストＳＰＤＬフォーマットにおいて要求されるエンコーディング順序を知る必要がある。また、特定のクリアテキストエレメントは、該エレメントのテキスト表現の前に現われるエレメントによって、異なったバイナリ表現をとることがある。
【００１３】
本発明は、クリアテキストからバイナリへの変換を遂行するが、その遂行のために長さ制御スタック（length control stack）を使用してエレメントをその変換中に管理する。この長さ制御スタックによって、各階層レベルの長さがそのレベルの完了まで分からなくとも、クリアテキストからバイナリへの変換を実行できる。
【００１４】
クリアテキストタグ（tag）は、エレメントテーブル（element table）に格納される。このエレメントテーブルは、エレメントの下に出現可能なサブエレメントに関する情報を管理するために用いられるサブエレメント連結リスト（sub−elemtnt linked list）データ構造を指示するポインタを持っている。このサブエレメント連結リストデータ構造は、その第１エントリーとして、１個以上のＡＳＮ．１タグを記憶するＡＳＮ．１ ＴＡＧＳ エントリーを持っている。ＡＤＤＩＴＩＯＮＡＬ ＡＳＮ．１ ＴＡＧ フィールドはポインタを格納し、このポインタはヌル（null）を指すか、または、付加的なＡＳＮ．１タグが必要となきはそれを指す。
【００１５】
クリアテキスト・タグ ＳＴＲＣＴＩＤ を処理する場合、当該タグに対するバイナリ表現は該クリアテキストＳＴＲＣＴＩＤに関するパラメータによって異なる。ＳＴＲＣＴＩＤのどのバイナリ表現を用いるべきか決定するためには、クリアテキストＳＰＤＬ文書の一部を実際に処理する必要がある。このことは、その文書が単にあるフォーマットから他のフォーマットへ変換されるだけで、プレゼンテーション（presentation）装置によりプレゼンテーションするための処理が行なわれない場合でも、そうである。しかし、文書をプレゼンテーションするための処理は、変換プロセスの前でも後でも可能である。ＳＴＲＣＴＩＤエレメントを処理するため、各種階層レベルを管理するピクチャー／ページセット（picture／pageset）スタックが用いられる。ピクチャー／ページセットスタックの各エントリーは、少なくともページセットレベル及びピクチャーレベルを含む１つのデータ構造を指示する。また、このデータ構造内に、ＳＴＲＣＴＩＤ 連結リストデータ構造を指すポインタがある。このデータ構造は構造ＩＤを表示するエレメント、構造タイプ、及び次の構造ＩＤ連結リストデータ構造へのポインタを含む。
【００１６】
変換プロセス中に、クリアテキスト表現の各種ＳＰＤＬエレメントのアトリビュートの順序がバイナリ表現に要求される順序と違うことがある。したがって、エレメントそれぞれに対するアトリビュートを管理するため、一時的アトリビュートバッファ（temporary attribute buffer）データ構造が使用される。１つのエレメントの全アトリビュートが一時的アトリビュートバッファ連結リストに書き込まれた後、一時的アトリビュートバッファ連結リストは、アトリビュートを適切な順序、すなわち当該エレメントのサブエレメント連結リストデータ構造内での順序に対応した順序にするように、並べ替えられる。
【００１７】
【作用】
以上に述べたように、本発明のフォーマット変換方法によれば、クリアテキスト・エンコード文書（例えばＳＰＤＬ文書）を入力することにより、それと等価なバイナリ・エンコード文書（ＳＰＤＬ）を生成することが可能である。
【００１８】
【実施例】
以下、添付図面を参照し、本発明の実施例を説明する。なお、添付図面中の複数の図面にわたって、同一の参照数字は同一部または対応部を示すものである。
図１に、バイナリエンコード文書に対する固定長及び不定長フォーマットのネスティング（nesting）の一例が示されている。図１は、生成されるべき１つのデータストリームもしくは文書データストリームを表わすと考えることができる。行１〜行１６及び行１７〜行１９は最高階層レベルの２つのエンコーディングであるが、行１〜行１６内にはネストされたエンコーディングがある。行１〜行１６のエンコーディングのコンテント（content）は４００バイトの固定長である。これら４００バイト内において、まず行４〜行１３に１つの不定長構造がある。この行４〜行１３の不定長コンテント内に、２４８バイト及び４０バイトの固定長コーディングがある。行４〜行１３の４００バイトのコンテントからなる不定長エンコーディングに加えて、１００バイトのコンテントを含む行１４〜行１６の固定長エンコーディングがある。図１の行１７〜行１９には、２５０バイト長の固定長エンコーディングが含まれる。
【００１９】
”固定長フォーマットと不定長フォーマットのネスティング”なるタームは、ある不定長エンコーディングが、そのコンテントとして、１つの不定長エンコーディングと１つの固定長エンコーディング、あるいは、これら２つのエンコーディングの組合せを持つことができる、ということを意味する。このことは、その固定長エンコーディングが、その不定長エンコーディングが終わる前に始まることを意味する。上記タームは不定長エンコーディングを含む固定長エンコーディングにも同様に当てはまる。すなわち、不定長エンコーディングは固定長エンコーディングが終わる前に開始可能である。さらに、１つのエンコーディング内に、任意数の任意タイプのエンコーディングをネストできる。
【００２０】
図１から分かるように、バイナリエンコーディングの長さを、そのコンテントが現われる前にエンコードする必要がある。したがって、長さ計算が可能であるためには、その前にコンテントをクリアテキストからバイナリ表現へ変換しておく必要がある。しかし、不定長エンコーディングが図１の行４〜行１３のエンコーディングのような不定長エンコーディングの時には、その長さを知っている必要はない。行１３にあるエンコーディング”０００Ｈ”は不定長エンコーディングの長さを示す。
【００２１】
本発明のフローチャートは、固定長バイナリエンコーディングへの変換を示している。しかし、本発明は不定長エンコーディングをカバーすることをも意図しており、これは、不定長エンコーディングの初めに、知られている適当な不定長エンコーディングタグ（tag）を挿入し、かつ、その不定長エンコーディングの終わりに適当な終了情報（”０００Ｈ”）を挿入することにより、容易に達成される。
【００２２】
さて、ＡＳＮ．１に要求されるエンコーディングであるが、図２はＩＳＯ／ＩＥＣ８８２４に定義されたベーシック・エンコーディング規則に従ったバイナリエンコーディングの構造を示している。このエンコーディングは１個以上のアイデンティファイア・オクテット（identifier octet）で始まり、１個以上の長さオクテット（length octet）が続き、これにコンテント・オクテット（contents octet）が続く。
【００２３】
ＩＳＯ／ＩＥＣ ８８２４で定義されたアイデンティファイア・オクテットの構造が図３に示されている。このアイデンティファイア・オクテットの初めの２ビットはエンコーディングのクラス（class）を表わす。図３に示されたビット８及びビット７で定義される可能なエンコーディング・クラスはユニバーサル（universal）、アプリケーション（application）、コンテント・スペシフィック（content−specific）、及びプライベート（private）の４つである。ＡＳＮ．１のエンコーディングの完全な解説は、ＩＳＯ／ＩＥＣ ８８２４及びＩＳＯ／ＩＥＣ ８８２５（いずれも引用によって本明細書に組み込まれる）に見られる。しかし、本発明の作用を理解するのに、様々なクラスのエンコーディングに関する理解は必要としないので、これ以上の詳細説明は簡略化のため省略する。
【００２４】
図３に示したビット６は、エンコーディングがプリミティブ（primitive）であるか複合（constructed）であるかを決定する。プリミティブとは現エンコーディング内にネストされたエンコーディングが全然存在しないことを意味し、複合とは現エンコーディング内にほかのエンコーディングがネストされていることを意味する。図３に示されているビット５〜ビット１は、タグの番号に関するものである。タグの番号が３１を超えるときには、ビット５〜ビット１は同番号を表現するには足りないので、アイデンティフアイア・オクテットの最後の５ビットは１１１１１に設定され、後続のアイデンティファィア・オクテットで該タグの番号をエンコードする。様々なタグ番号の完全な理解は、本発明の作用を理解するために必要とされないので、簡略化のため省略する。
【００２５】
アイデンティファイア・オクテット及び長さオクテットはプリアンブル（preamble）情報と考えることができ、コンテント・オクテットはコンテント情報と考えることができる。
【００２６】
当業者にとっては、以上の説明でバイナリＳＰＤＬエンコーディングの基本を理解するのに十分であると考えられる。しかし、バイナリ・エンコーディングの処理に関するより詳細かつ完全な説明は、同時係属米国特許出願第０８／０６６，３８３号（”ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＰＲＯＣＥＳＳＩＮＧ ＭＩＸＥＤ ＢＩＮＡＲＹ ＬＥＮＧＴＨ ＥＮＣＯＤＩＮＧ ＣＯＮＴＡＩＮＩＮＧ ＤＥＦＩＮＩＴＥ ＡＮＤ ＩＮＤＥＦＩＮＩＴＥ ＬＥＮＧＴＨ ＦＯＲＭＡＴＳ”）に見ることができる。しかし、本出願の主要な関心事及び処理はファイルをクリアテキストからバイナリ表現へ変換することであるのに対し、上記関連出願に述べられている処理は主としてプリンタ、ＣＲＴ等による文書の出力（presentation）に関係するものである。
【００２７】
本発明は各種ＳＰＤＬエレメントの情報を管理するためにエレメントテーブル（element table）とサブエレメント連結リスト（sub−element linked list）データ構造を用いる。ＳＰＤＬは階層的に構造化されたページ記述言語であり、エレメントテーブル及びサブエレメント連結リストの情報を生成するためにＳＰＤＬの階層構造を確定する必要があった。
【００２８】
ＳＰＤＬの階層秩序を確定するため、発明者は、規格草案に含まれているＳＰＤＬエレメントの記述を用い、図４に示すようなＳＰＤＬエレメント状態遷移ダイヤグラムを作成した。図４は、ＳＰＤＬ構造エレメントの階層構造を、それに包含されているツリー構造を用いて説明し、また１つのエレメントから出て同じエレメントに戻るラベル付けしたアトリビュート用円弧矢印を示すことにより、各種ＳＰＤＬエレメントに対するアトリビュートを説明する。この状態遷移ダイヤグラムより、発明者は本発明に用いられるエレメント・テーブルとサブエレメント連結リストを生成することができた。
【００２９】
状態遷移ダイヤグラムの最初のエレメントはＳＰＤＬ１５２である。このＳＰＤＬエレメントの下に出現できる２つの可能なエレメントがある。文書エレメント１５４とリソース定義（resource definition）エレメント１５６である。このリソース定義エレメント１５６はリソース・アトリビュート、ＳＰＤＬ ＩＤアトリビュート及びファンクション（function）アトリビュートというアトリビュートを持つ如く示されている。アトリビュートは固定値を持つことも、ユーザによって入力された値を持つこともできる。
【００３０】
図４において、特定の階層構造における終端（terminal）エレメントつまり最も下のエレメントはアスタリスクが付けられており、また、前に定義済みのエレメントはプラス記号が付けられている。特定の階層構造の最低レベルには終端エレメントが存在できるが、他のエレメントは存在できない。
【００３１】
図４に示したＳＰＤＬエレメント状態遷移ダイヤグラムは完全なものではなく、簡略化のためにＳＰＤＬ構造エレメントの一部が省略されている。例えば、リソース・スペシフィケーション（specification）１６４、上位エレメントとして外部宣言（external declaration）を持つ構造ＩＤエレメント１９６、情報宣言１７４、リソース定義１７６、リソース宣言１７８、ＤＰＩ宣言１８０、コンテキスト（context）宣言１８２、セットアップ（set−up）プロシージャ１８６の下に来る構造エレメントがある。
【００３２】
文書構造エレメント１５４の下にページセット（pageset）エレメント１５８とピクチャー（picture）エレメント１６０がある。ページセット１５８の下にページセットボディ（ｂｏｄｙ）１６６とプロローグ（ｐｒｏｌｏｇｕｅ）１７２がある。図４に示されるように、ピクチャーエレメント１６０はページセットボディ１６６の下に出現することも可能である。ピクチャーエレメント１６０はコンテント表現のアトリビュート（前記関連出願においてコンテント・タイプと呼ばれたもの）とＳＰＤＬ ＩＤとを有する。ピクチャーエレメント１６０の下に出現可能なＳＰＤＬエレメントはプロローグ１７２とピクチャーボディ１６８である。トークン（token）シーケンス１７０は、ピクチャーボディ１６８の下に出現可能である。プロローグ１７２の下に出現する辞書ジェネレータ（dictionarygenerator）１８４の下に、サイズのアトリビュートを持つ辞書ジェネレータエレメント１８８が出現可能である。辞書１８８の下に出現可能なＳＰＤＬエレメントは、辞書ＩＤ１９０、ネーム（ｎａｍｅ）１９４及びトークンシーケンス１９２である。
【００３３】
なお、図４はＳＰＤＬに対する最近の変更を反映しておらず、また、ＳＴＲＣＴＩＤエレメントが出現可能な場所が２９ある。図４は背景情報として用意されたもので、当業者によれば、ＳＰＤＬに関する文献及び情報を利用し、精密な最新のＳＰＤＬエレメント状態遷移ダイヤグラムを作成できるであろう。しかし、状態遷移ダイヤグラムがどのようなものかの一例として図４が用意された。
【００３４】
図５は、典型的なバイナリＳＰＤＬ文書を１６進表現で示している。図５に示された文書と等価なクリアテキスト文書が図６に示されている。本発明を作用させると、図６に示した文書を入力して図５に示した形式へ変換することができる。なお、図５，図６及び図７はＳＰＤＬ規格の前の草案に合わせたものであるので、エレメントネームの中には最新草案に入っているエレメントネームと違うものがあるかもしれない。しかし、これは問題ではない。図５及び図６の目的は、クリアテキスト文書とバイナリ文書との間の対応関係を説明することだからである。本発明の作用を説明した後ならば、もっとよく図５及び図６の詳細が理解されよう。
【００３５】
図７は、図５に示された文書が図６に示された文書とどのように対応するかを説明するものである。図７より分かるように、６１はエレメントであるページセットを表わしている。６１の後の５９は、このページセットの長さ（ｌｅｎｇｔｈ）を表わしている。このページセット内に、ＡＳＮ．１タグ０６により表わされたＳＰＤＬ ＩＤがある。このＳＰＤＬ ＩＤの長さは４である。実際のＳＰＤＬ ＩＤは”ＩＳＯ/ＩＥＤ １０１８０//ＳＰＤＬ”であり、”２８ ＣＦ ４４ ００”によって表わされている。
【００３６】
次に、図７において、ＡＳＮ．１タグ４４がコメントに対応することが分かる。このコメントの長さは１Ｆである。このコメントの内容は”ＳＰＤＬ ＩＤ＝Public Object ＩＤ value ”である。次に、Ａ１はページセットボディとも呼ばれるところのｐｓｂｏｄｙを表わすことが分かる。図７の残りの部分も、同様に理解することができる。したがって、図７における対応関係の完全な説明は簡略化のため省略する。
【００３７】
図８は、クリアテキスト入力ファイルをバイナリ出力ファイルへ変換するために用いられる概念的構成を示す。クリアテキストデータ２０２はパーサー（parser）２０４によって文法解析される。この文法解析（parsing）は普通の公知メカニズムによって遂行されるので、その説明は簡略化のため省略する。
【００３８】
解析されたクリアテキストデータは、クリアテキスト−バイナリ・トランスレータ（translator）２０６及びＳＰＤＬ構造プロセッサ２０８へ送られる。クリアテキスト−バイナリ・トランスレータはＳＰＤＬ構造に関する特定の情報を知る必要があり、この情報はＳＰＤＬ構造プロセッサ２０８より与えられる。ＳＰＤＬ構造プロセッサは、ＳＰＤＬ規格案の新しい草案では構造アイデンティフィケーション（ＳＴＲＣＴＩＤクリアテキストタグ）とも呼ばれる外部宣言を管理するために利用され、また構造ＩＤ及び構造タイプを管理するために利用される。クリアテキスト−バイナリ・トランスレータ２０６は、ファイルのバイナリ表現をバイナリデータ２１０として出力する。
【００３９】
図９は図８のＳＰＤＬ構造プロセッサ２０８により文書を実際に処理するために用いられるデータ構造を示している。図９に示したデータ構造の利用法に関しては、米国特許出願第０７／８７６，２５１号（１９９２年４月３０日受理，”ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＴＯ ＨＡＮＤＬＥ ＩＮＣＬＵＳＩＯＮ ＯＦ ＥＸＴＥＲＮＡＬ ＦＩＬＥＳ ＩＮＴＯ Ａ ＤＯＣＵＭＥＮＴ ＰＲＯＣＥＳＳＩＮＧ ＬＡＮＧＵＡＧＥ”及び米国特許出願第０７／８７６，６０１号（１９９２年４月３０日受理，”ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＴＯ ＭＡＮＡＧＥ ＰＩＣＴＵＲＥ ＡＮＤ ＰＡＧＥＳＥＴＦＯＲ ＤＯＣＵＭＥＮ ＰＲＯＣＥＳＳＩＮＧ”に完全に述べられている。なお、これら出願（本出願はその一部継続出願である）は、処理中に取り込まれるべき外部ファイルに関するＳＰＤＬ構造エレメントである外部宣言に言及している。しかし、ＳＰＤＬ規格の新草案は、外部宣言中のエレメントＥＸＴＩＤの代わりに構造エレメントＳＴＲＣＴＩＤをエレメントネームに指定しているが、本出願の図９に示された並びに米国特許出願第０７／８７６，２５１号及び第０７／８７６，６０１号に示された各種データ構造により遂行される機能は同様である。さらに、同時係属米国特許出願第０８／０８７，５７１号（１９９３年７月２日受理，”ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＴＯ ＨＡＮＤＬＥ ＣＯＮＴＥＸＴ ＯＦＩＮＴＥＲＰＲＥＴＡＴＩＯＮ ＩＮ Ａ ＤＯＣＵＭＥＮＴ ＰＲＯＣＥＳＳＩＮＧ ＬＡＮＧＵＡＧＥ”に述べられている、より進歩した処理メカニズムを、構造及びコンテントの処理のために利用することもできる。
【００４０】
図９のピクチャー／ページセットスタック２２０は、文書の様々な階層レベルの管理のために利用される。文書の最初の階層レベルはピクチャー／ページセットスタック２２０のポインタ２２４に対応し、このポインタ２２４は連結リストデータ構造２２６を指す。このデータ構造２２６はページセットレベル（pageset level）２２８及びピクチャーレベル（picturelevel）２３０を管理するために利用される。また、データ構造２２６は、構造ＩＤ連結リストデータ構造２４２を指す外部宣言（externl declaration）ポインタ２３２を含む。このデータ構造２４２はＳＴＲＣＴＩＤタグに関連した構造ＩＤ及び構造タイプを管理するために利用され、外部宣言でも参照される。ＳＰＤＬ構造の処理期間に、ある階層レベルの処理中にもう１つのＳＴＲＣＴＩＤエレメントが出現すると、追加の構造ＩＤ連結リストデータ構造が、データ構造２２６と、外部宣言ポインタ２３２により前に指示されていたデータ構造との間に挿入される。例えば、外部宣言ポインタ２３２が構造ＩＤ連結リストデータ構造２５０を指していて、ＳＰＤＬ文書中に次のＳＴＲＣＴＩＤ構造エレメントが出現すると、構造ＩＤ連結リストデータ構造２４２がデータ構造２２６とデータ構造２５０の間に挿入されることになる。
【００４１】
文書の次の階層レベルが出現した時に、追加のエントリー２２２がピクチャー／ページセットスタック２２０にプッシュされる。また、新しいデータ構造２３４が生成され、このデータ構造２３４は外部宣言ポインタ２３２と同一の外部宣言ポインタ２４０を持つ。
【００４２】
図１０は、本発明の変換プロセスに利用される一時的アトリビュートバッファ（temporary attribute buffer）データ構造を示す。アトリビュートとはエレメントのサブエレメントであり、当該エレメントの属性を定義する。ＳＰＤＬクリアテキストにおけるアトリビュートの出現順序は、変換後のバイナリ文書に要求されるアトリビュート順序と異なることがある。クリアテキスト文書の各アトリビュートの処理変換時に、アトリビュートは一時的アトリビュートバッファデータ構造に書き込まれる。１つのエレメントに対して連続したアトリビュートが出現した時に追加の一時的アトリビュートバッファデータ構造２７０が生成され、このデータ構造２７０は前に生成された一時的アトリビュートバッファデータ構造のnextポインタにより指し示される。１つのエレメントに対する全アトリビュートの変換が終了すると、一時的アトリビュートバッファデータ構造の連結リストがバイナリ文書に要求される順序と比較され、順序に違いがあるときには、一時的アトリビュートバッファデータ構造は正しい順序に並べ替えられる。最初の一時的アトリビュートバッファデータ構造は、一時的アトリビュートポインタ２７２により指示される。一時的データ構造２７０はアトリビュートネーム（attribute name）のエントリー２７４とアトリビュート値（value）のエントリー２７６を有する。図１３乃至図１８に示したサブエレメント連結リストデータ構造に関連して、アトリビュートの例を説明する。
【００４３】
図１１に示したエレメントテーブルは、本発明の変換プロセスに利用される。変換されるべきファイルの１つのクリアテキスト（clear text）タグもしくはエレメントが出現する都度、このタグをエレメントテーブル２８０の第１カラムで調べる。図１１に示したクリアテキストタグの例は、！ＤＯＣＫＴＹＰＥ，ＳＰＤＬ，ＰＩＣＴＵＲＥ，ＰＩＣＴＢＤＹ，ＴＫＮＳＥＱＮである。
【００４４】
エレメントテーブル２８０の第２カラムは、ＡＳＮ．１表記法（notation）に関連したエレメント宣言に関するものである。このエレメント宣言はエレメントの属性の記述である。より具体的に言えば、エレメント宣言はエレメントの属性、及び、従属構造エレメントがあれば、その扱いに関するものである。各種宣言の例は、無宣言（ＮＯＮＥ）、オクテットストリング（octet string）、印刷可能ストリング、選択（choice）、シーケンス（sequence）、選択シーケンス（sequence of choice）、暗黙シーケンス（implicit sequence）である。なお、あらゆるクリアテキストタグ、各エレメント宣言及びクリアテキストタグに関する他の情報の全てを含む完全なエレメントテーブルは、ＳＰＤＬ規格案等の公知資料に見ることができ、また、それら資料を使って作成することができる。
【００４５】
本発明は、エンコーディングのシンタックスがＳＰＤＬエンコーディング条件に違反しないように、エレメント宣言を使用できる。
【００４６】
エレメントテーブル２８０の第３カラムは、エレメントに関するアトリビュート数を示す。前述のように、アトリビュートはエレメントに関する特定の特徴を記述するために用いられる。アトリビュート数のカラムにおいて、疑問符は該クリアテキストタグのためにアトリビュートがいくつ必要であるか分からないことを示し、０は該タグのためのアトリビュートがないことを示し、１は該タグのためにアトリビュートが１個あることを示す、等々である。
【００４７】
エレメントテーブル２８０の第４カラムは、該エレメントの下に出現できる各種サブエレメントの個数を示す。例えば、！ＤＯＣＴＹＰＥのエレメントもしくはクリアテキストタグの直ぐ下に出現できるサブエレメントは、１個だけである。ＳＰＤＬタグの下には、２５の異なったタイプのサブエレメントが出現可能である。
【００４８】
エレメントテーブル２８０の第５カラムは、サブエレメント連結リストへのポインタである。これらの連結リストは、エレメントの下に出現可能なサブエレメントに関する情報を記憶している。ＴＫＮＳＥＱＮタグは、どのようなサブエレメントもその下に出現しないので、そのサブエレメント連結リストデータ構造へのポインタはヌル（null）を指す。
【００４９】
図１２はサブエレメント連結リストデータ構造２８２を示す。これらのデータ構造は、図１１に示したエレメントテーブル内のサブエレメントへのポインタによって指示または参照でき、あるいは、別のサブエレメント連結リストデータ構造のnextポインタにより参照できる。
【００５０】
図１２に示したサブエレメント連結リストデータ構造２８２の第１フィールド２８４は、１つのサブエレメントのバイナリ表現を含む１つ以上のＡＳＮ．１タグを記憶する。第２フィールド２８５は、該サブエレメントのクリアテキスト表現を記憶する。第３フィールドはタイプ（type）フィールド２８６であり、サブエレメントのタイプを示す。このタイプは１つのタグもしくはアトリビュートであり、これはＡＴＴと略されることがある。
【００５１】
シーケンス番号エントリー２８７は、順序がバイナリエンコーディングで重要である場合に、サブエレメントがエレメント後のどこに出現しなければならないかを示す。例えば、シーケンス番号が１の場合、サブエレメントがエレメントの後に出現すれば、それはエレメント後に最初に出現するサブエレメントでなければならない。
【００５２】
フィールド２８８は、追加ＡＳＮ．１タグへのポインタを格納する。一定のＳＰＤＬエレメントは２つ以上のバイナリタグを必要とし、これらのエレメントについては、ポインタ２８８は追加ＡＳＮ．１タグ２８９を指す。それ以外のエレメントについては、ポインタ２８８はヌルを指す。
【００５３】
同じエレメントに関する一定の複数のサブエレメントは、同じ追加ＡＳＮ．１タグを持つという点で関連付けられる。この追加ＡＳＮ．１タグは、関連したサブエレメント中の１つが最初に変換された時に出現しなければならないが、同じ追加ＡＳＮ．１タグを持つ後続の関連サブエレメントの後には出現してはならない。しかし、サブエレメント連結リストの第１フィールドであるＡＳＮ．１フィールドは、サブエレメントの表現のために常に出現する。サブエレメント連結リストデータ構造の追加ＡＳＮ．１タグフィールドに関係するのが、図１９に示す長さ制御スタック（length control stack）中にある追加タグ（additionaltag）フラグである。この追加タグフラグは、長さ制御スタック中の追加タグであるエントリーについてはyesである。そうでなければ、追加タグフラグはnoである。図１９に示した長さ制御スタックに関するこれ以上の説明は、フローチャートと関連させて行なう。
【００５４】
サブエレメント連結リストデータ構造２８２の最後のエントリーは、次のサブエレメント連結リストデータ構造を指すnextポインタ２９０である。１つのエレメントに対し２つ以上のサブエレメントが存在するときには、各サブエレメントはそれ固有のサブエレメント連結リストデータ構造を持ち、その最初のサブエレメント連結リストデータ構造のｎｅｘｔポインタは２番目のサブエレメントのサブエレメント連結リストデータ構造を指す。
【００５５】
図１３は、！ＤＯＣＴＹＰＥエレメントのためのサブエレメント連結リストデータ構造を示す。このサブエレメントはＳＰＤＬタグであり、ＳＰＤＬのＡＳＮ．１表現は２８Ｈである。ＳＰＤＬは！ＤＯＣＴＹＰＥのための唯一のサブエレメントであるので、シーケンス番号は１である。２８Ｈは１つのタグであるので、追加ＡＳＮ．１タグポインタはヌルを指す。！ＤＯＣＴＹＰＥエレメントに対するサブエレメントは１つしかないので、このサブエレメントのためのサブエレメント連結リストデータ構造のnextポインタもヌルを指す。
【００５６】
ＳＰＤＬエレメントは、図１４から分かるように、１つ目のページセット、２つ目のピクチャーというサブエレメントを持つ。これらサブエレメントはデータ構造３２０，３３０にそれぞれ格納されている。
【００５７】
ピクチャーエレメントの１番目のサブエレメントＣＯＮＴＲＥＰは、コンテント表現を示すもので、かってＳＰＤＬ規格の前草案でコンテントタイプと呼ばれた。このサブエレメントは図１５に示したデータ構造３４０に格納されている。このピクチャーエレメントの２番目のサブエレメントはＰＩＣＴＢＤＹであり、その情報はデータ構造３５０に格納されている。
【００５８】
なお、ＳＰＤＬエレメント及びピクチャーエレメントについては、２９個及び４個の可能なサブエレメントがそれぞれ存在することは図１１に示したエレメントテーブルに見られるとおりであるが、これらのサブエレメントのそれぞれは簡略にするため図１４及び図１５には示されなかった。しかし、これらのサブエレメント連結リストデータ構造は、ＳＰＤＬに関する公知情報を利用すれば誰でも作成可能である。
【００５９】
図１６は、ＰＩＣＴＢＤＹエレメントに対して可能なサブエレメントを示す。１番目の可能なサブエレメントはデータ構造３６０に格納されたＰＲＯＬＯＧＵＥ（プロローグ）である。プロローグを表現するには２つのタグが必要であるので、ＡＳＮ．１タグフィールドは６８Ｈであり、追加ＡＳＮ．１タグポインタはＡ０Ｈタグ３６８を指す。ＰＩＣＴＢＤＹエレメントに対する他のサブエレメントは、サブエレメント連結リスト３７０内のＳＴＲＣＴＩＤ、データ構造３８０内のＰＩＣＴＵＲＥ、データ構造３８２内のＴＫＮＳＥＱＮ（トークンシーケンス）、及び再び出現するデータ構造３８４内のＳＴＲＣＴＩＤである。
【００６０】
図１６から分かるように、ＰＩＣＴＢＤＹエレメントの下のＳＴＲＣＴＩＤサブエレメントは２つの異なったバイナリ表現を持つことができる、すなわち、１つ目はデータ構造３７０による Ａ０ ６Ｅ ４１ であり、２つ目はデータ構造３８４による Ａ１ ６Ｅ ４１ である。これらの異なったバイナリ表現は、変換されるべき文書に出現するＳＴＲＣＴＩＤクリアテキストタグの特殊な情報（ＳＰＤＬ規格の前の草案で外部宣言とも呼ばれたもの）に依存する。様々なＳＴＲＣＴＩＤサブエレメントの用法のより完全な説明は、フローチャートに関連して述べる。
【００６１】
図１７は及び図１８はＰＲＯＬＯＧＵＥエレメントのためのサブエレメント連結リストを示す。図１７に示したデータ構造３９６の最後のフィールドから出る線は、図１８に示したデータ構造３９８を指す。図１７及び図１８は、ＳＰＤＬに関する公知情報を用いて作成されたが、ＰＲＯＬＯＧＵＥエレメントの下には非常に多数のサブエレメントが出現可能であるので、サブエレメント連結リストの完全な図ではなく、データ構造４０８で終わっている。しかし、必要ならば、ＳＰＤＬ関連情報の公知資料を用いて完全なＰＲＯＬＯＧＵＥサブエレメント連結リストデータ構造を作成できる。
【００６２】
図１９は、ＳＰＤＬクリアテキスト文書がバイナリへ変換される時に利用される長さ制御スタック４２０を示す。最初に処理されるエレメントは、スタックのボトムにあって、通常、ＳＰＤＬタグである。クリアテキストタグは、第１カラムすなわちエレメントネームに出現する。スタックの第２カラムはＡＳＮ．１タグ値で、これはクリアテキストエレメントネームのバイナリ表現である。スタックの第３カラムはバッファカウント（count）で、バッファポインタにより指示されるバッファ４２２内の現在のバイト数を示す。追加タグフラグは、長さ制御スタックに記憶されているタグがサブエレメント連結リストデータ構造からの追加ＡＳＮ．１タグであることを示す。この情報は、後のサブエレメントに対し追加ＡＳＮ．１タグが存在するときに、それがクリアテキストエレメントのバイナリ表現に使用されるべきか判定するため該後のサブエレメントを処理する時に利用される。
【００６３】
さて、図２０乃至図２１に示したフローチャートを参照し、本発明の動作を説明する。図２０において、プロセスはステップ５００から始まり、ステップ５０２で構造パーサーを呼び出す。文法解析（parsing）が行なわれるが、これは公知の普通の文法解析メカニズムによってなされるので、その説明は簡略化のため省略する。図２０には３つの異なったプロセスがあり、これらを処理されているクリアテキストタグのタイプに応じて呼び出すことができる。処理されているタグがコメント（comment）タグであってコメントの始まりならば、ステップ５０６で図２１に示されているコメント（comment）プロセッサが呼び出される。変換されるタグがトークンシーケンス開始（begin）タグならば、フローはステップ５０８からステップ５１０へ進み、ステップ５１０で図２２に示されているトークンシーケンスプロセッサを呼び出す。処理すべき他の有効なタグがあれば、フローはステップ５１２からステップ５１４へ進み、図２７に示されているタグ（tag）プロセッサを呼び出す。ステップ５１２で処理すべき有効なタグがないと判定したときには、プロセスはステップ５１６で終了しエラーを表示する。
【００６４】
図２０には、処理の正常終了で終わるステップが含まれていないことに注意されたい。本発明の全体プロセスは図３０で終了する。図３０はＳＰＤＬ終了ルーチンを示しているが、これについては後述する。また、ステップ５０６，５１０，５１４は様々なプロセッサに言及するが、図に示したものは１つのプロセスを実行するためのフローチャートである。したがって、それらプロセスを実行する独立の物理プロセッサを持つ必要はなく、言及したプロセッサは概念的な機能要素である。
【００６５】
図２１に示されるコメントプロセッサは、コメントタグの処理を扱う。図２１において、ステップ５２２はコメントタグの最後まで入力データがスキップされることを示す。したがって、コメント情報は実際にはクリアテキストからバイナリへ変換されない。コメントはＳＰＤＬ文書の実際の処理に必要でないからである。しかし、コメント内の情報を保存したいときには、コメントプロセッサがその役割の実行を終了した後に図２７に示したタグプロセッサにコメントタグを処理させることによって、コメント情報をスキップしないでバイナリに変換することも可能である。ステップ５２４からフローは図２０のプロセスへ戻り、次の構造エレメントの文法解析のためにステップ５０２で構造パーサーが再度呼び出される。
【００６６】
図２０において、ステップ５０８とステップ５１０により図２２に示されたトークンシーケンスプロセッサが呼び出される。トークンシーケンスは文書のコンテントを含む構造エレメントである。図２２において、ステップ５５２が図２３に示された長さ制御スタックセットアップルーチン（後述）を呼び出す。次にステップ５５４で、トークンシーケンス構造エレメント内に含まれているコンテントを文法解析するコンテントパーサー（content parser）が呼び出される。この文法解析も普通の文法解析メカニズムにより遂行されるので、その説明は簡略化のため省略する。
【００６７】
ステップ５５６では、トークンシーケンスの終わりが検出されたか判定する。検出されていなければ、ステップ５６４で該トークンシーケンスを調べ、それが有効であるか判定する。有効でなければ、ステップ５６６でエラーコードが返される。該トークンシーケンスが有効ならば、ステップ５６８で該トークンシーケンスをバイナリ表現へ変換する。そしてステップ５７０で、そのバイナリ表現を長さ制御スタックに利用されるバッファに格納する。ステップ５７０からフローはステップ５５４へ戻る。トークンシーケンス終了タグが検出されたとステップ５５６で判定したときには、ステップ５５８で入力ポインタを、該トークンシーケンス終了タグの次のエレメントを指すように設定する。このポインタは、クリアテキスト入力ファイルの次に処理すべきエレメントを指示する。次にステップ５６０で、図２６に示された終了タグルーチンを呼び出す。このルーチンはトークンシーケンスエレメントの終了タグを処理するために用いられる。そして、ステップ５６２でフローは図２０へ戻る。
【００６８】
図２３、図２４及び図２５は”長さ制御スタックセットアップ（set−up）ルーチン”を示す。このルーチンは、１つの新しいクリアテキストタグが変換されようとするたびに、図１９に示した長さ制御スタックをセットアップするために利用される。この長さ制御スタックセットアップルーチンにおいて、Ｃurrent−Ｔagはエレメントテーブルを調べるために利用され、Ｔag−Ｒead−Ｉnはサブエレメント連結リストを調べるために利用され、Ｐrevious−Ｔagは処理されるタグの親エレメント（Ｔag−Ｒead−Ｉn）を格納するために用される。
【００６９】
長さ制御スタックセットアップルーチンが呼び出された後、図２３のステップ６０２で、変換しようとする新しいエレメント（Ｔag−Ｒead−Ｉn）が、処理されたばかりのエレメント（Ｃurrent−Ｔag）により指し示されるサブエレメント連結リストに見つかるか判定する。見つからないときには、変換しようとする該新エレメントは処理されたばかりのエレメントの適切なサブエレメントでないので、ステップ６０４でエラーが表示される。該新エレメントが適切なエレメントであるときには、ステップ６０６でＰrevious−Tag＝Ｃurrent−Ｔagに設定する。そしてステップ６０８で、Ｃurrent−Ｔagをたった今読み込まれたタグ（Ｔag−Ｒead−Ｉn）と等しい内容に設定する。
【００７０】
ステップ６１０で、Ｃurrent−Ｔagを格納しているサブエレメント連結リストの追加ＡＳＮ．１タグポインタがヌルを指すか判定する。該ポインタがヌルを指すか否かによって、異なる処理が実行される。該タグがヌルを指さないときには、フローは図２４に示されるプロセスＡＡへ進む。該タグがヌルを指すときには、図２４に示される各ステップと図２５の上部分は実行されず、フローは図２５に示されるＣＣへ進む。
【００７１】
該追加ＡＳＮ．１タグポインタがヌルを指さない場合、該ポインタにより指される追加ＡＳＮ．１タグが存在するので、フローは図２４に示されるプロセスＡＡへ進む。
【００７２】
図２４において、ステップ６２０で長さ制御スタックのトップエントリーの追加タグフラグがyesであるか判定する。yesでなければ、図２４のステップ６２２〜ステップ６３６を省くことができるので、フローは図２５に示されるプロセスＢＢへ進む。
【００７３】
長さ制御スタックのトップにある追加タグフラグがyesでないときには、フローはステップ６２２へ進み、ここで長さ制御スタックのトップエントリーのＡＳＮ．１タグが追加ＡＳＮ．１タグポインタに指されるタグと等しいか調べられる。等しければ、該追加ＡＳＮ．１タグに対し実行すべき処理はないので、サブエレメント連結リストのトップエントリーに格納されているＡＳＮ．１タグ（１つ又は複数）を処理するため、フローは図２５に示されるプロセスＣＣへ進む。長さ制御スタックのトップにあるＡＳＮ．１タグが該サブエレメント連結リストデータ構造の追加ＡＳＮ．１タグポインタにより指される追加ＡＳＮ．１タグと等しくなければ、該追加ＡＳＮ．１タグを処理する必要があるので、フローはステップ６２４へ進む。
【００７４】
ステップ６２４で、スタックのトップのバッファカウントを下のエントリーのバッファカウントに加える。ステップ６２６で、スタックのトップにあるＡＳＮ．１タグ値のバイト数を下のエントリーのバッファカウントに加える。ステップ６２８で、スタックのトップのバッファカウントのＡＳＮ．１ ＢＥＲ長さエンコーディングのバイト数を、下のエントリーのバッファカウントに加える。ステップ６３０で、スタックのトップのＡＳＮ．１タグ値を下のエントリーのバッファへ追加（アペンド）する。ステップ６３２で、スタックのトップのバッファを下のエントリーのバッファへ追加し、ステップ６３６で長さ制御スタックのトップエントリーをポップして捨てる。
【００７５】
図２５において、ステップ６４０で長さ制御スタックのトップに新しいエントリーを追加する。ステップ６４３で、この新しいエントリーのために１つのバッファを割り当て、スタックのトップエントリーのバッファポインタを該新バッファを指すように設定する。ステップ６４４で、追加ＡＳＮ．１タグポインタにより指される追加ＡＳＮ．１タグをスタックのトップに入れる。次に、ステップ６４６で、Ｐrevious−Ｔag（処理されるサブエレメントのエレメントのクリアテキストＳＰＤＬネーム）を長さ制御スタックのトップエントリーのエレメントネームフィールドに書き込む。ステップ６４８でスタックのトップエントリーのバッファカウントを０に設定し、ステップ６５０でスタックのトップエントリーの追加タグフラグをyesに設定する。
【００７６】
図２３及び図２４のＣＣ及びステップ６５０の次に、ステップ６５２でサブエレメントのＡＳＮ．１タグの処理を始める。ステップ６５２に初めて来た時は、処理されるべきサブエレメントのＡＳＮ．１タグがあるであろうから、フローはステップ６５４へ進む（長さ制御スタックのトップに１つのエントリーを追加する）。ステップ６５６でサブエレメント連結リストよりＡＳＮ．１タグを取得する。ステップ６５８で、該ＡＳＮ．１タグをスタックのトップエントリーに入れる。ステップ６６０で、スタックのトップエントリーのバッファを割り当て、スタックのトップエントリーのポインタを当該バッファを指すように設定する。ステップ６６２で、Ｃurrent−Ｔagをスタックのトップエントリーのエレメントネームに入れる。ステップ６６４でスタックのトップエントリーのバッファカウントを０に設定し、ステップ６６６で、現在処理されているタグは追加タグではなくサブエレメント連結リストの第１フィールドに格納されているタグであるので、スタックのトップエントリーの追加タグフラグをｎｏに設定する。ステップ６６６よりフローはステップ６５２に戻り、サブエレメント連結リストのトップフィールドのＡＳＮ．１タグの全部が処理されるまでステップ６５２〜６６６のループが実行される。これらＡＳＮ．１タグ全部が処理されると、フローは呼び出したプロセスへ戻る。
【００７７】
図２６は、クリアテキスト終了タグに達した時に長さ制御スタックの処理及び調整をするために用いられる”終了タグルーチン”を示す。開始すると、ステップ７０８でスタックのトップにあるエレメントネームが終了タグであるか判定する。終了タグでなければ、エラーがあるのでエラーメッセージが出される。終了タグであれば、フローはステップ７１０へ進む。
【００７８】
ステップ７０８でスタックのトップにあるエレメントネームが終了タグであると判定した場合、ステップ７１０で長さ制御スタックのトップエントリーのバッファカウントを、長さ制御スタックのトップエントリーより１つ下のバッファカウントエントリーへ加える。ステップ７１２で、ＡＳＮ．１タグのバイト数を下のエントリーのバッファカウントへ加える。次にステップ７１６で、スタックのトップエントリーのバッファの長さに関する長さ情報を表現するのに必要なバイト数を下のエントリーに加える。次にステップ７１８で、ＡＳＮ．１タグを下のエントリーのバッファに追加する。次にステップ７２０において、スタックのトップのバッファカウントの長さが下のエントリーのバッファへ加えられる。そして、ステップ７２４で、スタックのトップエントリーのバッファの内容が下のエントリーのバッファに追加される。ステップ７２６で長さ制御スタックよりトップエントリーをポップする。ステップ７２８で、長さ制御スタックのトップにあるエレメントネームが終了タグであるか判定する。終了タグであるならば、フローはステップ７１０へ戻って当該終了タグのための処理を繰り返す。終了タグでなければ、フローはステップ７３０へ進み、Ｃurrent−Ｔagは長さ制御スタックのトップにあるエレメントネームと同じに設定される。そして、フローは呼び出したプロセスに戻る。
【００７９】
図２７は”タグプロセッサ”により実行されるプロセスを説明するフローチャートを含んでいる。このプロセスは図２０のステップ５１４により呼び出される。このプロセスは、コメントタグ及びトークンシーケンスタグ以外の全てのタグの処理のために用いられる。ステップ７５０で、処理されるクリアテキストタグが！ＤＯＣＴＹＰＥであるか調べる。！ＤＯＣＴＹＰＥであるときには、図２８に示された”！ＤＯＣＴＹＰＥプロセッサ”がステップ７５２により呼び出される。ステップ７５６でＳＰＤＬ開始コマンドがあるか判定する。あるならば、図２９に示される”ＳＰＤＬ開始ルーチン”がステップ７５８により呼び出される。ステップ７６２でＳＰＤＬ終了タグがあるか判定する。あるならば、フローはステップ７６４へ進み図３０に示される”ＳＰＤＬ終了ルーチン”を呼び出す。つぎにステップ７６８で、処理されるエレメントが終了タグであるか判定する。終了タグならば、フローはステップ７７４へ進み、その終了タグネームが長さ制御スタックのトップにあるエレメントネームであるか判定する。そうでないときには、スタックのトップのエレメントはたった今終了したエレメントに対応しなければならないのであるから、ステップ７７６でエラーメッセージが表示されプロセスは終了する。終了タグがスタックのトップにあるならば、フローはステップ７７８へ進み、図２６に示される”終了タグルーチン”を呼び出す。
【００８０】
タグが終了タグでないとステップ７６８で判定したときには、ステップ７７０で図３１に示される”開始タグルーチン”を呼び出す。これらルーチンのどれかが図２７で呼び出された後、フローは図２７に戻り、続いてステップ７５４，７６０，７７２又は７８０によって呼び出したプロセスへ戻される。
【００８１】
図２８は、図２７のステップ７５２から呼び出される”！ＤＯＣＴＹＰＥプロセッサ”によって実行されるプロセスのフローチャートを示す。図２８において、ステップ７８２でクリアテキスト！ＤＯＣＴＹＰＥエレメントの次のストリングを、スペースのようなセパレータを無視して取得する。ステップ７８４で、当該ストリングを大文字に変換した後、それが”ＳＰＤＬ”であるか調べる。”ＳＰＤＬ”でないときには、ＳＰＤＬの後に”！ＤＯＣＴＹＰＥ”エレメントが続かなければならないので、エラーがある。”ＳＰＤＬ”であるときには、ステップ７８８で入力ファイルのポインタを当該”！ＤＯＣＴＹＰＥ”の次を指すように設定する。次に、ステップ７９０で、カレント（current）エレメント＝！ＤＯＣＴＹＰＥタグに設定する。なお、最初のエレメントが！ＤＯＣＴＹＰＥである場合には長さ制御ルーチンは呼び出されない。
【００８２】
図２９は、図２７のステップ７５８により呼び出される”ＳＰＤＬ開始ルーチン”を示す。このルーチンはＳＰＤＬ開始タグを処理する。まず、ステップ８０２で、ＳＰＤＬエレメントに対する１つのエントリーをスタックに生成するため、図２３に示される”長さ制御スタックセットアップルーチン”を呼び出す。次に、ステップ８０４で、長さ制御スタックのトップエレメントのＡＳＮ．１タグとして２８Ｈを書き込む。これは外部エレメントであるＡＳＮ．１タグ ＵＮＩＶＥＲＳＡＬ ８ に対応する。これはＳＰＤＬのために必要なタグである。次に、長さ制御スタックのトップエントリーのバッファに７エレメントが書き込まれようとしているので、スタックのトップエレメントのバッファカウントエントリーは７に設定される。次にステップ８０８は、１６進表現の ０６ ０５ ２８ ＣＦ （これはテキスト表現の”Ｏbject Ｉdentifier ＩＳＯ／ＩＥＣ （１） ＳＴＡＮＤＡＲＤ （０）１０１８０ ０”に相当する）を、長さ制御スタックのトップエントリーのバッファに書き込む。最後にステップ８１０でフローは図２７へ戻る。
【００８３】
図３０は、図２７のステップ７６４により呼び出される”ＳＰＤＬ終了ルーチン”により実行されるプロセスのフローチャートを示す。図３０において、ステップ８２２で、長さ制御スタックのトップにあるエレメントネームが”ＳＰＤＬ”であるか判定する。”ＳＰＤＬ”でないときには、スタックのトップにあるエレメントは終了エレメントでなければならないのであるから、エラーがある。したがって、ステップ８２４でエラーメッセージが表示される。”ＳＰＤＬ”であるときには、ステップ８２６で、このＳＰＤＬエレメントのＡＳＮ．１タグ（＝２８Ｈ）が出力ファイルに書き込まれる。この出力ファイルは、バイナリフォーマットに変換された最終文書を格納する。次にステップ８２８で、ＡＳＮ．１のベーシックエンコーディング規則（Ｂasic Ｅncoding Ｒules）に従って、長さ制御スタックのトップエントリーのバッファカウントを長さ値（length value）に変換し、この情報を出力ファイルに書く。最後に、ステップ８３０で、長さ制御スタックのトップエントリーより指されたバッファの情報が出力バッファに書かれる。したがって、ファイルの全情報が変換され所望の出力ファイルへ書き込まれたので、ステップ８３２で当該プロセスは終了となる。
【００８４】
図３１乃至図３３は”開始タグルーチン”を示す。このルーチンは！ＤＯＣＴＹＰＥ、ＳＰＤＬ、コメント、トークンシーケンス以外の一般的なクリアテキストタグが変換される時に必ず実行される。図３１において、ステップ９５４で新たに処理しようとするエレメントが、処理されたばかりのエレメントのサブエレメント連結リスト中に見つかるか判定する。見つからない時には、この新しいエレメントは前エレメントの適切なサブエレメントではないので、ステップ９５６でエラーメッセージが出される。該エレメントが適切なエレメントであるときには、フローはステップ９５８へ進み、該クリアテキストタグが”ＳＴＲＣＴＩＤ”であるか判定する。そうであるならば、ステップ９６０で図３４に示される”ＳＴＲＣＴＩＤプロセッサ”が呼び出される。”ＳＴＲＣＴＩＤ”でないときには、フローはステップ９５８からステップ９６４へ進み、図２３に示される”長さ制御スタックセットアップルーチン”を呼び出す。
【００８５】
次に、ステップ９６６は処理されているエレメントがアトリビュートを持っているか判定する。持っているならば、フローは図３２に示されるプロセスＡへ進む。アトリビュートがないときには、フローはステップ９６８へ進み、エレメント宣言が空であるか判定する。空エレメント宣言は、開始タグと終了タグとの間にデータがない時に出現する。この場合、その終了タグは省かれなければならない。
【００８６】
エレメント宣言が空であるときには、フローはステップ９７０へ進み、終了タグパラメータ＝開始タグとして、図２６に示される”終了タグルーチン”を呼び出す。エレメントタグが空でないときには、ステップ９７４で、エレメントのための何等かのデータ（すなわち、エレメントの開始タグに続くデータ）があるか判定する。データがなければ、ステップ９７６でフローは呼び出したプロセスへ戻る。
【００８７】
ステップ９７８で、データをバイナリフォーマットへエンコードする必要があるか判定する。必要があれば、フローはステップ９８０へ進み、データをバイナリへ変換する。バイナリへエンコードする必要が常にあるかも知れない。しかし、ある種のデータがエンコード／変換される必要がない場合やＳＰＤＬ規格が変わる場合に備えて、ステップ９７８が入れられている。
【００８８】
次にステップ９８２で、データを長さ制御スタックのトップのバッファへ入れる。ステップ９８４で、長さ制御スタックのトップエントリーのバッファ中のバイト数をカウントし、該バイト数を長さ制御スタックのバッファカウントに書き込む。そして、ステップ９８６でフローは呼び出したプロセスに戻る。
【００８９】
図３２は、アトリビュートがあると判定される時に図３１により呼び出されるプロセスＡを示す。図３２おいて、ステップ１０００はアトリビュートネームとアトリビュート値を取得する。ステップ１００２は、そのアトリビュートネームが、エレメントテーブルの現在エレメント位置により指される連結リスト中にあるか判定する。存在しないときには、アトリビュートは適切なサブエレメントではないので、ステップ１００４はプロセスを終わらせてエラーメッセージを表示する。
【００９０】
次にステップ１００６で、アトリビュートネームが”notation”であるか判定する。そうならば、図２３に示される長さ制御スタックセットアップルーチンが呼び出され、フローは図３３に示されるプロセスＣへ進む。アトリビュートネームが”notation”であるときには、このアトリビュートは開始タグと終了タグの間のデータタイプを指定する。例えば、オブジェクトアイデンティファイア（Ｏbject Ｉdentifier）が”ｎ１．ｎ２．ｎ３．．．．”とエンコードされたとき（ｎ１，ｎ２，ｎ３．．．はクリアテキストエンコーディングでは１０進表現である）、バイナリエンコーディング（ＢＥＲ）は別のエンコーディングスキームを用いる。したがって、ｎ１．ｎ２．ｎ３．．．はバイナリフォーマットへ変換されなければならない。
【００９１】
アトリビュートネームが”notation”でないときには、フローはステップ１０１０へ進み、図１０に示したような一時的アトリビュートバッファデータ構造からなる一時的アトリビュートバッファ連結リストの最後に、一つの一時的アトリビュートバッファデータ構造を挿入する。次にステップ１０１２で、アトリビュート値をクリアテキストからバイナリへ変換する必要があるか判定する。例えば、クリアテキストのアトリビュートがＣＯＮＴＲＥＰで、その値が”ＩＳＯ／ＩＥＣ”であると、この値は ０６ ０６ ２８ ＣＦ ４４ ００ ０２ ００ と変換される。これは１バイトずつの変換ではなく、アトリビュート全体が調べられ、バイナリの等価な値へ変換されるもので、各テキスト文字を個別に変換するものではない。
【００９２】
アトリビュート値を変換する必要があるときには、ステップ１０１４でアトリビュート値をバイナリへ変換する。次にステップ１０１６で、アトリビュート値及びアトリビュートネームを、新しく生成された一時的アトリビュートバッファデータ構造（ステップ１０１０により生成された）に格納する。次にステップ１０１８で、ほかに処理すべきアトリビュートがあるか判定する。あるときには、フローは図３２の上部に示されるプロセスＡへ進む。そうでなければ、図３５に示される”アトリビュート終了ルーチン”がステップ１０２０で呼び出され、そしてフローは図３１に示されるプロセスＢへ戻る。
【００９３】
図３３において、ステップ１０３０では、処理されているエレメントの開始タグと終了タグの間のデータを取得し、入力情報のポインタを、該終了タグの後のエレメントを指すように設定する。ステップ１０３２でアトリビュート値が”ＯＢＪＩＤ”であるか判定する。そうであるならば、フローはステップ１０３４へ進み、長さ制御スタックのトップにある値を０６Ｈ（これはＡＳＮ．１オブジェクトアイデンティファィアである）に設定する。つぎに、ステップ１０３６で、ステップ１０３０において得られたデータを、バイナリエンコーディングに変換し、フローは図３３に示されるプロセスＤへ進む。ステップ１０３８で、アトリビュート値が”ＥＮＶＮＭ”であるか判定する。そうならば、フローはステップ１０４０へ進み、長さ制御スタックのトップにあるタグ値を４３Ｈ（これはＡＳＮ．１アプリケーション３である）に設定する。そして、フローはプロセスＤへ進む。
【００９４】
ステップ１０４２で、アトリビュート値が”ＰＵＢＩＤ”であるか判定する。そうでなければ、値”ＰＵＢＩＤ”が期待されるとのエラーのメッセージであるから、ステップ１０４４でエラーを表示する。ステップ１０４６において、パブリックアイデンティファイア（public identifier）が対応するオブジェクトアイデンティファィアを持つか判定される。持っていれば、フローはステップ１０３４へ進む。持っていなければ、ステップ１０４８で長さ制御スタックのトップにあるタグ値をＡＳＮ．１アプリケーション１（これはバイナリで４２Ｈと表わされる）に設定する。
【００９５】
次にステップ１０５０で、ステップ１０３０において得られたデータを、長さ制御スタックのトップエントリーのバッファにコピーする。ステップ１０５２で、バッファバイトサイズをカウントし、このカウント値を長さ制御スタックのトップエントリーのバッファカウントエントリーに入れる。次にステップ１０５４で、図２６の”終了タグルーチン”を適当な終了タグに関して２度呼び出す。このルーチンが２度呼び出されるのは、長さ制御スタックルーチンが２回呼び出される（図３１のステップ９６４と図３２のステップ１００８）ことに対応するためである。そして、ステップ１０５６で、フローは呼び出したプロセスへ戻る。
【００９６】
図３４は、図３１のステップ９６０で呼び出される”ＳＴＲＣＴＩＤプロセッサ”を示す。図示のプロセスは、クリアテキストタグ”ＳＴＲＣＴＩＤ”を処理するために用いられる。ＳＴＲＣＴＩＤエレメントに対するバイナリ表現は、変換されるべきファイル中の前に出現するエレメントによって変わることがあるので、ＳＴＲＣＴＩＤエレメントのための特殊なルーチンがある。例えば、図１６はＰＩＣＴＢＤＹエレメントのためのサブエレメント連結リストデータ構造を示している。図１６において、データ構造３７０及びデータ構造３８４は共にＳＴＲＣＴＩＤサブエレメントのためのものである。図３４に示したフローチャートは、図１６に示したＳＴＲＣＴＩＤエレメントのどれが処理中に用いられるか判断するために利用される。
【００９７】
図３４において、ステップ１０８０で変換中のエレメントからＳＴＲＣＴＩＤデータを取得する。ステップ１０８０で取得されるＳＴＲＣＴＩＤデータの例は、ピクチャー、ページセット、トークンシーケンス、Ｐictbdy、プロローグである。ＳＴＲＣＴＩＤデータは、どのタイプの情報が外部リソース中に含まれているかを示す。この情報は、図１６のＳＴＲＣＴＩＤに対しどのＡＳＮ．１タグが用いられるかの判断を助けるために利用される。
【００９８】
次に、ステップ１０８２で、ピクチャー／ページセットスタックのトップエントリーにより指示されたデータ構造の外部宣言ポインタにより指された連結リスト中のＳＴＲＣＴＩＤを探す（図９参照）。図９に示したデータ構造は、変換すべき文書の実際の処理（変換プロセスではない）の間に生成される。図９に示したデータ構造の生成及び処理は、特許査定された米国特許出願第０７／８７６，２５１号（１９９２年４月３０日受理、”Ｍethod and Ｓystem to Ｈandle Ｉnclusion of Ｅxternal Ｆiles Ｉnto a Ｄocument Ｐrocessing Ｌanguage”に詳細に述べられている。
【００９９】
次にステップ１０８４で、図９に示した構造ＩＤ連結リストデータ構造のいずれかの中の構造ＩＤが、変換されるべきＳＴＲＣＴＩＤクリアテキストエレメントに対応するか判定する。対応しないときは、エラーがあるので、ステップ１０８６でプロセスを終了させる。対応するときには、ステップ１０８８で該エレメントの構造タイプを対応する構造ＩＤ連結リストデータ構造から取得する。構造タイプが得られると、ステップ１０９０でカレント（current）エレメントのサブエレメント連結リストをトレースし、ＳＴＲＣＴＩＤ連結リストデータ構造中に見つかった構造タイプを見つける。例えば、図９に示した連結リスト中の構造タイプがピクチャーであると判定された場合、該ピクチャーに対応するＳＴＲＣＴＩＤを見つけるべくサブエレメント連結リストリストがトレースされる。
【０１００】
構造タイプがサブエレメント連結リスト中に見つからないときには、フローはステップ１０９２からステップ１０９４へ進みプロセスを終了させる。構造タイプが見つかったときには、ステップ１０９６でサブエレメント連結リストのトレースを、ＳＴＲＣＴＩＤが見つかるまで続ける。したがって、ステップ１０９０では構造エレメントを確定し、そしてステップ１０９６で該構造エレメントの後の最初のＳＴＲＣＴＩＤを求める。
【０１０１】
次にステップ１０９８で、図２３に示したステップ６０６からの”長さ制御スタックセットアップルーチン”を呼び出す。次にステップ１１００で、フローは呼び出したプロセスへ戻る。
【０１０２】
図３５は”アトリビュート終了ルーチン”を示す。このルーチンは、図３１及び図３２に示したプロセスで始まったアトリビュートの変換処理を終了させるために用いられる。図３５において、ステップ１１２０で一時的アトリビュートバッファ連結リストがカレント（current）エレメントのためのサブエレメント連結リストのアトリビュートと同じ順序であるか判定する。同じ順序でないときには、ステップ１１２２で一時的アトリビュートバッファ連結リストを、サブエレメント連結リストのアトリビュートと同じ順序を持つように並べ替える。同じ順序のときには、順序を並べ替える必要がないので、フローはステップ１１２０から直ちにステップ１１２４へ進み、一時的アトリビュートバッファデータ構造中のアトリビュート全部が処理されたか判定する。ステップ１１２４が初めて呼び出される時には、アトリビュートの全部は処理されていないので、フローはステップ１１２８へ進み一時的アトリビュートバッファ連結リストデータ構造中の最初のアトリビュートのアトリビュートネームを取得する。ステップ１１３０で、図２３に示された”長さ制御スタックセットアップルーチン”を呼び出す。ステップ１１３２で、バイナリのアトリビュート値を長さ制御スタックのトップエントリーのバッファに入れる。ステップ１１３４で、バッファのバイトサイズをカウントし、そのサイズを長さ制御スタックのトップエントリーのバッファカウントに書き込む。ステップ１１３６は図２６に示された”終了タグルーチン”を呼び出し、フローはステップ１１２４へループバックする。アトリビュート全部が処理されると、フローは呼び出したプロセスへ戻る。そうでなければ、ステップ１１２８〜１１３６が繰り返される。
【０１０３】
図３６は、本発明のプロセスを実行するために利用できるワークステーション１２００の構成を示す。ワークステーション１２００はＣＰＵ１２０２、ＲＡＭ１２０４、ＲＯＭ１２０６、キーボード１２１０及びマウス１２１４と接続された入力コントローラ１２０８を含む。印刷エンジンインターフェイス１２１６が印刷エンジン１２１８に接続され、印刷エンジン１２１８は該インターフェイス１２１６によって伝送される画像データのビデオ制御信号を受信する。ワークステーション１２００はさらに、ハードディスク１２２４及びフロッピーディスク１２２６と接続されたデスクコントローラ１２２２、ネットワーク１２３０（例えばＥthernet（登録商標）ネットワーク）に接続するための通信コントローラ１２２８、Ｉ／Ｏコントローラ１２３２を含む。Ｉ／Ｏコントローラ１２３２は、例えばＳＣＳＩバスにより外部のハードディスク１２３６と接続され、例えばＲＳ−２３２ケーブルによってプリンタ１２３４と接続される。ワークステーション１２００は、ＣＲＴ１２４０と接続されるディスプレイコントローラ１２３８も含む。システムバス１２２０はワークステーション内部の各要素を接続する。
【０１０４】
本発明のプロセスは、図３６に示した記憶装置中のどれに格納してもよい。さらに、本発明のプロセスの実行中に、生成されるデータ及び処理に利用されるデータは図３６に示した記憶装置中のどれに格納してもよい。ＣＰＵ１２０２は本発明のプロセスの実行をするために利用できる。
【０１０５】
図３７は、本発明の変換プロセスの実行例に用いられる典型的なＳＰＤＬ文書を示す。行１は！ＤＯＣＴＹＰＥエレメントを含んでいる。行２はＳＰＤＬエレメントを含んでいる。行３はアトリビュート”コンテント表現”を持つピクチャーエレメントを含んでいる。行４はＰＩＣＴＢＤＹエレメントを含んでおり、行５はそのプロローグを含んでいる。図３７に示した文書のこれ以上の説明は、これらエレメントがよく知られたＳＰＤＬエレメントであり説明は必要でないので、簡略化のため省略する。
【０１０６】
図３８乃至図６１は、図３７に示した文書例の処理時の長さ制御スタックを示す。図３８において、図３７の行２にあるＳＰＤＬ開始タグが図２９に示したフローチャートに従って処理される。図３９において、ピクチャー開始エレメントが処理され、スタックは図示のようになる。なお、図３８乃至図６１において、３つのハイフン（−−−）は何等かのバイトシーケンスを指す。ハイフンを含む正確なバイトシーケンスは、添付図面に含まれかつ明細書中で述べられたフローチャートを使って決定できるが、簡単にするため省略されている。図３９において、３つのハイフンは図３８のポインタにより指されたものと同じシーケンスの可能性がある。図４０乃至図４５は、図３７の文書例の処理がさらに進んだ時点のスタックを示す。図４６、及び文書例の処理中のスタックを示す他の図において、ｘ，ｙ，ｘｙ，ｙｙ等々の変数はバイト値を表わす。正確なバイト値は、フローチャートを追跡し図３７に示した各種パラメータの値を求めることによって決定できる。図４６において、Ｃurrent−ＴagはＰＲＯＬＯＧＵＥエレメントである。図５０は、外部宣言データ構造へのポインタを持つピクチャー／ページセットスタックデータ構造の例と、その外部宣言データ構造を示す。図５０において、１３０２はピクチャー／ページセットスタックを表わし、１３０４は外部宣言データ構造へのポインタを持つデータ構造を表わし、１３０６は外部宣言データ構造を表わす。ファイルがクリアテキストからバイナリへ変換中であるとしても、図５０に示すデータ構造は、単に１対１変換の実行ではなく、変換される文書の一部を実際に処理するためには必要である。これは構造タイプ（図５０において、１３０６は構造ＩＤ ＭＹＰＩＣＴのピクチャーである）を確認する必要があるからである。図５０は本発明の処理に用いられるデータ構造の一例に過ぎないもので、当然、図示されない他のものが用いられてもよいが、簡略にするため省略されている。
【０１０７】
図５１において、Ｃurrent−ＴagはＰＲＯＬＯＧＵＥである。図５２においては、Ｔag−Ｒead−ＩnはＳＴＵＰＰＲＣであり、Ｃurrent−ＴagはＳＴＵＰＰＲＣであり、Ｐrevious−ＴagはＰＲＯＬＯＧＵＥである。図５７において、Ｃurrent−ＴagはＰＩＣＴＢＤＹである。図５８において、Ｔag−Ｒead−ＩnはＳＴＲＣＴＩＤであり、外部宣言データのデータはＭＹＰＩＣＴ（不図示）である。これは次のＳＴＲＣＴＩＤを取り出すために利用される。Ｃurrent−ＴagはＳＴＲＣＴＩＤであり、Ｐrevious−ＴagはＰＩＣＴＢＤＹである。処理は図５９乃至図６１に示すデータ構造を利用して続く。
【０１０８】
【発明の効果】
以上の説明から理解されるように、本発明によれば、クリアテキスト・エンコーディングからバイナリ・エンコーディングへの変換における課題を解決し、クリアテキスト・エンコーディング文書からバイナリ・エンコーディング文書への変換、より特定的に言えば、クリアテキスト・エンコーディングＳＰＤＬ文書からバイナリ・エンコーディングＳＰＤＬ文書への変換を実行するための効果的な方法を実現することができる。
【図面の簡単な説明】
【図１】 バイナリ・エンコーディングに対する固定長フォーマット及び不定長フォーマットのネスティングの一例を示す図である。
【図２】 ＩＳＯ／ＩＥＣ ８８２５ によるエンコーディングの構造を示す図である。
【図３】 ＩＳＯ／ＩＥＣ ８８２５ によるアイデンティファイア・オクテットの構造を示す図である。
【図４】 ＳＰＤＬエレメント状態遷移ダイヤグラムの部分図である。
【図５】 バイナリエンコードＳＰＤＬ文書の見本の１６進表現を示す図である。
【図６】 図５に示したバイナリ文書のクリアテキスト表現を示す図である。
【図７】 図５に示したバイナリエレメントと図６に示したクリアテキストエレメントとの間の対応を示す図である。
【図８】 クリアテキスト文書をバイナリ文書へ変換するために利用される要素の概念図である。
【図９】 ＳＴＲＣＴＩＤエレメントのバイナリ表現のためにどのバイナリ表現を用いるかを決定するため、ＳＰＤＬ構造プロセッサがＳＴＲＣＴＩＤエレメントの処理に利用するデータ構造を示す図である。
【図１０】 バイナリ変換された文書中のアトリビュートの順序が適切であることを保証するために利用される一時的アトリビュートバッファデータ構造を示す図である。
【図１１】 各クリアテキストタグのための各種パラメータの格納に利用されるエレメントテーブルを示す図である。
【図１２】 サブエレメント連結リストデータ構造のフィールドを示す図である。
【図１３】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１４】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１５】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１６】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１７】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１８】 図１１に示したエレメントテーブルにより指示される、図１２に示した構造を持つ典型的なサブエレメント連結リストデータ構造を示す図である。
【図１９】 文書の各階層レベルの変換を管理するために利用される長さ制御スタックを示す図である。
【図２０】 変換プロセスのために用いられるフローチャートを示す図である。
【図２１】 コメントプロセッサに用いられるプロセスを示す図である。
【図２２】 トークンシーケンスプロセッサに用いられるプロセスのフローチャートを示す図である。
【図２３】 長さ制御スタックを初期化するために用いられる長さ制御スタックセットアップルーチンを示す図である。
【図２４】 長さ制御スタックを初期化するために用いられる長さ制御スタックセットアップルーチンを示す図である。
【図２５】 長さ制御スタックを初期化するために用いられる長さ制御スタックセットアップルーチンを示す図である。
【図２６】 終了タグルーチンのフローチャートを示す図である。
【図２７】 タグプロセッサにより利用されるフローチャートを示す図である。
【図２８】 ＤＯＣＴＹＰＥプロセッサにより利用されるフローチャートを示す図である。
【図２９】 ＳＰＤＬ開始ルーチンのフローチャートを示す図である。
【図３０】 ＳＰＤＬ終了ルーチンのフローチャートを示す図である。
【図３１】 開始タグルーチンのフローチャートを示す図である。
【図３２】 開始タグルーチンのフローチャートを示す図である。
【図３３】 開始タグルーチンのフローチャートを示す図である。
【図３４】 ＳＴＲＣＴＩＤプロセッサのフローチャートを示す図である。
【図３５】 アトリビュート終了ルーチンのプロセスを示す図である。
【図３６】 本発明の典型的なハードウエア構成を示す図である。
【図３７】 バイナリへ変換可能な典型的なクリアテキストＳＰＤＬ文書を示す図である。
【図３８】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図３９】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４０】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４１】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４２】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４３】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４４】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４５】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４６】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４７】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４８】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図４９】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５０】 外部宣言データ構造へのポインタを持つピクチャー／ページセットスタックデータ構造の例と、その外部宣言データ構造を示す図である。
【図５１】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５２】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５３】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５４】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５５】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５６】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５７】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５８】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図５９】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図６０】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【図６１】 図３７に示した文書がバイナリへ変換される時の長さ制御スタックを示す図である。
【符号の説明】
２０２ ＳＰＤＬクリアテキストデータ
２０４ パーサー
２０６ クリアテキスト−バイナリトランスレータ
２０８ ＳＰＤＬ構造プロセッサ
２１０ バイナリデータ
２２０ ピクチャー／ページセットスタック
２３４，２２６，２４２，２５０ 連結リストデータ構造
２７０ 一時的アトリビュートバッファデータ構造
２８０ エレメントテーブル
２８２ サブエレメント連結リストデータ構造
２８９ 追加ＡＳＮ．１タグ
３１０ サブエレメント連結リストデータ構造
320，330 サブエレメント連結リストデータ構造
340，350 サブエレメント連結リストデータ構造
360，370，380，382，384 サブエレメント連結リストデータ構造
368，378，381，383，385 追加ＡＳＮ．１タグ
386，388，390，392，394，396 サブエレメント連結リストデータ構造
387，389，391，393，394，396 追加ＡＳＮ．１タグ
398，400，402，404，406，408 サブエレメント連結リストデータ構造
399，401，403，405，407，409 追加ＡＳＮ．１タグ
４２０ 長さ制御スタック
４２２ バッファ
１２００ ワークステーション
１２０２ ＣＰＵ
１２０４ ＲＡＭ
１２０６ ＲＯＭ
１２０８ 入力インターフェイス
１２１０ キーボード
１２１４ マウス
１２１６ 印刷エンジンインターフェイス
１２１８ 印刷エンジン
１２２０ システムバス
１２２２ ディスクコントローラ
１２２４ ハードディスク
１２２６ フロッピードライブ
１２２８ 通信インターフェイス
１２３０ ネットワーク
１２３２ Ｉ／Ｏコントローラ
１２３４ プリンタ
１２３６ ハードディスク
１２３８ ディスプレイコントローラ
１２４０ ＣＲＴ
Claims (6)
- データ処理装置により、クリアテキストエンコードの標準ページ記述言語文書であるＳＰＤＬクリアテキストデータをバイナリエンコードの標準ページ記述言語であるバイナリデータに変換する文書フォーマット変換方法であって、
データ処理装置は、プロセスを実行するＣＰＵ、プロセスの実行中に生成されるデータ及び処理に利用されるデータを一時的に格納するメモリを有し、
前記ＣＰＵが、
ＳＰＤＬクリアテキストデータをメモリに入力するステップと、
入力されたＳＰＤＬクリアテキストデータのエレメントのタグが開始タグである場合は、そのタグのバイナリエンコードの記述に追加の部分が存在するか否かを判定するステップと、
追加の部分が存在すると判定された場合に、スタックのトップエントリーに記憶されているバイナリエンコードの記述が追加の部分であるか否かを判定するステップと、
スタックのトップエントリーに記憶されているバイナリエンコードの記述が追加の部分であると判定された場合に、その追加の部分が、入力されたエレメントのタグにおける追加の部分と同じであるか否か判定するステップと、
同じでないと判定された場合に、スタックのトップエントリーに記憶されているタグのバイナリエンコードの記述に基づいて、バイナリデータを作成してトップエントリーをポップし、次に、入力されたエレメントのタグについて、追加の部分を入れたエントリーをスタックに追加し、さらにバイナリエンコードの記述で常に出現する必要がある部分を入れたエントリーをスタックに追加するステップと、
同じであると判定された場合に、入力されたタグに対するバイナリエンコードの記述で常に出現する必要がある部分を入れたエントリーのみをスタックに追加するステップと、
入力されたＳＰＤＬクリアテキストデータのエレメントのタグが終了タグである場合は、
スタックのトップエントリーに記憶されているタグのバイナリエンコードの記述に基づいて、バイナリデータを作成してトップエントリーをポップするステップと、
を実行することを特徴とする文書フォーマット変換方法。 - 請求項１記載の文書フォーマット変換方法において、スタックのトップエントリーに記憶されているバイナリエンコードの記述が追加の部分であるか否かを判定するステップでは、該追加の部分を含むか表示するフラグを調べることを特徴とする文書フォーマット変換方法。
- 請求項１記載の文書フォーマット変換方法において、少なくとも２つの異なるフィールドを持つデータ構造によって、前記変換のステップのそれぞれにより、クリアテキストエンコードで記述されたタグをバイナリコードの記述へ変換するために用いられる変換情報を格納し、該少なくとも２つの異なるフィールドの中の１つが、該対応エレメントのバイナリエンコード記述中に常に出現する必要がある部分を格納するために用いられ、該少なくとも２つの異なるフィールドのもう１つがバイナリコード記述中の追加の部分を格納するために用いられる、ことを特徴とする文書フォーマット変換方法。
- 請求項３記載の文書フォーマット変換方法において、前記データ構造は連結リストデータ構造であることを特徴とするフォーマット変換方法。
- 請求項１記載の文書フォーマット変換方法において、入力されたエレメントのタグが複数のバイナリエンコード記述を持つ場合、スタックのトップエントリーのエレメントに対する正しいサブエレメントである１つを選ぶことにより、入力されたエレメントのタグを、その該複数のバイナリエンコード記述中の１つへ変換することを特徴とする文書フォーマット変換方法。
- 請求項５記載の文書フォーマット変換方法において、スタックのトップエントリーのエレメントに対するサブエレメント連結リストをトレースし、該サブエレメント連結リストにおいて、入力されたエレメントのタグに関する構造タイプの後に出現するクリアテキストエンコード記述を選ぶことによって複数のバイナリエンコード記述中の該１つを選ぶことを特徴とする文書フォーマット変換方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/261184 | 1994-06-13 | ||
| US08/261,184 US5504891A (en) | 1991-10-17 | 1994-06-13 | Method and apparatus for format conversion of a hierarchically structured page description language document |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH07334496A JPH07334496A (ja) | 1995-12-22 |
| JP4098838B2 true JP4098838B2 (ja) | 2008-06-11 |
Family
ID=22992241
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP09471895A Expired - Fee Related JP4098838B2 (ja) | 1994-06-13 | 1995-04-20 | 文書フォーマット変換方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4098838B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7325396B2 (ja) * | 2020-12-25 | 2023-08-14 | 株式会社日立製作所 | データファイル暗号化送受信システム及びデータファイル暗号化送受信方法 |
-
1995
- 1995-04-20 JP JP09471895A patent/JP4098838B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH07334496A (ja) | 1995-12-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5504891A (en) | Method and apparatus for format conversion of a hierarchically structured page description language document | |
| US5506985A (en) | Method and apparatus for format conversion of a hierarchically structured page description language document | |
| EP0349457B1 (en) | Dynamic redefinition of a shell structure | |
| US6859810B2 (en) | Declarative specification and engine for non-isomorphic data mapping | |
| US7873663B2 (en) | Methods and apparatus for converting a representation of XML and other markup language data to a data structure format | |
| US7188115B2 (en) | Processing fixed-format data in a unicode environment | |
| Lam et al. | XML document parsing: Operational and performance characteristics | |
| US7158990B1 (en) | Methods and apparatus for data conversion | |
| US7627566B2 (en) | Encoding insignificant whitespace of XML data | |
| US20050144556A1 (en) | XML schema token extension for XML document compression | |
| EP0268069B1 (en) | Method of forming a message file in a computer | |
| US20070016554A1 (en) | Hardware accelerated validating parser | |
| US20020029229A1 (en) | Systems and methods for data compression | |
| EP1684191A2 (en) | Method and system for binary serialization of documents | |
| US20070112810A1 (en) | Method for compressing markup languages files, by replacing a long word with a shorter word | |
| US20060271850A1 (en) | Method and apparatus for transforming a printer into an XML printer | |
| EP0520708B1 (en) | Method and apparatus for converting high level form abstract syntaxes into an intermediate form | |
| US5487165A (en) | Standard page description language cleartext structure generator | |
| JP4098838B2 (ja) | 文書フォーマット変換方法 | |
| RU2294012C2 (ru) | Структура данных и способы преобразования потока битов в электронный документ и формирования потока битов из электронного документа на ее основе | |
| JP3560258B2 (ja) | フォーマット変換装置 | |
| US7596630B2 (en) | Method, system and computer program product for parsing an encoding | |
| WO2008107802A2 (en) | Method and device for processing documents on the basis of enriched schemas and corresponding decoding method and device | |
| AU2003277250A1 (en) | Hardware accelerated validating parser | |
| CN117041391A (zh) | 一种以太网通讯报文协议的通用解析处理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20041109 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050111 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050301 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20050902 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080212 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080314 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110321 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120321 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |