JPH07271551A - フォーマット変換装置 - Google Patents

Abstract

(57)【要約】 【目的】 文書をバイナリフォーマットからクリアテキ
ストフォーマットへ変換する。 【構成】 バイナリファイル内の各ＡＳＮ．１タグのク
リアテキストネームを決定する。各エレメントの下に出
現可能なサブエレメントは、エレメントテーブルにより
参照されるサブエレメントリンクリストデータ構造に格
納されている。バイナリエンコーディングは不定長フォ
ーマットであるか固定長フォーマットであり、バイナリ
ファイルのレングスを管理するためにエレメントスタッ
クが用いられる。バイナリエレメントが変換された後、
このバイナリエレメントのクリアテキスト表現に関する
情報は、前のエレメントと次のエレメントを参照するダ
ブルリンクリストデータ構造（７００〜７４０）に格納
される。ファイル全体が変換された後、ダブルリンクリ
ストデータ構造に記憶されている情報は出力ファイルに
書き出される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は文書のフォーマット変換
に係り、特にバイナリ・エンコードの文書（binary enc
oded document）からクリアテキスト・エンコードの文
書（cleartextencoded document）への変換に関する。
本発明はまたさらに、バイナリ・エンコードの標準ペー
ジ記述言語文書（standard Page Description Languag
edocument）のクリアテキスト・エンコードの標準ペー
ジ記述言語文書）への変換に関する。

【０００２】なお、本出願は、米国特許出願第０８／１
４７，６０３号（１９９３年１１月４日受理，"STANDAR
D PAGE DESCRIPTION LANGUAGE CLEARTEXT STRUCTUREGEN
ERATOR"）、米国特許出願第０８／０６６，３８３号
（１９９３年５月２１日受理，" METHOD AND SYSTEM FO
R PROCESSING MIXED BINARY LENGTH ENCODINGSCONTAINI
NG DEFINITE AND INDEFINITE LENGTH FORMATS "）及び
米国特許出願第０８／００６，４１６号（１９９３年１
月１９日，" METHOD AND SYSTEM TORECOGNIZE ENCODING
TYPE IN DOCUMENT PROCESSING LANGUAGE"）の一部継続
出願であり、上記３件の米国特許出願はそれぞれ米国特
許出願第０７／９３１，８０８号（１９９２年８月１１
日受理，" A Method And System to HandleDiction
ary Generation and Context DEclaration in a Docume
nt ProcessingLanguage"）の一部継続出願であり、当該
米国特許出願第０７／９３１，８０８号は米国特許出願
第０７／８７６，６０１（１９９２年４月３０日受
理，" Method and Apparatus to Manage Picture and P
ageset for DocumentProcessing " 、米国特許出願第０
７／８７６，２５１号（１９９２年４月３０日受理，"
Method and System to handle Inclusion of External
Files intoa Document Processing Language "）及び米
国特許出願第０７／７７８，５７８号（１９９１年１０
月１７日受理，" System and Method for Document
Processing"）の一部継続出願であり、上記各特許出願
は引用により本明細書に組み込まれる。

【０００３】

【従来の技術】一つの標準化ページ記述言語（ＳＰＤ
Ｌ）が提案され、国際標準化機構（ＩＳＯ）で国際規格
として開発中である。この提案は、本願発明者の一人も
その関与者であるが、現在、ＩＳＯの１セクションに草
案として提出されている。この草案はISO/IEC DIS 1018
0 ”Information Processing TextーCommunication−Sta
ndard Page Description Language”として知られ、ニ
ューヨークの米国規格協会（ＡＮＳＩ）で入手可能であ
るが、ここに引用することによっ本明細書に組み込まれ
る。

【０００４】標準ページ記述言語（ＳＰＤＬ）は階層的
に構造化されたページ記述言語である。この構造化され
た階層によれば、文書の一部分の印刷をする場合に、当
該部分に影響する可能性のあるフォーマット用コマンド
（formatting command）を文書全体にわたって調べる必
要がなくなる。所望の部分を印刷するのに、その刷した
い部分より階層が上の文書の部分しか処理する必要がな
い。

【０００５】ＳＰＤＬのもう一つの利点は、ＳＰＤＬが
ＩＳＯ 8879:1986 に定義された標準一般化マークアッ
プ言語（Standard Generalized Markup Language，
ＳＧＭＬ）に準拠していることである。このことによ
り、文書構造を記述し包括的に結び付けることが可能に
なる。複数のファイルは、ＳＧＭＬで結びつけられたな
らば、変換ユーティリティを用いる事なく、かつ構造フ
ォーマットを損なうことなく、あるプラットフォームか
ら他のプラットフォームへ継ぎ目なく移ることができ
る。

【０００６】ＳＰＤＬは、ＡＳＮ．１に述べられている
ベーシック・エンコーディング規則（Basic Encoding
Rules）に準拠している。ＡＳＮ．１に関する完全な
説明は、Douglas Steedman著”ＡＳＮ．１，The Tuto
rial and Reference”（１９９０年）に見られるが、
この文献は引用により本明細書に組み込まれる。

【０００７】クリアテキスト（cleartext）言語は、人
間が読むことのできるコンピュータ言語の一種である。
非クリアテキスト言語の一例をあげるならば、文書のバ
イナリ・エンコーディング（binary encoding）であろ
う。２進もしくは１６進表現の文書を見ても、人間には
文書内容を容易には理解できないからである。バイナリ
・エンコードされた文書の一つの主要な利点として、２
進で表現された文書は同等のクリアテキスト形式の文書
に比べて必要とする記憶スペースが非常に少ない事があ
る。このことがバイナリ文書の記憶スペースの減少及び
伝送時間の高速化を可能にする。しかしクリアテキスト
・エンコードの文書に比べ、特殊なソフトウエアを用い
ないとバイナリ・エンコードの文書の編集及び理解が難
しい。

【０００８】したがって、前述のように文書のクリアテ
キスト・エンコーディングにもバイナリ・エンコーディ
ングにも長所と短所があるので、文書を一方のフォーマ
ットから他方のフォーマットへ変換したいことがあろ
う。

【０００９】

【発明が解決しようとする課題】本発明の一つの目的
は、バイナリ・エンコードの文書をクリアテキスト・エ
ンコードの文書へ変換する手段を提供することである。

【００１０】本発明のもう一つの目的は、バイナリ・エ
ンコードの標準ページ記述言語文書を等価なクリアテキ
スト・エンコードの標準ページ記述言語文書へ変換する
手段を提供することである。

【００１１】バイナリＳＰＤＬ文書で要求されるフォー
マットのゆえに、バイナリ・エンコード文書をクリアテ
キスト・エンコード文書に変換するために単純なルック
アップ（look-up）プロシージャを実行することはでき
ない。様々なバイナリ・シンボル（binary symbol）の
表わす内容は、ＳＰＤＬ文書中のバイナリ・シンボルの
ロケーションに依存して決まる。

【００１２】本発明が扱わなければならないもう一つの
課題は、バイナリ・エンコードされたプロセスそれぞれ
の長さを管理することである。ＳＰＤＬは階層的に構造
化されたページ記述言語であり、各階層レベルの始まり
は、該レベルが固定長フォーマットまたは不定長フォー
マットのいずれでエンコードされるかを示し、また、固
定長バイナリ・エンコーディングがある時には、エンコ
ーディングの長さを示す。

【００１３】本発明が扱う別の課題は、バイナリ・エン
コーディングにおける特定エレメントの順序がクリアテ
キスト・エンコーディングでは変更されなければならな
いという事である。したがってクリアテキストＳＰＤＬ
フォーマットにおいて要求されるエンコーディング順序
を知る必要がある。

【００１４】

【課題を解決するための手段】前記目的もしくは課題を
解決するための手段を、やや具体的に説明すれば、本発
明は、バイナリからクリアテキストへの変換を行なうた
めに、まず最初に、アプリケーション・テーブル（appl
ication table）よりＡＳＮ.１タグを検索し、このバイ
ナリ・タグ（binary tag）のクリアテキスト名を決定す
る。クリアテキスト名が決まったならば、当該エレメン
トに関するそれ以上の情報をエレメント・テーブル（el
ement table）より検索できる。エレメント・テーブル
のエレメントはサブエレメント（sub-element）を持つ
ことができ、サブエレメントはサブエレメント・リンク
リスト（sub-element linked list）を指すエレメント
・テーブル中のポインタによって参照される。

【００１５】エレメントに関し必要な情報が得られた
後、変換プロセスで用いられる情報の管理のための各種
フィールドを持つエレメント・スタックに、一つのエン
トリーがプッシュされる。このエレメント・スタック
は、バイナリ・コーディングの固定長フォーマット及び
不定長フォーマットの処理に非常に有益である。

【００１６】バイナリ・エレメントが変換されている時
に、アトリビュート（attribute）値がアトリビュート
・バッファに格納される。出力ファイルの生成前におい
て、ファイルが変換されている時に変換された各クリア
テキスト行がダブル・リンクリストデータ構造（double
linked list data structure）に書き込まれる。ファ
イル全体が変換されてダブル・リンクリストデータ構造
に書き込まれると、ダブル・リンクリストデータ構造の
情報が出力ファイルへ書き出される。

【００１７】

【作用】ダブル・リンクリストデータ構造は、不適切な
（out of order）アトリビュートの処理のために有効に
利用される。エレメントはアトリビュートとサブエレメ
ントを含むことができる。通常、クリアテキストＳＰＤ
Ｌの場合、アトリビュートはエレメントの直後、及び、
あらゆるサブエレメントの出現前に、出現しなければな
らない。しかし、バイナリＳＰＤＬエンコーディングに
おいては、サブエレメントがアトリビュートの前に出現
することがある。

【００１８】本発明は、アトリビュート・バッファとダ
ブル・リンクリストデータ構造を用いて、上述の不適切
なアトリビュートの問題を解決する。本発明において、
エレメントより階層的に下に現われるオブジェクトはサ
ブエレメントと総称される。あるエレメントに対するサ
ブエレメントは、そのエレメントのアトリビュートであ
るか、あるいは実際のサブエレメントである。アトリビ
ュートを適切ならしめるためには、それらアトリビュー
トはエレメントの直後に出現するべきである。アトリビ
ュートの全てが出現する以前にエレメントの後にサブエ
レメントが出現したならば、その後のアトリビュートは
不適切なアトリビュートであると考えられる。ダブル・
リンクリストデータ構造はエレメントのアトリビュート
情報を格納するためのエントリーを有する。あるエレメ
ントの下に、アトリビュートの全部が処理される前にノ
ンアトリビュート（non-attribute）・サブエレメント
が出現した場合には、親（parent）エレメントのダブル
・リンクリストデータ構造によって新しいダブル・リン
クリストデータ構造が参照される。親エレメントのサブ
エレメントの処理後に、不適切なアトリビュートが出現
することになる。最も最近に生成されたダブル・リンク
リストデータ構造より、親エレメントのダブル・リンク
リストデータ構造に到達するまで、ダブル・リンクリス
トデータ構造が逆向きにトレースされる。そして、その
アトリビュート・サブエレメントのアトリビュート情報
が親エレメントのダブル・リンクリストデータ構造のア
トリビュート・エントリーに書き込まれる。このように
して、不適切アトリビュートが効率的に処理される。

【００１９】

【実施例】以下、添付図面を参照して本発明の一実施例
を説明するが、複数の図面にわたって同一の参照数字は
同一部または対応部を示す。

【００２０】添付図面中の図１を参照するに、バイナリ
・エンコード文書に関する固定長及び不定長フォーマッ
トのネスティングの一例が示されている。図１は、処理
されるべき一つのデータストリームもしくは文書データ
ストリームを示すと考えることができる。行１〜行１６
及び行１７〜行１９は、最高階層レベルの２つのコーデ
ィングであるが、行１〜行１６内にはネストされたコー
ディングがある。行１〜行１６のエンコーディングのコ
ンテント（content）は４００バイトの固定長である。
これら４００バイト内で、まず行４〜行１３に一つの不
定長構造がある。この行４〜行１３の不定長コンテント
は２４８バイト及び４０バイトの固定長コーディングで
ある。行４〜行１３にある４００バイトのコンテントか
らなる不定長エンコーディングに加えて、１００バイト
のコンテントを含む行１４〜行１６の固定長エンコーデ
ィングがある。図１の行１７〜１９は２５０バイトの長
さの固定長エンコーディングを含む。

【００２１】”固定長フォーマットと不定長フォーマッ
トのネスティング（nesting）”なるタームは、ある不
定長エンコーディングが、そのコンテントとして、一つ
の不定長エンコーディングと一つの固定長エンコーディ
ング、すなわち、これら二つのエンコーディングの組合
せを持つことができる、ということを意味する。このこ
とは、その固定長エンコーディングが、その不定長エン
コーディングが終わる前に始まることを意味する。上記
タームは不定長エンコーディングを含んだ固定長エンコ
ーディングにも同様に当てはまる。すなわち、不定長エ
ンコーディングは固定長エンコーディングが終わる前に
始まることができる。さらに、一つのエンコーディング
内に、任意数の任意タイプのエンコーディングをネスト
可能である。

【００２２】図１に示したようなエンコーディングが処
理されている時に、ネストされた固定長エンコーディン
グ及び不定長エンコーディングのハンドリングに関して
一つの問題が生じる。図１に示した例は単純なケースで
ある。固定長・不定長フォーマットのネスティングがず
っと深くなることがあり得る。したがって、処理システ
ムは、多くの不定長フォーマット及び固定長フォーマッ
トの階層レベルを管理せねばならないかもしれない。

【００２３】不定長エンコーディングの終わりを確認す
るには、ＡＳＮ．１エンコーディングで使用される行１
３の０００Ｈのような、不定長エンコーディングの終わ
りフラグもしくはマーカーを捜すだけでは不十分であ
る。というのは、行９及び行１２にあるコンテントが０
００Ｈをデータ、イメージデータとして含むことがある
からである。したがって、本発明は、不定長エンコーデ
ィングの終わり０００Ｈを、ネストされた固定長エンコ
ーディングの処理が済んだ後に捜す。不定長エンコーデ
ィングの終わりは、固定長フォーマットのネストされた
ルーチンの後に来る筈であるからである。

【００２４】さて、ＡＳＮ．１に要求されるエンコーデ
ィングであるが、図２はISO/IEC8824に定義されたベー
シック・エンコーディング規則に従ったバイナリ・エン
コーディングの構造を示している。このエンコーディン
グは１個以上のアイデンティファイア・オクテット（id
entifier octet）から始まり、次に１個以上のレングス
・オクテット（length octet）が来て、これにコンテン
ト・オクテット（contents octet）が続く。

【００２５】ISO/IEC 8824により定義されたアイデンテ
ィファイア・オクテットの構造が図３に示されている。
このアイディンティファイア・オクテットの初めの２ビ
ットはエンコーディングのクラスを表わす。図３に示さ
れたビット８及びビット７で定義される可能なエンコー
ディング・クラスは、ユニバーサル、アプリケーショ
ン、コンテント・スペシフィック（content-specifi
c）、及びプライベートの４クラスである。ＡＳＮ．１
によるエンコーディングの完全な説明は、ISO/IEC 8824
及びISO/IEC 8825（いずれも引用によって本明細書に組
み込まれる）に見られる。しかし、本発明の作用を理解
するのにエンコーディングの様々なクラスについての理
解は必要ではないので、説明の簡略のため、これ以上の
詳細については述べない。

【００２６】図３に示したビット６は、エンコーディン
グがプリミティブ（primitive）であるか複合（constru
cted）であるかを決定する。プリミティブとは他のエン
コーディングが当該エンコーディング内にネストされて
いないことを意味し、複合とは他のエンコーディングが
当該エンコーディング内にネストされていることを意味
する。図３に示されているビット５〜１はタグの番号に
関するものである。タグの番号が３１を超えるときに
は、ビット５〜１は同番号を表現するには足りないの
で、後続のアイデンティファィア・オクテットでタグの
番号をエンコードする。様々なタグ番号の完全な理解
は、本発明の作用を理解するためには必要ではないので
簡略のため省略する。

【００２７】アイデンティファイア・オクテット及びレ
ングス・オクテットはプリアンブル（preamble）情報と
考えることができ、コンテント・オクテットはコンテン
ト情報と考えることができる。アイデンティファイア情
報がテキストフォーマットへ変換されたときに得られる
テキスト情報は、クリアテキスト開始タグにコンテント
情報のクリアテキスト表現が続いたもので、必要なら
ば、もしくは要求されるならば、その後にクリアテキス
ト終了タグが続く。

【００２８】当業者にとって以上の説明でバイナリＳＰ
ＤＬエンコーディングの基本を理解するのに十分である
と考えられる。しかし、バイナリ・エンコーディングの
処理に関するより詳細かつ完全な説明を、係属中の米国
特許出願第０８／０６６，３８３号（”METHOD AND SYS
TEM FOR PROCESSING MIXED BINARY LENGTH ENCODINGCON
TAINING DEFINITE AND INDEFINITE LENGTH FORMATS”）
に見ることができる。本出願の主要な関心事及び処理は
ファイルをバイナリ表現からクリアテキスト表現へ変換
することであるが、上記関連出願に述べられている処理
は主としてプリンタ、ＣＲＴ等による文書の出力（pres
entation）に関係するものである。

【００２９】本発明は各種ＳＰＤＬエレメントの情報を
管理するためにエレメント・テーブルとサブエレメント
・リンクリストを用いる。ＳＰＤＬは階層的に構造化さ
れたページ記述言語であるので、エレメント・テーブル
及びサブエレメント・リンクリストの情報を生成するに
はＳＰＤＬ内の階層構造を決定する必要があった。

【００３０】ＳＰＤＬの階層の秩序を決定するため、本
願発明者は、規格草案に含まれているＳＰＤＬエレメン
トの記述を使用し、図４に示すようなＳＰＤＬエレメン
ト状態遷移ダイヤグラムを作成した。図４は、ＳＰＤＬ
構造エレメントをツリー構造を用いて図示しており、ま
た、一つのエレメントから出て同じエレメントに戻るラ
ベル付けされたアトリビュート用円弧矢印を示すことに
より、様々なＳＰＤＬエレメントに対するアトリビュー
トを図示している。 この状態遷移ダイヤグラムから、
本願発明者は本発明に用いられるエレメント・テーブル
とサブエレメント・リンクリストを生成することができ
た。

【００３１】状態遷移ダイヤグラムの最初のエレメント
はＳＰＤＬ１５２である。ＳＰＤＬエレメントの下に出
現できる２つの可能なエレメントがある。すなわち、文
書エレメント１５４とリソース定義（resource definit
ion）エレメント１５６である。このリソース定義エレ
メント１５６はリソース・アトリビュート、ＳＰＤＬＩ
Ｄアトリビュート及びファンクション（function）アト
リビュートというアトリビュートを持つとして示されて
いる。アトリビュートは固定値を持つことも、ユーザに
よって入力された値を持つこともある。

【００３２】図４において、特定の階層構造における終
端エレメントつまり最も下のエレメントはアスタリスク
が付けられており、また、前に定義済みのエレメントは
プラス記号が付けられている。特定の階層構造の最低レ
ベルには終端エレメントが存在可能であるが、他のエレ
メントは存在できない。図４に示したＳＰＤＬエレメン
ト状態遷移ダイヤグラムは完全ではなく、簡略化のため
にＳＰＤＬ構造エレメントの一部を省略している。例え
ば、リソース・スペシフィケーション（specificatio
n）１６４、外部宣言１７２、情報宣言１７４、リソー
ス定義１７６、リソース宣言１７８、ＤＰＩ宣言１８
０、コンテキスト（cpntext）宣言１８２、セットアッ
プ・プロシージャ（set-up procedures）１８６の下に
来る構造エレメントがある。

【００３３】文書構造エレメント１５４の下にページセ
ット（pageset）エレメント１５８とピクチャー（pictu
re）エレメント１６０がある。ページセット１５８の下
にページセット・ボディ（body）１６６及びプロローグ
（prologue）１７２がある。図４に示されるように、ピ
クチャー・エレメント１６０はページセット・ボディ１
６６の下に出現することも可能である。ピクチャー・エ
レメント１６０は、コンテント・タイプのアトリビュー
トとＳＰＤＬ ＩＤとを有する。ピクチャーエレメント
１６０の下に出現可能なＳＰＤＬエレメントはプロロー
グ１７２とピクチャー・ボディ１６８である。トークン
・シーケンス（token sequence）１７０がピクチャー・
ボディ１６８の下に出現可能である。プロローグ１７２
の下に出現する辞書ジェネレータ（dictionary generat
or）１８４はその下に、サイズのアトリビュートを持つ
辞書ジェネレータ・エレメント１８８が出現可能であ
る。辞書１８８の下に出現可能なＳＰＤＬエレメントは
辞書ＩＤ１９０、ネーム（name）１９４及びトークン・
シーケンス１９２である。

【００３４】図５は、典型的なバイナリＳＰＤＬ文書を
１６進表現で示している。図５に示された文書と等価な
クリアテキスト文書が図６に示されている。本発明が用
いられた場合、図５に示した文書を入力して図６に示し
た形式へ変換させることができる。図５及び図６に示し
た文書に対する本発明の作用の説明を行なった後のほう
が、図５及び図６の詳細を理解しやすいであろう。

【００３５】図７は、図５に示された文書が図６に示さ
れた文書にどのように対応するかを説明するものであ
る。図７より分かるように、６１はエレメントたるペー
ジセットを表わしている。６１の後の５９は、このペー
ジセットの長さ（length）を表わしている。このページ
セット内にＳＰＤＬ ＩＤがＡＳＮ．１タグ０６で表わ
されている。このＳＰＤＬ ＩＤの長さは４である。実
際のＳＰＤＬ ＩＤである”ISO/IED 10180//SPDL”
は”２８ ＣＦ ４４ ００”によって表わされてい
る。

【００３６】次に、図７において、ＡＳＮ．１タグ４４
はコメントに対応することが分かる。このコメントの長
さは１Ｆである。このコメントの内容は”SPDL ID=Publ
icObject ID value ”である。次に、Ａ１はページセッ
ト・ボディとも呼ばれるところのpsbodyを表わすことが
分かる。図７の残りの部分も同様に理解することができ
る。したがって、簡略化のために図７における対応関係
の完全な説明は省略する。

【００３７】図８は本発明で使用されるアプリケーショ
ン・テーブルを示す。このアプリケーション・テーブル
はＡＳＮ．１タグ（アイデンティファイア・オクテッ
ト）のバイト値と、それに対応したクリアテキストのア
プリケーション・エレメントのネーム（name）を記憶し
ている。例えば、ＡＳＮ．１タグの４０Ｈはクリアテキ
スト・エレメント”name”に対応する。また、ＡＳＮ．
１タグの６１Ｈ及び６２Ｈは、ページセット（pagese
t）及びピクチャー（picture）なるエレメントにそれぞ
れ対応することが分かる。当然、本発明で使用される完
全なアプリケーション・テーブルは、ＳＰＤＬ構造エレ
メントそれぞれのための既知のＡＳＮ．１タグと既知の
エレメント・ネームを記憶することになる。ＡＳＮ．１
タグは公知文献で容易に知ることができるので、ＡＳ
Ｎ．１タグそれぞれの完全なリストは提示しない。

【００３８】図９は、本発明で使用されるＳＰＤＬエレ
メント・テーブルを示す。このエレメント・テーブルの
最初のカラムはエレメント・ネームもしくは同エレメン
トのクリアテキスト・タグである。次の２つのカラム
は、開始タグ及び終了タグが省略可能であるか必要とさ
れるかを示す。ハイフンはタグが必要であることを示
し、０はタグがオプショナルであることを示す。なお、
ここに開示される本発明の実施例においては、各エレメ
ントの開始タグ及び終了タグが常に用いられる。勿論、
エレメント・テーブルの開始タグ・エントリー及び終了
タグ・エントリーを使用し、それらがオプショナルの時
にタグを省略することも可能である。

【００３９】エレメント・テーブルの４番目のカラム
は、エレメントがプリミティブであるか複合（construc
ted）であるかを示す。プリミティブはコンテント中に
他のエンコーディングがネストされていないことを意味
し、複合はコンテント中に他のエンコーディングがネス
トされていることを意味する。本発明は４番目のカラム
を格別に参照することはないが、このプリミティブ／複
合情報は他の関連発明で使用されるかのしれないので当
該エレメント・テーブルに含まれている。

【００４０】エレメント・テーブルの５番目のカラム
は、エレメント宣言を記憶する。このエレメント宣言
は、エレメントの特性の記述である。より具体的には、
エレメント宣言は、エレメントのエレメント・ネームに
ついての特性及び従属構造エレメント（それがあるなら
ば）の扱いについての特性に関係する。例えば、DOCTYP
E、NO DECLARATION、OCTET STRING、PRINTABLE STRING
は第１のタイプのエレメント宣言である。CHOICE、SE
QUENCE、SEQUENCE OF CHOICE は第２のタイプのエレメ
ント宣言である。DOCTYPE 宣言は特殊タイプの宣言で、
DOCTYPE構造エレメントのためにだけ使用される。CHOIC
E 宣言はエレメント下のサブエレメントの任意の一つを
ユーザが選択できることを示す。SEQUENCE 宣言はエレ
メントの下に出現するサブエレメントは特定の順番で出
現しなければならず、この順番は変更できないことを示
す。

【００４１】SEQUENCE OF CHOICE 宣言はCHOICE 宣言を
繰り返すことにより、２つ以上の従属構造エレメントを
選択させる。NO DECLARATION 宣言はエレメントが従属
構造エレメントを１つしか持たないことを意味する。

【００４２】OCTET STRING 宣言は、エレメントが８ビ
ット・バイトの文字ストリングであることを示す。PRIN
TABLE STRING 宣言は、エレメントが印刷可能（printab
le）ストリングであることを示す。

【００４３】宣言が暗黙的である時、宣言は下に出現す
るタグに基づいて決定されるから、明示的に記述される
必要がないことを意味する。この特徴の詳細は、ＡＳ
Ｎ．１等のＳＰＤＬで用いられるエンキコーディングに
関する公知文献で知ることができるので、簡略化のため
割愛する。

【００４４】他のＳＰＤＬ文書タイプで他の宣言が用い
られるが、これら宣言の詳細は説明の簡略化のため省略
する。それらの詳細は、ＳＰＤＬに関する公知文献で知
ることができる。本発明は、バイナリＳＰＤＬ文書のシ
ンタックスがＳＰＤＬエンコーディング条件に違反しな
いようにするためにエレメント宣言を使用することがで
きる。

【００４５】エレメント・テーブルの６番目のカラム
は、エレメントのアトリビュート数を示す。アトリビュ
ートはエレメントの様々な特徴を記述するが、エレメン
トに対する固有のアトリビュートはサブエレメント・リ
ンクリスト中に見つかる。

【００４６】エレメント・テーブルの７番目のカラム
は、エレメントのサブエレメント数を示す。このサブエ
レメント数はエレメントの下に出現可能な様々なサブエ
レメントの個数を示す。エレメント・テーブルの最後の
カラムは、エレメントの下に出現可能なサブエレメント
に関する情報を記憶しているサブエレメント・リンクリ
ストデータ構造へのポインタである。

【００４７】図１０は、図９に示したエレメント・テー
ブルのいずれかのポインタに対応するポインタ２０２に
より指されるサブエレメント・リンクリストデータ構造
２００を示す。このサブエレメント・リンクリストデー
タ構造２００の最初のエントリー２０４はＡＳＮ．１タ
グであり、このタグはサブエレメントのバイナリ表現で
ある。サブエレメント・リンクリストデータ構造２００
のエントリー２０６はサブエレメント宣言で、エレメン
ト・テーブルに関して述べたエレメント宣言と同様の宣
言情報を記憶する。

【００４８】サブエレメント・リンクリストデータ構造
２００のエントリー２０８は、ＡＳＮ．１タグ２０４に
対応したクリアテキスト・サブエレメントネームを記憶
する。

【００４９】エントリー２１０はサブエレメント・タイ
プを記憶する。可能なサブエレメントのタイプは、アト
リビュート、オプショナル、デフォルト、またはターミ
ネーティング（terminating）であり、これら４つのタ
イプの組合せも許される。本発明を実施する場合、サブ
エレメントのタイプは４タイプなら４ビットを用いて表
現される。先に述べたサブエレメントの４タイプのいず
れにも合致しないときには、サブエレメント・タイプを
空白にすることも可能である。

【００５０】フィールド２１２はサブエレメントのシー
ケンス番号を記憶しており、このシーケンス番号はサブ
エレメント・リンクリストデータ構造の番号である。例
えば、あるエレメントに対する最初のサブエレメントは
シーケンス番号１を有し、あるサブエレメント（２番目
のサブエレメント）の最初のリンクリストデータ構造に
より指されるリンクリストデータ構造はシーケンス番号
２を有する。

【００５１】サブエレメント・リンクリストデータ構造
の最後のフィールド２１４は、次のサブエレメント・リ
ンクリストデータ構造へのポインタである。あるエレメ
ントが、その下に出現する多数の様々なサブエレメント
を階層構造中に持っている場合、各サブエレメントはそ
れ自体のリンクリストデータ構造を有する。これらのサ
ブエレメント・リンクリストデータ構造は、あるエレメ
ントの後続サブエレメント・リンクリストデータ構造を
指すポインタ２１４によって相互にリンクされる。最後
のサブエレメント・リンクリストデータ構造はヌルを指
す。

【００５２】図１１は、ページセットエレメントのため
のサブエレメント・リンクリストデータ構造２３０，２
４０，２５０を示す。最初のサブエレメントのためのＡ
ＳＮ．１タグは０６で、これは SPDL ID エレメントに
対応する。 SPDL ID に対しては宣言がないので、 SPDL
ID はアトリビュートである。この SPDL ID は、最初
のサブエレメントであるので、２番目のサブエレメント
であるプロローグを指す。このプロローグ・サブエレメ
ント・リンクリストデータ構造は、 PSBODY サブエレメ
ント・リンクリストデータ構造２５０を指す。

【００５３】図１２に示すピクチャーエレメント、図１
３に示す PSBODY エレメント、及び図１４に示す PICBO
DY エレメントのためのサブエレメント・リンクリスト
データ構造のフィールドは、ページセット・エレメント
に関して述べたリンクリストデータ構造のフィールドと
同じように記述することができる。

【００５４】本明細書の作成時点では、ＳＰＤＬ規格は
草案段階で未だ完成していない。将来、エレメントまた
はサブエレメント宣言がシーケンスである時に使用され
る”フラグ”エントリーをサブエレメント・リンクリス
トデータ構造に追加する必要があるかもしれない。しか
し、現時点では必要でないので、このフラグは図示した
サブエレメント・リンクリストデータ構造には含まれて
いない。

【００５５】図１５はバイナリ・ファイルをクリアテキ
ストＳＰＤＬファイルに変換するプロセス中で本発明に
より使用されるエレメント・スタック３４０を示す。エ
レメント・スタック３４０のフィールド３４２は、処理
されているエレメントのクリアテキスト表現であるとこ
ろのエレメント・ネームを記憶している。フィールド３
４４はエレメントの宣言である。フィールド３４６は、
エレメントのアトリビュートを処理するために使用され
る。エレメントの各アトリビュートの処理後、当該エレ
メントの処理されたアトリビュートを管理するため、フ
ィールド３４６は１だけデクリメントされる。フィール
ド３４８は、文書の階層レベルそれぞれのレベル番号を
管理するために使用され、また、クリアテキストＳＰＤ
Ｌファイルにおける字下げ（indentation）レベルを管
理するために用いられる。

【００５６】INDEF フラグ３５０及びエレメント・レン
グス（ELEMENT LENGTH）フィールド３５２は、バイナリ
・エレメントの長さを管理するために使用される。INDE
F フラグ３５０内の”１”はバイナリ・エレメントが不
定長フォーマットであることを示す。エレメント・レン
グスフィールド３５２はバイナリ・エンコーディングが
処理されている時にそのバイトのカウントのために使用
される。ポインタ３５４は、図１１乃至図１４に示した
リンクリストと類似のサブエレメント・リンクリストを
指す。

【００５７】図１５に示したエレメント・スタック３４
０が持っている indef フラグとエレメント・レングス
フィールドは、係属中の米国特許出願第０８／０６６，
３８３号（１９９３年５月２１日受理、”METHOD AND S
YSTEM FOR PROCESSINGMIXED BINARY LENGTH ENCODING
CONTAINING DEFINITE AND INDEFINITE LENGTHFORMAT
S”）に詳しく述べられており、当該特許出願は引用に
より本明細書に組み込まれる。エレメント・スタックの
他の特徴は係属中の米国特許出願第０８／１４７，６０
３号（１９９３年１１月４日受理、”STANDARD PAGE DE
SCRIPTIONLANGUAGE CLEARTEXT STRUCTURE GENERATO
R”）に述べられているエレメント・スタックと幾分類
似しており、当該特許出願は引用により本明細書に組み
込まれる。

【００５８】図１６に示すダブル・リンクリストデータ
構造（double linked list datastructure）３６０は、
クリアテキスト変換後情報を管理するために用いられ
る。一つのバイナリ・エレメントが処理変換される都
度、当該エレメントのための情報がダブルリンクリスト
データ構造に格納される。バイナリからクリアテキスト
への変換が終了した後、ダブル・リンクリストデータ構
造のそれぞれの情報が、図６に示した文書に類似した出
力ファイルへコピーされる。このダブル・リンクリスト
は、バイナリ表現ではクリアテキスト表現での順序と違
った順序を持つことのあるエレメントの処理に役立つ。

【００５９】ダブル・リンクリストデータ構造３６０
は、ポインタ３６２によって指される。ポインタ３６２
は、当該ダブル・リンクリストデータ構造が変換されて
いるファイルのための最初のダブル・リンクリストデー
タ構造でなければ、一つ前のダブル・リンクリストデー
タ構造の”next”ポインタに対応する。当該ダブル・リ
ンクリストデータ構造が変換されているファイルの最初
のダブル・リンクリストデータ構造ならば、ポインタ３
６２は、デフォルト値でよく、システムが当該最初のデ
ータ構造を参照するために使用されるに過ぎない。フィ
ールドレベル番号３６４はエレメントの字下げレベルを
示す。エレメント・ネーム３６８はエレメントのクリア
テキスト・ネームを示す。エントリー３６８は、そのネ
ームを格納するメモリ領域を指すポインタであることも
ある。フィールド３７０はエレメントのアトリビュート
情報を、それが存在するときに、格納する。フィールド
３７０は、アトリビュート情報を格納する別のメモリロ
ケーションへのポインタであることもある。

【００６０】フィールド３７２はエレメントにより使用
されるかもしれないデータを格納する。例えば、エレメ
ントがコメントならば、このデータ・フィールドはコメ
ントのテキストを格納することになろう。このデータ・
フィールドは、実際のデータを格納している別のメモリ
ロケーションへのポインタであることもある。フィール
ド３７４はバックポインタ（back pointer）であり、こ
れは前のダブルリンクリストデータ構造が存在するなら
ば、それを指すものである。前のダブル・リンクリスト
データ構造が存在しないときは、このバックポインタは
ヌルを指す。ネクスト・ポインタ（next pointer）３７
６は、次のダブル・リンクリストデータ構造が存在する
ならば、それを指す。次のダブル・リンクリストデータ
構造が存在しないときには、このネクスト・ポインタ３
７６はヌルを指す。

【００６１】図１７は、本発明に使用されるアトリビュ
ート・バッファ３８０を示す。このアトリビュート・バ
ッファ３８０は、エレメントの処理中に該エレメントの
アトリビュート情報を一時的に記憶するために用いられ
る。

【００６２】図１８乃至図２８は、バイナリＳＰＤＬフ
ァイルをクリアテキストＳＰＤＬファイルへ変換するた
めに本発明により用いられるプロセスを示す。図１８の
ステップ４０２は、入力コマンドライン（command lin
e）を解析して入力ファイルネーム及び出力ファイルネ
ームを確定する。ステップ４０４は、その入力ファイル
が存在するか判定する。入力ファイルが存在しないとき
には、フローはステップ４０６へ進み、入力ファイル不
存在を原因とするエラーが表示され、プロセスから抜け
出す。入力ファイルが存在するときには、フローはステ
ップ４０８へ進み、出力ファイルが特定済みであるか判
定する。出力ファイルが特定済みでなければ、ステップ
４１０で出力ファイルにデフォルトのファイルネームが
割り当てられる。ステップ４１２は、入力ファイルがＳ
ＰＤＬバイナリ・ファイルであるか判定する。この判定
は、ファイルの始まり部分を調べ、それにバイナリＳＰ
ＤＬファイルであることを表示するビットが含まれてい
るかを確かめることによって、行なうことができる。フ
ァイルがバイナリＳＰＤＬファイルであるか判定する方
法に関するより詳細な説明は、係属中の米国特許出願第
０８／００６，４１６号（”METHOD AND SYSTEM TO REC
OGNIZE ENCODING TYPE IN DOCUMENTPROCESSING LANGUAG
E”）に見ることができ、当該出願は引用により本明細
書に組み込まれる。ステップ４１２で入力ファイルがバ
イナリＳＰＤＬファイルではないと判定した場合、ステ
ップ４１４は入力ファイルのフォーマットが正しくない
ことを表示し、プロセスは終了する。入力ファイルがバ
イナリＳＰＤＬファイルであるならば、フローは図１９
に示すプロセスＡに進む。なお、図５，図６及び図７に
挙げた例は国際規格草案に基づいているのに対し、米国
特許出願第０８／００６，４１６号はそれより後のバー
ジョンに基づいているが、該バージョンは未だ最終的な
形で刊行されていない。しかし、いずれのバージョンで
も”28CF 44 00”はバイナリＳＰＤＬエンコーディン
グを意味する。

【００６３】図１９のステップ４２０はエレメントスタ
ックを初期化するが、これは単にスタックのためにメモ
リを予約するに過ぎない。ステップ４２２及びステップ
４２４は、クリアテキスト・ファイルの初めの２行をダ
ブル・リンクリストデータ構造に書き込む。クリアテキ
ストＳＰＤＬファイルの初めの２行は常にDOCTYPE及びS
PDLであるので、これらの２行を各ＳＰＤＬファイルの
始めに書き込む必要がある。

【００６４】ステップ４２６は入力ファイルよりタグを
取得し、ステップ４２８は該タグを調べ、それがRESDEF
であるか判定する。最初のタグがRESDEFでないときに
は、ＳＰＤＬエンコーディング規則はクリアテキスト・
エンコーディングの第３行が文書エレメントであること
を要求する。最初のエレメントタグがRESDEFであれば、
クリアテキスト・エンコーディングの第３行を文書エレ
メントにする必要はない。ステップ４２８及びステップ
４３０より、フローは図２０に示すプロセスＢへ進む。

【００６５】図２０のステップ４４０は、エレメント・
テーブルをサーチしてバイナリタグに対応するエレメン
トを見つけ、エレメントタグに関する情報、例えば、ク
リアテキスト・エレメントネームや、開始タグと終了タ
グがオプショナルであるか必要であるか、エレメントが
プリミティブであるか複合であるか、エレメントのアト
リビュート数、エレメントのサブエレメント数、エレメ
ントのサブエレメント・リンクリストへのポインタとい
った情報を取得する。ステップ４４２は入力ファイルよ
り、エレメントの長さ（length）を示す次のバイトを読
み出す。エンコーディングのレングス・オクテット（le
ngth octet）が２進の10000000である時には、その長さ
は不定長である。不定長エンコーディングの終わりは、
コンテント・オクテット（contents octet）中の0000H
により示される。ステップ４４４でエンコーディングが
不定長であると判定した場合、ステップ４４６はINDEF_
LEN_FLAGを真（true）に設定し、エンコーディングが不
定長フォーマットであることを表示する。ステップ４４
４でエンコーディングが不定長フォーマットではないと
判定された場合には、フローはステップ４４８に進み、
固定長エンコーディングの値が決定される。ステップ４
４８及びステップ４４６より、フローは図２１に示すス
テップＣへ進む。

【００６６】図２１において、ステップ４６０はエレメ
ント・スタックが空であるか判定する。空でなければ、
ステップ４６２で、エレメント・スタックのトップエン
トリーより、処理されるタグのバイト数、該タグに使用
されるバイト及び該タグのレングス部を減じる必要があ
る。現タグのレングス・タイプが固定長であるときに
は、この固定長も減じられる。多くの場合、タグは１バ
イトで、レングスは１バイトであるので、エレメント・
スタックのトップエントリーのレングス・フィールドよ
り２バイトが減じられる。

【００６７】ステップ４６０及びステップ４６２より、
フローはステップ４６４に進み、サブエレメント・リン
クリストポインタがヌルであるか判定される。サブエレ
メント・リンクリストポインタがヌルのときには、エレ
メントにはサブエレメントが存在しないので、エレメン
トは終端（terminal）エレメントであり、フローはステ
ップ４７４に進み、終端エレメントに関するデータを、
対応のダブル・リンクリストデータ構造３６０のポイン
タ３７２により指されたバッファに格納する。フローは
ステップ４７６に進み、TERMINAL_ENTRY_FLAG が真（tr
ue）に設定される。フローはステップ４７６より、図２
４に示すプロセスＥへ進み、エレメントの情報を新しい
ダブル・リンクリストに格納する。

【００６８】ステップ４６４でサブエレメント・リンク
リストポインタがヌルでないと判定した場合、エレメン
トのサブエレメントが存在するので、フローはサブエレ
メント情報の処理を開始すべくステップ４６８に進む。
ステップ４６８はステップ４４０で得られたエレメント
情報をエレメント・スタックへプッシュする。フローは
ステップ４６８から図２２に示すプロセスＤへ進む。

【００６９】図２２において、ステップ４８０はアトリ
ビュート数（エレメント・スタックに記憶されている）
が０より大きいか判定する。アトリビュート数が０より
大きくなければ、ステップ４８２はアトリビュート・バ
ッファATTR_BUFFERをヌルに設定し、フローは図２４に
示すＥへと進む。アトリビュート数が０より大きいとき
には、アトリビュートが処理されなければならないの
で、フローはステップ４８０よりステップ４８４に進
み、入力ファイルより次のＡＳＮ．１タグを読み出す。
次にステップ４８６は、サブエレメント・リンクリスト
をサーチして、そのＡＳＮ．１タグが現エレメントのサ
ブエレメントまたはアトリビュートの有効なタグである
かチェックする。サブエレメントがエレメントの正しい
ＡＳＮ．１サブエレメントならば、フローは図２３に示
すプロセスＧへ進む。処理されるエレメントが適切なサ
ブエレメントでないときは、フローはステップ４９０へ
進み、タグがコメントであるか判定する。タグがコメン
トでなければ、サブエレメントはエレメントにとって適
切でないので、ステップ４９２はエラーを表示し、プロ
セスから抜け出る。タグがコメントならば、タグは一つ
のエレメントとして処理すべく入力ファイルへ書き戻さ
れ、フローは場２０のプロセスＢへ戻る。

【００７０】図２３に示したプロセスＧは、正しいサブ
エレメントの処理を扱うが、図２２のステップ４８８か
ら始まる。図２３のステップ５００において、サブエレ
メント・リンクリストより、ＡＳＮ．１タグ値、サブエ
レメント宣言、サブエレメント・ネーム、サブエレメン
ト・タイプ、サブエレメントの連続番号、次のサブエレ
メント・リンクリストデータ構造へのネクスト・ポイン
タのような、サブエレメントに関する情報を取得する。
ステップ５０２は、サブエレメント・タイプを調べてサ
ブエレメントがアトリビュートであるか判定する。サブ
エレメントがアトリビュートならば、ステップ５０８は
アトリビュート・データをアトリビュート・バッファAT
TR_BUFFERに格納し、フローは図２４に示すプロセスＨ
へ進む。ステップ５０２でサブエレメント・タイプがア
トリビュートでないと判定したときには、フローはステ
ップ５０４へ進む。ステップ５０４は、アトリビュート
が続いていないことを表示する。エレメントのアトリビ
ュートは、そのエレメントの直後及びそのエレメントの
サブエレメントの出現前に現われるべきである。ステッ
プ４８０でアトリビュート数が０より大きいと判定した
場合にはフローはステップ５０２へ到達し、サブエレメ
ントはアトリビュートのはずである（アトリビュートで
ある必要はないが）。サブエレメントがアトリビュート
でないならば、現サブエレメントに続くアトリビュート
は不適切なものであろう。本発明は、図２８に示したフ
ローチャートのステップ６０６，６０８により、そのよ
うなアトリビュートを、その後に出現した時にきちんと
整える。ステップ５０４の後に、ステップ５０６は不適
切なタグを入力ファイルに書き戻し、フローは次の処理
のため図２４のプロセスＥに進む。

【００７１】図２４のプロセスＨはアトリビュートであ
るサブエレメントの処理を扱う。図２４のステップ５２
０は、エレメント・スタックのトップエントリーより、
アトリビュート数を減じる。ステップ５２２はエレメン
ト・スタック内のアトリビュート数を１だけデクリメン
トする。ステップ５２４は、エレメント・スタック内の
アトリビュート数が０より大きいか判定する。アトリビ
ュート数が０より大きいときには、別のアトリビュート
を処理しなければならないのでフローはステップ５２６
へ進む。ステップ５２６はアトリビュート・バッファに
新しい１行キャラクタを格納し、残りのアトリビュート
の処理のためフローは図２２に示すプロセスＦへ進む。

【００７２】ステップ５２４でアトリビュート数が０よ
り大きいと判定した場合、フローはステップ５２８に進
み、処理エレメントに関する、エレメントネーム、レベ
ル番号、アトリビュート・バッファ、データ情報、ネク
ストポインタ及び前ポインタを含む情報の全てが新しい
ダブル・リンクリストデータ構造に格納される。ステッ
プ５２８より、フローは図２５に示すプロセスＩへ進
む。

【００７３】ステップ５４０はTERMINAL_ENTRY_FLAGが
真（true）であるか判定する。TERMINAL_ENTRY_FLAGは
図２１のステップ４７６で真に設定されている。このフ
ラグが設定されていないならば、TERMINAL_ENTRY_FLAG
のデフォルト値は偽（false）である。それが真なら
ば、フローはステップ５４２へ進んで現エレメントが終
端エレメントであることを表示し、該エレメントのため
のエレメント終了タグが新しいダブル・リンクリストデ
ータ構造に書き込まれる。そしてステップ５４４は、TE
RMINAL_ENTRY_FLAGを偽に設定する。

【００７４】ステップ５４０，５４４の次に、ステップ
５４６はINDEF_LEN_FLAGが真であるか判定する。それが
真ならば、フローは不定長フォーマットの処理のため図
２６に示したプロセスＪへ進む。そうでなければ、フロ
ーはステップ５４８へ進み、エレメントスタックのトッ
プエントリーのエレメント・レングスが０であるか判定
される。このレングスが０でなければ、エレメントは固
定長であるので、エレメントの全長は処理が終わってお
らず、さらに処理するため図２８に示すプロセスＫへ進
む。そうでなければ、エレメント・スタックのトップエ
ントリーのレングスは０であり、エレメント・スタック
のトップエントリーにある現エレメントは処理が終了
し、ステップ５５０はエレメントスタックのトップエレ
メントの終了タグを新しいダブル・リンクリストデータ
構造に書き込む。ステップ５５０より、フローは図２７
のＬへ進む。

【００７５】図２６に示したプロセスＪは不定長フォー
マットの処理を扱う。ステップ５６０は入力ファイルに
おける現在位置を変数FPOSへセーブする。ステップ５６
２は入力ファイルより次の２バイトを読み出す。ステッ
プ５６４は、この２バイトの両バイトが０であるか判定
する。そうであるならば、不定長コーディング・フォー
マットの終わりを意味しているので、フローはステップ
５６６に進み、処理されている現エレメントの終了タグ
がダブル・リンクリストデータ構造に書き込まれ、そし
てフローは図２７のＬへ進む。終了フラグに達しないと
きには、フローはステップ５６４からステップ５６８へ
進み、ステップ５６２で読み出されたファイルの最後の
２バイトを処理できるように、入力ファイルのポインタ
が再び位置FPOSを指すよう調整される。ステップ５６８
よりフローは図２８のＫへ進む。図２７に示したプロセ
スＬにおいて、ステップ５７６は現エレメントが不定長
フォーマットであって、かつ現エレメントの下にエント
リーが存在するかを判定する。そうならば、ステップ５
７８で、エレメント・スタック内の該下のレベルのレン
グス・エントリーが、現エレメントのレングス（これは
負の値である）を該下のレベルのレングス・エントリー
に加算することによって調整される。そしてステップ５
８０はエレメント・スタックのトップエントリーをポッ
プする。

【００７６】ステップ５８２でエレメント・スタックが
空であると判定し、かつ、ステップ５８４で処理すべき
データがまだあると判定したときには、フローはステッ
プ５８６へ進んでダブル・リンクリストデータ構造から
出力ファイルへデータがコピーされ、プロセスは終了す
る。エレメント・スタックが空ではないか処理すべきデ
ータがまだあるならば、フローは図２８に示すプロセス
Ｋへ進む。

【００７７】図２８において、ステップ５９０はバイナ
リ入力ファイルの次のタグを読み出す。ステップ５９２
は、そのタグがコメントであるか判定し、コメントであ
るときは現エレメントがコメントに設定され、フローは
図２０に示すプロセスＢへ進む。該次のタグがコメント
でなければ、フローはステップ５９２からステップ５９
６へ進み、サブエレメントの有効性を確認するためにサ
ブエレメントリンクリストがサーチされる。このステッ
プは、現サブエレメントが処理されているエレメントの
下に出現することが許されるか判定する。ステップ５９
８がサブエレメントを有効でないと判定したときには、
不正のサブエレメントであるのでステップ６００でエラ
ーが表示されプロセスを抜け出す。ステップ５９８でサ
ブエレメントが有効であると判定したときには、フロー
はステップ６０２へ進む。

【００７８】ステップ６０２において、エレメント・ス
タック内のトップエレメントのアトリビュート数が０よ
り大きいか調べられる。０より大きくないときには、サ
ブエレメントはアトリビュートでないのでフローはプロ
セスＢへ進む。エレメント・スタックのトップエントリ
ーにおけるアトリビュート数が０より大きいときは、フ
ローはステップ６０４へ進みサブエレメントがアトリビ
ュートであるか判定する。ステップ６０４でサブエレメ
ントがアトリビュートでないと判定したならば、フロー
はプロセスＢへ進む。ステップ６０４でサブエレメント
がアトリビュートであると判定したときには、ステップ
６０６はエレメント・スタックのトップエントリーのエ
レメント情報を見つけるためダブル・リンクリストをサ
ーチする。次にステップ６０８はアトリビュートをアト
リビュート・バッファに格納する。そして、フローは図
２５に示すプロセスＭへ進む。

【００７９】図２９及び図３０は、図５に示したバイナ
リ・ファイルが図６に示したクリアテキスト・ファイル
へ変換される時に作られるダブル・リンクリストデータ
構造を示す。最初のダブル・リンクリストデータ構造７
００は、字下げレベルが０であり、エレメントネームが
!DOCTYPEであり、アトリビュートもデータも持たず、
（ネクスト・ポインタが）ダブル・リンクリストデータ
構造７１０を指す。ダブル・リンクリストデータ構造７
１０は、字下げレベルが０であり、SPDLとネームが付け
られ、データフィールドにアトリビュートもデータも持
たず、（バックポインタが）ダブル・リンクリストデー
タ構造７００を指し、（ネクストポインタが）次のダブ
ル・リンクリストデータ構造７２０を指す。

【００８０】ダブル・リンクリストデータ構造７２０
は、（ネクスト・ポインタが）ダブル・リンクリストデ
ータ構造７３０を指す。このダブル・リンクリストデー
タ構造７３０は、字下げレベルが１であり、ページセッ
トのエレメントを持ち、アトリビュートSPDL ID を定義
され、（ネクスト・ポインタが）ダブル・リンクリスト
データ構造７４０を指す。ダブル・リンクリストデータ
構造７４０は、字下げレベルが２のコメントであり、ア
トリビュートを持たないが、コメントの内容を含むデー
タを持つ。なお、ダブル・リンクリストデータ構造７４
０のDATA_HEADエントリーは、実際のデータを指すとこ
ろのリンクリストデータ構造を指す。ダブル・リンクリ
ストデータ構造７４０のDATA_HEADエントリーにより指
されたれたリンクリストデータ構造のネクストエントリ
ーが次のリンクリストデータ構造を指すことがある。

【００８１】ダブル・リンクリストデータ構造７４０
は、（ネクストポインタが）図３０に示すダブル・リン
クリストデータ構造７６０を指す。図３０に示すデータ
構造は、図２９に示したデータ構造と同様に説明でき
る。なお、簡略化のため、ダブル・リンクリストデータ
構造７８０とダブル・リンクリストデータ構造８００の
間のデータ構造は省略されているが、本発明のプロセス
を辿り、及び／または図６に示したクリアテキストの例
をよく見ることにより、省略されたデータ構造を確認し
得る。

【００８２】図３１乃至図３５は、図５及び図６に示し
た例が処理される時のエレメントスタックを示す。エレ
メント・スタック内のポインタによって指されるサブエ
レメント・リンクリストは、一定のままであるので、図
１１乃至図１４に示す同じゼネラルタイプのリンクリス
トとなろう。

【００８３】バイナリＳＰＤＬファイルが本発明により
処理される様子の例を示すため、図１８乃至図２８に示
したフローチャートに戻る。本発明のプロセスは図１８
から始まるが、入力ファイルと出力ファイルが特定され
フローが図１９へ進んだと仮定する。ステップ４２２は
図２９に示すダブル・リンクリストデータ構造７００を
生成する。ステップ４２４は図２９に示したダブル・リ
ンクリストデータ構造７１０を生成する。次にステップ
４２６は、図５に示すファイルで最初に現われるエレメ
ントであるエレメントタグバイト６１を読み出す。この
エレメント６１はPAGESETに対応しエレメントRESDEFに
は対応しないので、フローはステップ４３０へ進み、図
２９のダブル・リンクリスト７２０を生成する。そして
フローは図２０のプロセスＢへ進む。ステップ４４０
は、PAGESETのようなエレメント・ネームやステップ４
４０に列挙された他の全情報を含む、エレメント６１に
関する情報を取得する。入力ファイルの次のバイトは５
９であり、これはPAGESETの固定長値である。したがっ
て、フローはステップ４２２からステップ４４４、ステ
ップ４４８と進み、図２１のステップ４６０へ進む。

【００８４】図２１において、ステップ４６０は、エレ
メント・スタックにはエレメントが全くプッシュされて
いないので、エレメント・スタックが空であると判定す
る。ステップ４６４はサブエレメント・リンクリストが
ヌルでないと判定し、フローはステップ４６８へ進み、
エレメント情報をエレメント・スタックへプッシュす
る。この時のエレメント・スタックは図３１に示す如き
である。そしてフローは図２２に示すプロセスＤへ進
む。

【００８５】PAGESETのアトリビュート数は０より大き
いので、フローはステップ４８０からステップ４８４へ
進み、入力ファイルより次のＡＳＮ．１タグである０６
が取り出される。０６はPAGESETの適切なサブエレメン
トであるので、フローはステップ４８８から図２３に示
したプロセスＧへ進む。ステップ５００はサブエレメン
トの情報を読み出し、ステップ５０２はサブエレメント
がアトリビュートであると判定する。PAGESETエレメン
トは一つのアトリビュートを有し、PAGESETの最初のサ
ブエレメントがアトリビュートであるから、このアトリ
ビュートは順序通りであるので、フローはステップ５０
８へ進み、アトリビュートデータはアトリビュート・バ
ッファATTR_BUFFERへ格納される。そしてフローは図２
４に示すプロセスＨへ進む。

【００８６】図２４において、ステップ５２０はエレメ
ント・スタックのトップエントリーよりアトリビュート
のレングスを差し引く。SPDL IDのレングスは４バイト
であるので、４に、レングス情報のバイト数、SPDL ID
のバイト数及びPAGESETのバイト数を足した値が図３１
に示したスタックより減じられる。最初のアトリビュー
トの処理が済んだのでステップ５２２はアトリビュート
数を１だけ減らし、またPAGESETはアトリビュートを１
個しか持たないのでフローはステップ５２４からステッ
プ５２８へ進み、エレメントの情報が図２９に示す新し
いダブルリンクリストデータ構造７３０に格納される。
PAGESETは図６の最初の字下げレベルであるので、ダブ
ル・リンクリストデータ構造７３０のレベル番号エント
リーは１に設定される。ステップ５２８より、フローは
図２５に示すプロセスＩへ進む。

【００８７】TERMNAL_ENTRY_FLAGは偽（false）に初期
化されているので、フローはステップ５４０からステッ
プ５４６へ、そしてステップ５４８へと進み、エレメン
トスタックのトップエントリーのエレメント・レングス
は０ではないと判定される。そしてフローは図２８に示
すプロセスＫへ進む。

【００８８】図２８において、ステップ５９０は入力フ
ァイルより次のＡＳＮ．１タグを読み出すが、同タグは
４４である。このタグはコメントタグであるので、ステ
ップ５９４は現エレメントをコメントととし、フローは
図２０に示すプロセスＢへ進む。

【００８９】図２０において、ステップ４４０はエレメ
ント・テーブルをサーチしてコメントに関する情報を取
得し、ステップ４４８はコメントの固定長値を取得する
が、この固定長値は１Ｆである。フローはステップ４６
０に進み、エレメント・スタックが空でないことを確認
し、ステップ４６２においてコメントのレングスがスタ
ック内のPAGESETのエレメントレングス・エントリーよ
り差し引かれる。次にステップ４６４は、コメント・エ
レメントがサブエレメントを全く持たないので、サブエ
レメント・リンクリスト・ポインタがヌルであると判定
する。ステップ４７４で、コメントに含まれる情報はデ
ータバッファ・リンクリストデータ構造に格納される。
次にステップ４７６は変数TERMINAL_ENTRY_FLAGを真に
設定し、フローは図２４に示すプロセスＥへ進む。

【００９０】図２４において、ステップ５２８はコメン
トの情報を図２９に示すダブル・リンクリストデータ構
造７４０に格納する。そしてフローは図２５に示すプロ
セスＩへ進む。ステップ５４０１での判定結果はＹＥＳ
である。この変数は図２１のステップ４７６で真に設定
されているからである。次にフローはステップ５４２に
進み、エレメント終了タグが図３０に示すダブル・リン
クリストデータ構造７６０に書き込まれる。フローはス
テップ５４６、ステップ５４８と進み、図２８に示すプ
ロセスＫへ進む。

【００９１】図２８のステップ５９０は入力ファイルよ
り次のＡＳＮ．１タグを読み出すが、このタグはページ
セット・ボディに対応するＡ１である。そしてフローは
ステップ５９２からステップ５９６，５９８，６０２と
進み、次に図２０に示すプロセスＢへ進む。

【００９２】図２０において、ページセット・ボディの
情報を取得するためエレメント・テーブルがサーチされ
る。次にフローは図２１に示すプロセスＣへ進み、ステ
ップ４６２は図３１に示すスタック８５０内のPAGESET
エントリーのエレメント・レングス・エントリーから、
ページセット・ボディ・エレメントのレングスを減じ
る。ステップ４６４はページセットボディのサブエレメ
ント・リンクリストポインタがヌルでないと判定するの
で、フローはステップ４６８へ進み、PAGESETのエレメ
ント情報をエレメント・スタックへプッシュする。これ
で、エレメント・スタックは図３２に示すようになる。

【００９３】同様にして、図５に示すバイナリ・ファイ
ルの残りの部分が本発明のフローチャートに従って処理
されることにより、図３３乃至図３５に示すエレメント
・スタックと図２９及び図３０に示すダブル・リンクリ
ストデータ構造が得られる。フローチャートのこれ以上
の追跡は、簡略化のため省略する。

【００９４】図３６は本発明のプロセスを実行するため
に利用可能なワークステーション１０００の構成を示
す。ワークステーション１０００はＣＰＵ９５０、ＲＡ
Ｍ９５２、ＲＯＭ９５４、キーボード９５８及びマウス
９６０がつながれた入力コントローラ９５６を含む。印
刷エンジンインターフェイス９６４は印刷エンジン９６
２に直接接続され、印刷エンジン９６２はインターフェ
イス９６４により伝達されるイメージデータを表わすビ
デオ制御信号を受け取る。このワークステーションはさ
らに、ハードディスク９６８及びフロッピードライブ９
７０とつながれたディスクコントローラ９７２、ネット
ワーク９８４（例えばＥthernet（登録商標）ネットワ
ーク）との接続のための通信コントローラ９７４、外部
ハードディスク９８０と例えばＳＣＳＩバスにより、ま
たプリンタ９７８と例えばＲＳ−２３２Ｃケーブルによ
り接続されたＩ／Ｏコントローラ９７６を含む。ワーク
ステーションはＣＲＴ９８６と接続されたディスプレイ
コントローラ９８２も含む。システムバス９６６はワー
クステーション内の各要素を接続する。

【００９５】本発明のプロセスは図３６に示す記憶デバ
イスのどれに格納してもよい。さらに、本発明のプロセ
スの動作中に、プロセス中で生成され使用されるデータ
は図３６に示した記憶デバイスのどれに格納してもよ
い。

【００９６】なお、本発明で使用されたデータ構造は、
本願発明者による他の発明のいくつかで使用できる。こ
れらの他の発明は本発明のフローチャートで使用された
データフィールドより余分のデータフィールドを必要と
するかもしれないので、本発明を構成するために各デー
タ構造に示したフィールドの全ては必要でないかもしれ
ない。さらに、ＳＰＤＬ規格は草案段階で発展中であ
る。したがって、生成されたデータ構造の一部は、規格
の変更によりもう必要でないフィールドを、あるいは、
規格が変更される可能性の故に存在するフィールドを持
っているかもしれない。

【００９７】なお、付記するならば、下記方法及び装置
は本発明の範囲に包含されるものである。

【００９８】（１）ファイルのフォーマットを変換する
方法で、次のステップを有する：バイナリファイルを入
力するステップ；該バイナリファイルのエレメントをテ
キストフォーマットへ変換するステップ；該エレメント
の該テキストフォーマットを第１のバッファに書き込む
ステップ；該エレメントのためにアトリビュートが必要
とされるか確認するステップ；該バイナリファイルのサ
ブエレメントが該エレメントのアトリビュートである
か、または該サブエレメントが該エレメントのアトリビ
ュートでないか判定するステップ；該サブエレメントを
テキストフォーマットへ変換するステップ；該サブエレ
メントが該エレメントのアトリビュートでないと判定さ
れ、かつ、該エレメントのためにアトリビュートが必要
とされると確認された時に、次のステップを実行するス
テップ：該エレメントの該サブエレメントの該テキスト
フォーマットを第２のバッファに書き込むステップ；該
必要とされるアトリビュートに出会うまで該バイナリフ
ァイルを処理するステップ；該必要とされるアトリビュ
ートをテキストフォーマットへ変換するステップ；該必
要とされるアトリビュートの該テキストフォーマットを
該エレメントを格納している該第１バッファに書き込む
ステップ；該サブエレメントがアトリビュートであると
判定され、かつ、該第１のエレメントのためにアトリビ
ュートが必要とされると確認された時に、次のステップ
を実行するステップ：該サブエレメントの該テキストフ
ォーマットを該第１バッファに書き込むステップ。

【００９９】（２）前記（１）の方法において、該エレ
メントの該サブエレメントの該テキストフォーマットを
第２バッファに書き込むステップは、該エレメントの該
サブエレメントの該テキストフォーマットを該第１バッ
ファを参照する該第２バッファに書き込み、かつ該方法
は、該サブエレメントが該エレメントのアトリビュート
でないと判定された後に実行される次のステップをさら
に有する：該必要とされるアトリビュートの該テキスト
フォーマットを該エレメントを記憶している該第１バッ
ファに書き込むステップを実行する前に、該第２バッフ
ァから逆向きに辿って該第１バッファを見つけるステッ
プ。

【０１００】（３）前記（１）の方法において、該第２
バッファは、該第１バッファを後方参照しかつ次のバッ
ファを前方参照するダブルリンクリストであり、かつ該
サブエレメントの該テキストフォーマットを該第２バッ
ファに書き込むステップは、該サブエレメントの該テキ
ストフォーマットを該ダブルリンクリストに書き込み、
該方法はさらに、該サブエレメントが該エレメントのア
トリビュートではないと判定された後に実行される次の
ステップを有する：該必要とされるアトリビュートの該
テキストフォーマットを該エレメントを記憶している該
第１バッファに書き込むステップを実行する前に、該ダ
ブルリンクリストから逆向きに辿って該第１バッファを
見つけるステップ。

【０１０１】（４） 以下の手段を有するファイルのフ
ォーマットを変換するための装置：バイナリファイルを
入力するための手段；該バイナリファイルのエレメント
をテキストフォーマットへ変換するための手段；該エレ
メントの該テキストフォーマットを第１のバッファに書
き込むための手段；該エレメントのためにアトリビュー
トが必要とされるか確認するための手段；該バイナリフ
ァイルのサブエレメントが該エレメントのアトリビュー
トであるか、または該サブエレメントが該エレメントの
アトリビュートであるかを判定するための手段；該サブ
エレメントを該テキストフォーマットへ変換するための
手段；該サブエレメントが該エレメントのアトリビュー
トでないと判定されかつ該エレメントのためにアトリビ
ュートが必要とされると確認された時に、該エレメント
の該サブエレメントの該テキストフォーマットを第２の
バッファに書き込むための手段；該サブエレメントが該
エレメントのアトリビュートでないと判定されかつ該エ
レメントのためにアトリビュートが必要とされると確認
された時に、該必要とされるアトリビュートに出会うま
で該バイナリファイルを処理するための手段；該サブエ
レメントが該エレメントのアトリビュートではないと判
定されかつ該エレメントのためにアトリビュートが必要
とされると確認された時に、該必要とされるアトリビュ
ートを該テキストフォーマットへ変換するための手段；
該サブエレメントが該エレメントのアトリビュートでは
ないと判定されかつ該エレメントのためにアトリビュー
トが必要とされると確認された時に、該必要とされるア
トリビュートの該テキストフォーマットを該エレメント
を記憶している該第１バッファに書き込むための手段；
及び該サブエレメントがアトリビュートであると判定さ
れかつ該エレメントのためにアトリビュートが必要とさ
れると確認された時に、該サブエレメントの該テキスト
フォーマットを該第１バッファに書き込むのための手
段。

【０１０２】（５）前記（４）の装置において：該エレ
メントの該サブエレメントの該テキストフォーマットを
該第２バッファに書き込むための手段は、該第１バッフ
ァを参照する該第２バッファに該エレメントの該サブエ
レメントの該テキストフォーマットを書き込み、かつ該
装置はさらに次の手段を有する：該サブエレメントが該
エレメントのアトリビュートではないと判定された後、
該必要とされるアトリビュートの該テキストフォーマッ
トを該エレメントを記憶している該第１バッファに書き
込むステップを実行する前に、該第２バッファから逆向
きに辿って該第１バッファを見つけるための手段。

【０１０３】（６）前記（４）の装置において、該エレ
メントの該サブエレメントの該テキストフォーマットを
該第２バッファに書き込むための手段は、該第１バッフ
ァを後方参照しかつ次のバッファを前方参照するダブル
リンクリストであるところの該第２バッファに、該エレ
メントの該サブエレメントの該テキストフォーマットを
書き込み、かつ該装置はさらに次の手段を有する：該サ
ブエレメントが該エレメントのアトリビュートでないと
判定された後、該必要とされるアトリビュートの該テキ
ストフォーマットを該エレメントを記憶している該第１
バッファに書き込むステップを実行する前に、該ダブル
リンクリストより逆向きに辿って該第１バッファを見つ
けるための手段。

【０１０４】（７）ファイルのフォーマットを変換する
ための方法で次のステップを有する：バイナリファイル
を入力するステップ；該バイナリファイルのエレメント
をテキストフォーマットへ変換するステップ；該エレメ
ントの該テキストフォーマットを第１のバッファに書き
込むステップ；該エレメントの許容されるサブエレメン
トを記憶しているデータ構造を辿って調べることによ
り、該バイナリファイルの該エレメントのサブエレメン
トが該エレメントの許容されるサブエレメントである
か、または該サブエレメントが該エレメントの許容され
ないサブエレメントであるか判定するステップ；該サブ
エレメントが該エレメントの許容されないサブエレメン
トであると判定された時にエラーを表示するステップ；
及び該サブエレメントが該エレメントの許容されないサ
ブエレメントであると判定された時に、該バイナリファ
イルの後続部分をテキストフォーマットへ変換するステ
ップ。

【０１０５】（８）前記（７）の方法において、該判定
のステップは、該エレメントの許容されるサブエレメン
トをそれぞれ記憶しているサブエレメントリンクリスト
データ構造を辿って調べることにより、該エレメントの
該サブエレメントが該エレメントの許容されるサブエレ
メントであるか、または該サブエレメントが該エレメン
トの許容されないサブエレメントであるか判定し、該サ
ブエレメントが該サブエレメントリンクリストデータ構
造中に見つかるならば該サブエレメントは許容されると
判定され、該サブエレメントが該サブエレメントリンク
リストデータ構造中に見つからなければ該サブエレメン
トは許容されないと判定される。

【０１０６】（９）次の手段を有する、ファイルのフォ
ーマットを変換する装置：バイナリファイルを入力する
ための手段；該バイナリファイルのエレメントをテキス
トフォーマットへ変換するための手段；該エレメントの
該テキストフォーマットを第１のバッファに書き込むた
めの手段；該エレメントの許容されるサブエレメントを
記憶しているデータ構造を辿って調べることにより、該
バイナリファイルの該エレメントのサブエレメントが該
エレメントの許容されるサブエレメントであるか、また
は該サブエレメントが該エレメントの許容されないサブ
エレメントであるか判定するための手段；該サブエレメ
ントが該エレメントの許容されないサブエレメントであ
ると判定された時にエラーを表示するための手段；及び
該サブエレメントが該エレメントの許容されないサブエ
レメントであると判定された時に、該バイナリファイル
の後続部分を該テキストフォーマットへ変換するための
手段。

【０１０７】（１０）前記（９）の装置において、該判
定のための手段は、該エレメントの許容されるサブエレ
メントをそれぞれ記憶しているサブエレメントリンクリ
ストデータ構造を辿って調べることにより、該エレメン
トの該サブエレメントが該エレメントの許容されるサブ
エレメントであるか、または該サブエレメントが許容さ
れないサブエレメントであるか判定し、該サブエレメン
トが該サブエレメントリンクリストデータ構造中に見つ
かるならば該サブエレメントは許容されると判定され、
該サブエレメントが該サブエレメントリンクリストデー
タ構造中に見つからなければ該サブエレメントは許容さ
れないと判定される。

【０１０８】（１１）固定長エンコーディングがネスト
された不定長エンコーディングのフォーマットをバイナ
リからテキストへ変換する方法であり、該不定長エンコ
ーディング及び該固定長エンコーディングは両方ともプ
リアンブル情報及びコンテント情報を含み、該方法は次
のステップを有する：バイナリファイルを入力するステ
ップ；該不定長エンコーディングの該プリアンブル情報
を処理して該不定長エンコーディングの該プリアンブル
情報のバイナリ表現をテキスト表現へ変換するステッ
プ；次のステップを実行することによって、該固定長エ
ンコーディングを含む該不定長エンコーディングの該コ
ンテント情報を処理するステップ：該固定長エンコーデ
ィングの該プリアンブル情報を処理して該固定長エンコ
ーディングのコンテント情報のバイト数を確認するステ
ップ；及び該固定長エンコーディングのコンテント情報
のバイナリ表現をテキスト表現へ変換することにより、
該不定長エンコーディングの終わりを示すマーカーが存
在するか判定することなく、該固定長エンコーディング
のコンテント情報のバイト数が処理されるまでバイトを
処理することによって該固定長エンコーディングの該コ
ンテント情報を処理するステップ；該固定長エンコーデ
ィングの該コンテント情報を処理した後、該固定長エン
コーディングの該コンテント情報の後の該不定長エンコ
ーディングのバイトを調べ該不定長エンコーディングの
終わりを示すマーカーを捜すステップ；及び該固定長エ
ンコーディングの該コンテント情報の後のバイトが該不
定長エンコーディングの終わりを示すならば、該不定長
エンコーディングの処理を終了させるステップ。

【０１０９】（１２）前記（11）の方法で、さらに次の
ステップを有する：該固定長エンコーディングの該コン
テント情報に続くバイトが該不定長エンコーディングの
終わりを示さないならば、該固定長エンコーディングに
続くバイトを、該不定長エンコーディング中にネストさ
れた次のプロシージャとして処理するステップ。

【０１１０】（１３）固定長エンコーディングがネスト
された不定長エンコーディングのフォーマットをバイナ
リからテキストへ変換する方法であり、該不定長エンコ
ーディング及び該固定長エンコーディングは両方ともプ
リアンブル情報及びコンテント情報を含み、該方法は次
のステップを有する：該不定長エンコーディングの該プ
リアンブル情報を処理して該プリアンブル情報のバイナ
リ表現をテキスト表現へ変換するステップ；次のステッ
プを実行することによって、該固定長エンコーディング
を含む該不定長エンコーディングの該コンテント情報を
処理するステップ：該固定長エンコーディングの該プリ
アンブル情報を処理して該固定長エンコーディングの該
コンテント情報のバイト数を確認し、該固定長エンコー
ディングの該コンテント情報のバイト数を一時的記憶手
段に格納し、かつ、該固定長エンコーディングのバイナ
リ表現をテキスト表現へ変換するステップ；及び該不定
長エンコーディングの終わりを示すマーカーが該不定長
エンコーディング中に存在するか判定することなく、該
一時的記憶手段に記憶された該コンテント情報バイト数
が処理されるまでバイトを処理することによって該固定
長エンコーディングの該コンテント情報を処理し、該固
定長エンコーディングの該コンテント情報が処理されて
いる時に、該固定長エンコーディングの処理が済んだバ
イト数を該一時的記憶手段にカウントするステップ；該
固定長エンコーディングの該コンテント情報を処理した
後、該固定長エンコーディングの該コンテント情報の後
の該不定長エンコーディングのバイトを調べ該不定長エ
ンコーディングの終わりを示すマーカーを捜すステッ
プ；及び該固定長エンコーディングの該コンテント情報
の後のバイトが該不定長エンコーディングの終わりを示
すならば該不定長エンコーディングの処理を終了させる
ステップ。

【０１１１】（１４）前記（１３）の方法において、該
固定長エンコーディングの該コンテント情報の該バイト
数を格納するステップは、そのレングス情報をスタック
にプッシュし；かつ該固定長エンコーディングの該コン
テント情報を処理するステップは、該不定長エンコーデ
ィングの終わりを示すマーカーが該不定長エンコーディ
ング中に存在するか判定することなく、該スタック上の
該コンテントのバイト数が処理されるまでバイトを処理
し、該固定長エンコーディングの該コンテント情報が処
理されている時に、該固定長エンコーディングの処理の
済んだバイト数を該スタックにカウントする。

【０１１２】（１５）不定長エンコーディングがネスト
された第１の固定長エンコーディングのフォーマットを
バイナリからテキストへ変換する方法であり、該不定長
エンコーディングは第２の固定長エンコーディングがネ
ストされており、該不定長エンコーディング並びに該第
１及び該第２の固定長エンコーディングはそれぞれプリ
アンブル情報及びコンテント情報を含み、該方法は次の
ステップを有する：該第１固定長エンコーディングの該
プリアンブル情報を処理し該プリアンブル情報をバイナ
リ表現からテキスト表現へ変換するステップ；次のステ
ップを実行することにより該第１固定長エンコーディン
グの該コンテント情報を処理するステップ：該不定長エ
ンコーディングの該プリアンブル情報を処理し、該不定
長エンコーディングの該プリアンブル情報が処理されて
いる時に、該不定長エンコーディングの該プリアンブル
情報の処理されたバイト数を一時的記憶手段の第１のエ
ントリーにカウントし、該不定長エンコーディングの該
プリアンブル情報をバイナリ表現からテキスト表現へ変
換するステップ；次のステップを実行することにより該
不定長エンコーディングの該コンテント情報を処理する
ステップ：該第２固定長エンコーディングの該プリアン
ブル情報を処理して該第２固定長エンコーディングの該
コンテント情報のバイト数を確認し、該第２固定長エン
コーディングの該コンテント情報のバイト数を該一時的
記憶手段の第２のエントリーに格納し、該第２固定長エ
ンコーディングの該プリアンブル情報が処理されている
時に、該第２固定長エンコーディングの処理されたバイ
ト数を該一時的記憶手段の該第１エントリーにカウント
し、該第２固定長エンコーディングのバイナリ表現をテ
キスト表現へ変換するステップ；及び該不定長エンコー
ディングの終わりを示すマーカーが該エンコーディング
中に存在するか判定することなく、該第２固定長エンコ
ーディングの該コンテント情報のバイト数が処理される
まで該第２固定長エンコーディングを処理することによ
って該第２固定長エンコーディングの該コンテント情報
を処理し、該第２固定長エンコーディングの該コンテン
ト情報が処理されている時に、該第２固定長エンコーデ
ィングの処理されたバイト数を該一時的記憶手段の該第
２エントリーにカウントするステップ；該第２固定長エ
ンコーディングの該コンテント情報を処理した後、該第
２固定長エンコーディングの該コンテント情報の後の該
エンコーディングのバイトを調べ、該不定長エンコーデ
ィングの終わりを示すバイトを捜すステップ；該第２固
定長エンコーディングの該コンテント情報に続くバイト
が該不定長エンコーディングの終わりを示すならば、該
不定長エンコーディングの処理を終了させるステップ；
及び該第１固定長エンコーディングのコンテントの後続
バイトを、該第１固定長エンコーディングの全バイトが
処理されるまで処理するステップ。

【０１１３】

【発明の効果】以上、詳細に説明したところから理解さ
れるように、本発明によれば、バイナリフォーマットを
クリアテキストフォーマットへ変換する際に解決すべき
前記したような諸課題を解決し、文書のバイナリフォー
マットからクリアテキストフォーマットへの変換が可能
になる。

【図面の簡単な説明】

【図１】バイナリ・エンコーディングの固定長フォーマ
ット及び不定長フォーマットのネスティングの一例を示
す図である。

【図２】ＩＳＯ／ＩＥＣ 8825 によるエンコーディング
の構造を示す図である。

【図３】ＩＳＯ／ＩＥＣ 8825 によるアイデンティファ
イア・オクテットの構造を示す図である。

【図４】ＳＰＤＬエレメント状態遷移ダイヤグラムの部
分図である。

【図５】バイナリ・エンコードのＳＰＤＬ文書サンプル
の１６進表現を示す図である。

【図６】図５に示したバイナリ文書のクリアテキスト表
現を示す図である。

【図７】図５に示したバイナリ・エレメントと図６に示
したクリアテキスト・エレメントとの対応を示す図であ
る。

【図８】ＡＳＮ．１タグ及び対応のクリアテキスト・エ
レメントを示すアプリケーション・テーブルを示す図で
ある。

【図９】ＳＰＤＬ構造エレメントに関する情報を格納す
るために用いられるエレメント・テーブルを示すずであ
る。

【図１０】エレメント・テーブルにより指されるサブエ
レメント・リンクリストデータ構造の説明図である。

【図１１】図９に示したエレメント・テーブルにより指
されるサブエレメント・リンクリストデータ構造のサン
プルを示す図である。

【図１２】図９に示したエレメント・テーブルにより指
されるサブエレメント・リンクリストデータ構造のサン
プルを示す図である。

【図１３】図９に示したエレメント・テーブルにより指
されるサブエレメント・リンクリストデータ構造のサン
プルを示す図である。

【図１４】図９に示したエレメント・テーブルにより指
されるサブエレメント・リンクリストデータ構造のサン
プルを示す図である。

【図１５】本発明の変換プロセスに用いられるエレメン
ト・スタックを示す図である。

【図１６】各ラインのクリアテキスト表現を、出力ファ
イルに書き出されるまで記憶するため使用されるダブル
・リンクリストデータ構造を示す図である。

【図１７】本発明に使用されるアトリビュート・バッフ
ァを示す図である。

【図１８】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図１９】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２０】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２１】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２２】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２３】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２４】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２５】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２６】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２７】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２８】本発明で用いられるプロセスを記述したフロ
ーチャートである。

【図２９】図５に示されたバイナリ文書の変換中に生成
されるダブル・リンクリストデータ構造の一部を示す図
である。

【図３０】図５に示されたバイナリ文書の変換中に生成
されるダブル・リンクリストデータ構造の一部を示す図
である。

【図３１】図５に示された文書の変換中におけるエレメ
ント・スタックのステータスを示す図である。

【図３２】図５に示された文書の変換中におけるエレメ
ント・スタックのステータスを示すずである。

【図３３】図５に示された文書の変換中におけるエレメ
ント・スタックのステータスを示す図である。

【図３４】図５に示された文書の変換中におけるエレメ
ント・スタックのステータスを示す図である。

【図３５】図５に示された文書の変換中におけるエレメ
ント・スタックのステータスを示す図である。

【図３６】本発明のハードウエア構成例を示すブロック
図である。

【符号の説明】

２３０〜３３０ サブエレメント・リンクリストデータ
構造 ３４０ エレメントスタック ３６０ ダブル・リンクリストデータ構造 ３７４ バックポインタ ３７６ ネクストポインタ ３８０ アトリビュートバッファ ７００〜８１０ ダブル・リンクリストデータ構造 ８５０ エレメントスタック ９５６ 入力コントローラ ９５８ キーボード ９６０ マウス ９６２ 印刷エンジン ９６４ 印刷エンジンインターフェイス ９６６ システムバス ９６８ ハードディスク ９７０ フロッピーディスク ９７２ ディスクコントローラ ９７４ 通信コントローラ ９７６ Ｉ／Ｏコントローラ ９７８ プリンタ ９８０ ハードディスク ９８２ ディスプレイコントローラ ９８４ ネットワーク

───────────────────────────────────────────────────── フロントページの続き (72)発明者 サットウインダー マンガット アメリカ合衆国 カリフォルニア州 94025 メンローパーク サンド ヒル ロード 2882 リコー コーポレーション 内 (72)発明者 ドニー ツアイ アメリカ合衆国 カリフォルニア州 94025 メンローパーク サンド ヒル ロード 2882 リコー コーポレーション 内

Claims (5)

【特許請求の範囲】
1. 【請求項１】 バイナリファイルを入力するための手
   段、 該バイナリファイルのエレメントをテキストフォーマッ
   トへ変換するための手段、 該エレメントの該テキストフォーマットを第１のバッフ
   ァに書き込むための手段、 該エレメントのためにアトリビュートが必要とされるか
   確認するための手段該バイナリファイルのサブエレメン
   トが該エレメントのアトリビュートであるか、または該
   サブエレメントが該エレメントのアトリビュートである
   かを判定するための手段、 該サブエレメントを該テキストフォーマットへ変換する
   ための手段、 該サブエレメントが該エレメントのアトリビュートでな
   いと判定されかつ該エレメントのためにアトリビュート
   が必要とされると確認された時に、該エレメントの該サ
   ブエレメントの該テキストフォーマットを第２のバッフ
   ァに書き込むための手段、 該サブエレメントが該エレメントのアトリビュートでな
   いと判定されかつ該エレメントのためにアトリビュート
   が必要とされると確認された時に、該必要とされるアト
   リビュートに出会うまで該バイナリファイルを処理する
   ための手段、 該サブエレメントが該エレメントのアトリビュートでは
   ないと判定されかつ該エレメントのためにアトリビュー
   トが必要とされると確認された時に、該必要とされるア
   トリビュートを該テキストフォーマットへ変換するため
   の手段、 該サブエレメントが該エレメントのアトリビ
   ュートではないと判定されかつ該エレメントのためにア
   トリビュートが必要とされると確認された時に、該必要
   とされるアトリビュートの該テキストフォーマットを該
   エレメントを記憶している該第１バッファに書き込むた
   めの手段、及び該サブエレメントがアトリビュートであ
   ると判定されかつ該エレメントのためにアトリビュート
   が必要とされると確認された時に、該サブエレメントの
   該テキストフォーマットを該第１バッファに書き込むの
   ための手段、を具備してなる、ファイルのフォーマット
   を変換するためのフォーマット変換装置。
2. 【請求項２】 請求項１記載のフォーマット変換装置に
   おいて、 該エレメントの該サブエレメントの該テキストフォーマ
   ットを該第２バッファに書き込むための手段は、該第１
   バッファを参照する該第２バッファに該エレメントの該
   サブエレメントの該テキストフォーマットを書き込み、
   かつ該フォーマット変換装置は、該サブエレメントが該
   エレメントのアトリビュートではないと判定された後、
   該必要とされるアトリビュートの該テキストフォーマッ
   トを該エレメントを記憶している該第１バッファに書き
   込むステップを実行する前に、該第２バッファから逆向
   きに辿って該第１バッファを見つけるための手段、をさ
   らに具備することを特徴とするフォーマット変換装置。
3. 【請求項３】 請求項１記載のフォーマット変換装置に
   おいて、該エレメントの該サブエレメントの該テキスト
   フォーマットを該第２バッファに書き込むための手段
   は、該第１バッファを後方参照しかつ次のバッファを前
   方参照するダブルリンクリストであるところの該第２バ
   ッファに、該エレメントの該サブエレメントの該テキス
   トフォーマットを書き込み、かつ該フォーマット変換装
   置は、該サブエレメントが該エレメントのアトリビュー
   トでないと判定された後、該必要とされるアトリビュー
   トの該テキストフォーマットを該エレメントを記憶して
   いる該第１バッファに書き込むステップを実行する前
   に、該ダブルリンクリストより逆向きに辿って該第１バ
   ッファを見つけるための手段をさらに具備することを特
   徴とするフォーマット変換装置。
4. 【請求項４】 バイナリファイルを入力するための手
   段、 該バイナリファイルのエレメントをテキストフォーマッ
   トへ変換するための手段、 該エレメントの該テキストフォーマットを第１のバッフ
   ァに書き込むための手段、 該エレメントの許容されるサブエレメントを記憶してい
   るデータ構造を辿って調べることにより、該バイナリフ
   ァイルの該エレメントのサブエレメントが該エレメント
   の許容されるサブエレメントであるか、または該サブエ
   レメントが該エレメントの許容されないサブエレメント
   であるか判定するための手段、 該サブエレメントが該
   エレメントの許容されないサブエレメントであると判定
   された時にエラーを表示するための手段、及び該サブエ
   レメントが該エレメントの許容されないサブエレメント
   であると判定された時に、該バイナリファイルの後続部
   分を該テキストフォーマットへ変換するための手段、を
   具備してなる、ファイルのフォーマットを変換するため
   のフォーマット変換装置。
5. 【請求項５】 請求項４記載のフォーマット変換装置に
   おいて、該判定のための手段は、該エレメントの許容さ
   れるサブエレメントをそれぞれ記憶しているサブエレメ
   ントリンクリストデータ構造を辿って調べることによ
   り、該エレメントの該サブエレメントが該エレメントの
   許容されるサブエレメントであるか、または該サブエレ
   メントが許容されないサブエレメントであるか判定し、
   該サブエレメントが該サブエレメントリンクリストデー
   タ構造中に見つかるならば該サブエレメントは許容され
   ると判定され、該サブエレメントが該サブエレメントリ
   ンクリストデータ構造中に見つからなければ該サブエレ
   メントは許容されないと判定される、ことを特徴とする
   フォーマット変換装置。