JP3406706B2 - 状態変数管理方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、テキスト、グラフィッ
ク成分及び／またはイメージからなる文書のコンピュー
タ制御による印刷、表示、その他のプレゼンテーション
に関する。本発明は特に、辞書の集合、それら辞書のサ
ーチ順を定義するコンテキストスタック（context stac
k）、状態変数テーブル、資源の集合、及びオペランド
スタック（operand stack）を使用して、バーチャルマ
シンのステータスと呼ばれるプレゼンテーション装置の
ステータスを管理しつつ、文書データストリーム中のピ
クチャーまたはページセットの始まりと終わりを処理す
るための方法及び装置に関し、特に階層構造文書の処理
中に使用される状態変数の管理方法に関する。

【０００２】本発明は米国特許出願第０８／０８７，５
７１号（１９９３年７月２日受理，”Ｍethod and Ｓys
tem to Ｈandle Ｃontext of Ｉnterpretation in aＤo
cument Ｐrocessing Ｌanguage”）の一部継続出願であ
り、当該米国特許出願第０８／０８７，５７１号は米国
特許出願第０７／９３１，８０８号（１９９２年８月１
１日受理，”Ａ Ｍethod and Ｓystem to Ｈandle Ｄic
tionaryＧeneration and Ｃontext Ｄeclaration in a
Ｄocument ＰrocessingＬanguage”)の一部継続出願で
あり、当該米国特許出願第０７／９３１，８０８号は、
米国特許出願第０７／８７６,６０１号（１９９２年４
月３０日受理，”Ｍethod and Ａpparatus to Ｍanage
Ｐicture and Ｐageset for ＤocumentＰrocessin
g”)、及び米国特許出願第０７／８７６，２５１号（１
９９２年４月３０日受理，”Ｍethod and Ｓystem to
Ｈandle Ｉnclusion of ＥxternalＦiles into a Ｄocu
ment Ｐrocessing Ｌanguage”）の一部継続出願であ
り、当該各米国特許出願は引用により本明細書に組み込
まれる。

【０００３】

【従来の技術】１９７０年代初期のレーザプリンタの開
発により、文字データのみならず一般的なグラフィクデ
ータも含む文書を高品質かつ低コストで印刷する機会が
与えられた。コンピュータによりプリンタに対するコマ
ンドを制御する当初の方法は、ＤＩＡＢＬＯ（登録商
標）コマンドシーケンスに使用される種類のコマンドに
似たコマンド、いわゆる”エスケープシーケンス”（es
cape sequence）を採用していた。この種のコマンド
は、その前に特殊なバイト、一般にエスケープキャラク
タ（ASCII 27）、を置くことにより、普通のキャラクタ
データと区別された。この方法は、デイジーホイールプ
リンタやドットマトリクスプリンタには問題がないが、
必要条件が変化する可能性のある文書を印刷する目的に
は、あまり適さない。例えば、ニーズの変化や技術の進
歩に従い、プレゼンテーション装置のアップグレードが
必要になる。従来、この種のアップグレードには、プレ
ゼンテーション装置のプログラムコントローラの交換が
必要であった。少なくとも、プリンタの命令を格納した
新しいＰＲＯＭが必要になった。しかし、これは一時的
に変更する方法としては実用的ではない。いくつかの印
刷ジョブのために新しいＰＲＯＭを取り付け、その後に
元のＰＲＯＭまたは別の新しいＰＲＯＭと交換しなけれ
ばならないからである。このアップグレード方法は無駄
が多く、またプレゼンテーション装置のコントローラの
故障の増加を招く。

【０００４】エスケープシーケンスコマンドには、この
ような本質的な制約があるので、レーザプリンタ、その
他のページプリンタを制御するための様々なタイプの”
ページ記述言語”（ＰＤＬ）が開発された。これらのレ
ーザプリンタのバックワード互換性は、エスケープシー
ケンスコマンドをシミュレート可能にすることにより提
供された。現在用いられているページ記述言語の例とし
て、Ａdobe Ｓystems社のポストスクリプト（ＰostＳcr
ipt，登録商標）とＸerox社のインタープレス（Ｉnterp
ress，登録商標）がある。これ以外にもいくつかの権利
化されたＰＤＬが知られている。

【０００５】従来のあるページ記述言語は、オブジェク
トの処理のためのツールやシンタックスを提供したり、
またオペランドスタック類を利用できるようにする等に
よって、在来の標準的なエスケープシーケンスに対し様
々な改善をもたらした。さらに、これらページ記述言語
はスタック指向のプログラミング言語である。これらの
言語はまた、場合によって、プリンタの利用可能なリソ
ースにフォントやグラフィクイメージを追加する機能の
ように、プリンタの状態のダイナミックな変更を可能に
する。これらの特徴の一部について、Ａdobe Ｓystems
社の”PostScript Ｌanguage Ｒeference Ｍanual”及
び”PostScript ＬanguageＰrogram Ｄesign”（いずれ
もＡddison-Ｗesley Ｐublishing社発行）等の市販参考
書類に述べられている。他のＰＤＬも同様に様々な技術
書及び参考書、例えば Ｈarrington 他著”Ｉnterpres
s，Ｔhe Ｓource Ｂook ”（Ｓimon andＳchuster社,
１９８８）に述べられている。

【０００６】一つの標準化ページ記述言語が提案され、
国際標準化機構（ＩＳＯ）で国際規格として開発中であ
る。この提案は本願発明者もその一寄与者であるが、現
在、ＩＳＯの１セクションに草案として提出されてい
る。この草案は、ISO/IEC DIS10180”Ｉnformation Ｐr
ocessing Ｔext-Ｃommunication Ｓtandard ＰageＤesc
ription Ｌanguage”として知られて、ニューヨークの
米国規格協会（ＡＮＳＩ）で入手できる。

【０００７】従来のページ記述言語の多くは、様々な欠
点を持っている。例えば、ポストスクリプトの欠点の一
つは、文書のページ記述にリソース宣言（すなわち追加
フォント）や新しい辞書宣言を含めることができ、それ
を文書のどこにでも使用できることである。つまり、ポ
ストスクリプトでは構造が強制されないので、あるプリ
ンタが文書を印刷するために必要なリソースを持ってい
ることを確認するためには、文書全体を処理しなければ
ならない。この”前処理”を行なわないと、印刷プロセ
スのどの段階でも、終了間際でさえも、プリンタが文書
ページ記述のコマンドに対応できず文書の印刷を失敗す
る虞がある。

【０００８】ポストスクリプトを採用した従来システム
は、他にも問題点がある。例えば、文書のあるページを
印刷するためには、文書の当該ページより前の全ページ
のＰＤＬ記述全体を、各ページのプレゼンテーションの
前に読んで処理し、文書ページセットアップパラメータ
（すなわちリソース宣言、辞書定義等）の状態を調べる
必要が一般にあることである。別のいい方をすれば、印
刷コントローラプログラムは、全てのページのセットア
ップコマンドの影響を考慮するために、文書の初めから
指定ページまでのＰＤＬ記述全体を読まなければならな
い。このページセットアップのスキャン処理は、比較的
簡単ではあるが、プリンタで有効に利用可能なプロセッ
サ時間の相当量を必要とする。

【０００９】さらに、ポストスクリプトには、構造、プ
ロローグ（prologue）やデータ宣言の範囲（scope）を
処理するためのシンタックス（syntax）もセマンテック
ス（semantics）も定義されていない。規約は存在す
る。しかし、この規約に従わなくともよい。

【００１０】周知のゼロックス社のインタープレスシス
テムに関する１つの問題点は、その構造が入力データス
トリーム中の辞書定義を効率的に処理できないことであ
る。インタープレスは、プロローグ構造を即座に使用す
ることもできない。また、インタープレスの標準的なエ
ンコーディングはバイナリだけで、人間が読めるクリア
テキスト（clear text）ではない。

【００１１】

【発明が解決しようとする課題】本発明の目的は、一般
的には、前述したような問題点を解決もしくは改善し、
階層構造文書の効率的な処理を実現することにあり、本
発明の格別の目的は、階層構造文書の効率的処理を実現
するために、階層構造の文書の処理中に、該処理を実行
するバーチャルマシンの状態を定義する各種変数（状態
変数）を管理する好適な方法を提供することである。

【００１２】

【課題を解決するための手段】本発明によれば、例えば
ＩＳＯ／ＩＥＣＤＩＳ１０１８０（以下DIS 10180）に
定義されたようなページ記述言語の効率的な処理が可能
となる。

【００１３】最近制定されたDIS 10180 によれば、各文
書デーストリームはページセットまたはピクチャーのい
ずれかの構造で与えられる。ページセットエレメント及
びピクチャーエレメントは、定義及び宣言コマンドを含
む１つのオプションのプロローグ（prologue）と、１つ
のオプションのボディ（body）とからなる。ページセッ
トボディ(pageset body)はゼロ個以上のページセットま
たはピクチャーからなり、ピクチャーボディ（picture
body）はゼロ個以上のピクチャーまたはトークンシーケ
ンス（tokensequence）からなる。特定のトークンまた
は特定のイメージを必要なオペレータとともに定義する
コマンドを含むトークンシーケンスは、”コンテント”
（content）と呼ばれるのに対し、文書の他の要素は”
構造”（structure）と呼ばれる。構造は、コンテント
が適当な出力イメージを生成するための環境をセットア
ップする。ピクチャーまたはページセットの階層レベル
内のプロローグの影響が及ぶのは、そのピクチャーまた
はページセットの終わりまでである。したがって、文書
の階層構造中の１つのピクチャーのプロローグは、同レ
ベル以上の構造には影響を及ぼさないが、下の階層レベ
ルの構造には影響を及ぼす。本発明は、１つのスタック
及び様々なポインタを使用することにより、このような
階層ツリー構造をプロローグの範囲とともに効率的に操
作する。

【００１４】ツリー接続階層構造（tree-linked hierar
chical structure）は、文書の任意の部分の処理を当該
部分を直接的にアドレッシングして行なうことができる
という有利性があり、また、高い階層の部分の処理に、
階層ツリーの他の枝の他のアイテムを処理する必要がな
いという有利性がある。すなわち、文書のある特定部分
より上の階層ツリーに出現する構造定義しか処理する必
要がない。このことは、文書の処理効率の向上をもたら
し、またさらに、実際に文書の印刷を開始するに先だっ
て、印刷装置または表示装置で必要となるリソースのタ
イプを容易に決定できるようにする。後者のことは、様
々な装置による文書の印刷または表示の速度及び効率を
向上させる。

【００１５】文書の１つの階層レベルが処理される時に
は常に、この階層レベルに対応したピクチャー／ページ
セットスタック（picture／pageset stack）に１つのエ
ントリー（entry）がプッシュされる。ピクチャー／ペ
ージセットスタックの各エントリーは、プロローグデー
タ構造（prologue data structure）へのポインタと、
カレント解釈コンテキスト（current context of inter
pretation、以下 ”ＣＣＩ”）データ構造へのポインタ
とを持つ。文書もしくはファイルのコンテントの処理中
には必ずＣＣＩデータ構造が用いられる。ＣＣＩデータ
構造のエントリーは、文書もしくはファイルの構造の処
理中に修正可能であり、また、コンテントの処理中にも
修正可能である。しかしながら、コンテントは、ピクチ
ャー／ページセットプロローグデータ構造(picture／pa
geset prologue data structure)のエントリーを直接的
に修正することはできない。

【００１６】本発明の格別なる目的に関連し、１つの文
書の処理中に、該処理を実行しているバーチャルマシン
の状態を定義する変数が、１つの状態変数テーブル内に
定義される。状態変数テーブル内の状態変数は、様々な
処理コマンドにより修正することができる。

【００１７】１つの文書のプレゼンテーションの開始時
に１つのプロローグデータ構造が生成されるが、このプ
ロローグデータ構造は、当該文書の最初の階層レベルに
関しては、デフォルト（default）の状態変数テーブル
へのポインタを持っている。この文書のコンテント部分
（トークンシーケンス）が処理される時に、１つのカレ
ント解釈コンテキスト（ＣＣＩ）データ構造が生成され
るが、このＣＣＩデータ構造は、それ自体の状態変数テ
ーブルへのポインタを持ち、この状態変数テーブルは初
めはデフォルト状態変数テーブル内の状態変数と同じ状
態変数を持っている。当該トークンシーケンスの直ぐ上
位の構造エレメントが終わると、ＣＣＩデータ構造は、
必要ならば若干の処理の後に、削除される。

【００１８】次の階層レベルの処理時に、その直ぐ上位
の階層構造エレメントのためのＣＣＩデータ構造が存在
するならば、当該次の階層レベルに対するプロローグデ
ータ構造の状態変数へのポインタは、当該上位エレメン
トに対するＣＣＩデータ構造内の状態変数テーブルへの
ポインタと等しい内容に設定される。直ぐ上位の階層構
造エレメントに対するＣＣＩデータ構造が存在しないと
きは、当該次の階層レベルに対するプロローグデータの
状態変数テーブルへのポインタは、当該上位エレメント
に対するプロローグデータ構造内の状態変数テーブルへ
のポインタと等しい内容に設定される。

【００１９】トークンシーケンスの処理中に状態変数が
修正され、また、その直ぐ上位の構造エレメントがセッ
トアッププロシージャ（setup procedure）であれば、
このセットアッププロシージャの完了時に、当該トーク
ンシーケンスのＣＣＩデータ構造内の状態変数テーブル
へのポインタが、当該状態変数テーブル内のポインタへ
コピーされる。当該直ぐ上位の構造エレメントがセット
アッププロシージャでなければ、状態変数の修正は現ト
ークンシーケンスエレメントに対して使用されることを
意図されていたに過ぎないので、当該状態変数に対して
なされた変更はセーブされない。

【００２０】

【作用】本発明の状態変数の管理構成及び他の関連した
構成を上に述べたが、それによれば、階層構造文書に関
する従来技術の問題点を解決もしくは改善し、階層構造
文書の処理の一層の効率化・高速化を実現することがで
きるようになる。

【００２１】

【実施例】以下、添付の図面を参照して、本発明の実施
例について詳細に説明する。なお、添付図面において、
いくつかの図にわたって用いられる同一の参照番号は、
同一または対応した部分を意味する。

【００２２】図１及び図２に、２つの文書と、それらの
構造エレメントすなわち標準ページ記述言語（”ＳＰＤ
Ｌ”）で定義されたピクチャー及びページセットが示さ
れている。

【００２３】ＳＰＤＬでは、文書は単一のピクチャーま
たは単一のページセットとして定義できる。ページセッ
トは追加のページセットまたはピクチャーより構成する
ことができる。１つのピクチャーは、１ページを超える
ことはできないし、あるページからもう１つのページへ
跨ることもできない。

【００２４】図１は４ページの１つのページセット（ピ
クチャーの最高レベル）より構成された文書を示す。図
２はテキストと２つのピクチャーを含む単一ページ文書
を示す。図２の文書は、１ページだけであるので、１ペ
ージのページセットとして表現することもできるし、１
つのピクチャーとして表現することもできる。

【００２５】図３はＳＰＤＬ文書の階層構造の説明図で
ある。図３に示された文書は、その最高位の階層構造エ
レメントとしてページセット１０を含んでいる。このペ
ージセット１０はページセット１２とピクチャー１４と
からできている。さらに、このページセット１２はピク
チャー１６，１８，２０からなっている。

【００２６】例を用いて階層レベルを定義すると、ペー
ジセット１２は、ページセット１０より低い階層レベル
にあるがピクチャー（ページ）１６，１８，２０より高
い階層レベルにある。各階層エレメントは、普通、それ
より低いレベルの階層エレメント及び／または１つ以上
のトークンシーケンスエレメントから構成される。トー
クンシーケンスは、コンテントを含む特別種類の構造エ
レメントである。コンテントとは、文書として印刷また
は表示されるものの実体である。トークンシーケンス
は、例えば、図、テキストまたはイメージを記述する。
トークンシーケンスにより図、テキストまたはイメージ
等のコンテントを表現することは、非常に高速かつ効率
的な文書のプロゼンテーション処理を可能にし、殊に、
文書の一部だけのプレゼンテーションをしようとする時
には、対象外のページのトークンシーケンスを処理しな
くてもよいので、高速かつ効率的な処理が可能である。
ピクチャー１４，１６，１８，２０はそれぞれ、多分、
少なくとも１つのトークンシーケンスエレメントを持っ
ているであろう。

【００２７】図４に示す如く、ピクチャー及びページセ
ットは”文法”(grammar) が設定されている。ピクチャ
ーは、１つのオプションのプロローグ及び１つのオプシ
ョンのピクチャーボディ(picture body)を持つものと定
義されている。ページセットは、１つのオプションのプ
ロローグ及び１つのオプションのページセットボディ(p
ageset body)を持つものと定義されている。オプション
のプロローグは、文書を処理するために処理システムに
より使用される様々なパラメータを定義するもので、外
部宣言（external declaration)、情報宣言（informati
ve declaration)、リソース宣言（resource declaratio
n）、文書プロダクション命令宣言（document producti
on instruction declaration）、コンテキスト宣言、辞
書生成宣言、セットアッププロシージャ等のエレメント
を含む。プロローグ中のこれらエレメントは全てオプシ
ョンであり、また、同一アイテムが多重的に存在しても
よいという意味で事実上は繰り返し可能である。したが
って、１つのプロローグに関し複数のレベルが存在して
もよく、これらの多重的ケースは後述のように処理可能
である。

【００２８】図５は一例としての２ページ文書の構造エ
レメントの詳細説明図である。この文書は、プロローグ
５１とページセットボディ６０とを持つ１つのページセ
ット５０からなっている。図４に関して説明したよう
に、プロローグは、オプションの構造エレメントで、ピ
クチャーまたはページセットのための様々なパラメータ
を定義する。プロローグ５１は４つの従属要素、すなわ
ちリソース宣言５２、辞書ジェネレータ（dictionary g
enerator）５４、辞書ジェネレータ５６及びセットアッ
ププロシージャ５８、並びに対応したトークンシーケン
スを含んでいる。リソース定義（resource definitio
n）５２は、トークンシーケンス５３がプレゼンテーシ
ョンのために使用されるリソースを定義する（例えば文
書に使用されるフォームを定義する）コンテントを含ん
でいることを示す構造エレメントである。

【００２９】辞書ジェネレータ５４は、トークンシーケ
ンス５５が１つの辞書を定義することを示す。同様に、
辞書ジェネレータ５６は、トークンシーケンス５７が１
つの辞書を定義することを示す。辞書定義は、順序付け
られた、キー（key）と値（value）のペアを含む。コン
テント中にキーが見つかった時には、辞書から得られた
当該キーに対応の値が当該キーの代わりに用いられる。
辞書内の値エントリーは整数、実数、プロシージャまた
は他の任意の型の値にすることができる。辞書ジェネレ
ータにより生成される辞書は、後述のように読み出し専
用のコンテント辞書（content dictionary）となる。

【００３０】セットアッププロシージャ（setup proced
ure）５８は、コンテントの処理時に用いられる様々な
状態変数を初期化する。代表的な状態変数は、カレント
色（current_color）、カレント・フォント（current_f
ont）及びカレント位置（current_position）等の変数
である。セットアッププロシージャは、ユーザ辞書のコ
ンテントを必要に応じ変更するためにも用いられる。ユ
ーザ辞書は、コンテキスト辞書及びコンテント辞書をサ
ーチして目的のキーが見つからなかった場合に、その後
でサーチされるリード／ライト（read／write）辞書で
ある。

【００３１】ページセットボディ６０は、ピクチャー６
１，７５を持つ２ページを含む。ピクチャー６１はそれ
自体のプロローグ６２を持つが、このプロローグ６２は
ピクチャー６１だけに対するパラメータを定義しピクチ
ャー７５には影響を及ぼさない。プロローグ６２はコン
テキスト宣言（context declaration）６３とその辞書
識別子（dictionary identifier）６４、辞書ジェネレ
ータ６５とそのトークンシーケンス６６、セットアップ
プロシージャ６７とそのトークンシーケンス６８を含
む。ピクチャー６１のピクチャーボディ６９はトークン
シーケンス７０，７４を含み、ピクチャー７１はピクチ
ャーボディ７２とトークンシーケンス７３を持つ。この
文書の第２ページはピクチャー７５を持ち、このピクチ
ャー７５のピクチャーボディ７６はトークンシーケンス
７７を持つ。

【００３２】コンテキスト宣言６３は、構造のより高い
階層レベルで定義されるコンテキスト辞書の操作を指示
する。辞書識別子６４のような辞書識別子がコンテキス
ト宣言の後に続くときは、この辞書識別子がコンテキス
ト辞書のサーチ順の変更方法を指示する。コンテキスト
宣言の後に辞書識別子エレメントが来ないときは、辞書
の定義されたサーチ順は廃棄され、当該階層レベルに対
するコンテキスト辞書のサーチはなされず、ユーザ辞書
及びシステム辞書がコンテキストスタックのボトムに入
れられる。辞書のサーチ順はコンテキスト辞書スタック
データ構造を用いて定義されるが、その詳細は後述す
る。

【００３３】なお、図５はＳＰＤＬ文書の構造の概念的
な記述だけを示したものであり、実際のＳＰＤＬ文書は
それとは異なった記述を用いることもあることを理解す
べきである。

【００３４】さて、図６に示した本発明の典型的なハー
ドウエア構成について説明すると、システムは一般的
に、少なくともＣＰＵ１０２、メモリ（一般にＲＯＭ１
０６とＲＡＭ１０４の形をとる）、文書データストリー
ムを受信する入力／出力手段、及び最終出力の表示／印
刷のための手段を備える。最終的な出力イメージはイメ
ージラスター装置によって作られるが、このイメージラ
スター装置はＣＰＵに直接接続されてもよく、また特有
のネイティブ描画形式を持っていてもよい。後者の場合
には当然に、文書データストリームを個々の描画装置の
持つ形式の描画コマンドへ変換する必要がある。一例と
してポストスクリプト形式の装置がシステムに接続され
る場合を挙げることができよう。この場合、本発明で
は、システムは要求された時に文書記述データストリー
ムを送って処理し、ポストスクリプト言語へ変換した後
のデータを印刷する。これは当然、既存プリンタのサポ
ート方法を考慮している。

【００３５】前述のように、文書は構造とコンテントを
含んでいる。図７は、ＳＰＤＬ文書の構造とコンテント
を処理して出力イメージに変換するためのシステムの説
明図である。図６のＣＰＵ１０２のような単一のＣＰＵ
を使用して文書を処理することができるが、図７には、
独立した構造プロセッサ１５２、コンテントプロセッサ
１６２、及び、処理後の構造及びコンテントを結合して
出力イメージ１６６にするイメージャ（imager）１６４
が含まれている。図７に示した処理モデルを、以後、バ
ーチャルマシンと呼ぶ。

【００３６】図７を詳しく見ると、例えばワードプロセ
ッサやページ記述ジェネレータ（page description gen
erator）によって作成されたＳＰＤＬ文書１５０は、既
知の一般的な文法解析（parsing）プロセスにより文法
解析をされた後に、構造プロセッサ１５２によって解釈
される。説明の簡略化のため、文法解析プロセスの詳細
はここでは述べない。コンテントを含む構造エレメント
であるトークンシーケンスが構造プロセッサ１５２によ
り処理される時に、このトークンシーケンスのコンテン
トがライン１５６に沿ってコンテントプロセッサ１６２
へ送られる。なお、ＳＰＤＬ文書の全体ではなく、ある
ページだけを出力したいときは、出力されないトークン
シーケンスのコンテントはコンテントプロセッサ１６２
へ送られないことに注意されたい。こうすることで、処
理時間が従来技術のシステムより減る利点がある。

【００３７】コンテントプロセッサ１６２は、コンテン
トの処理中に、当該文書の構造により定義された様々な
パラメータを知る必要がある。これを達成するため、構
造プロセッサ及びコンテントプロセッサは、ＣＣＩデー
タ構造１５４及びピクチャー／ページセットプロローグ
データ構造１５８（picture／pageset prologue datast
ructure）をアクセス可能である。ＣＣＩデータ構造１
５４は、それを通じて構造プロセッサとコンテントプロ
セッサとが通信をするところの１つの構造である。ＣＣ
Ｉデータ構造が存在するのは、コンテントを含む構造エ
レメントの処理中である。その構造エレメントの階層レ
ベルの処理が終了すれば、一般に、ＣＣＩデータ構造中
の情報が構造プロセッサへ返され、ＣＣＩデータ構造は
構造プロセッサによって削除されるかセーブされる。例
えば図５において、プロローグ５１はトークンシーケン
ス５３，５５，５７，５９を含んでいる。１つのトーク
ンシーケンスが処理される時には必ず、１つのＣＣＩデ
ータ構造が生成される。このトークンシーケンスの処理
の終了時に、ＣＣＩデータ構造に格納されていた情報は
返されてピクチャー／ページセットプロローグデータ構
造に接続される。

【００３８】カレント解釈コンテキスト（current cont
ext of interpretation）は、利用可能なリソースの集
合とバーチャルマシンの状態からなる。この利用可能な
リソースの集合は、あるコンテントエレメントの処理に
利用できるリソースの集まりである。バーチャルマシン
の状態は、コンテキストスタック、オペランドスタック
及び状態変数である。バーチャルマシンの状態を構成す
るこれらのエレメントの詳細については後述する。

【００３９】コンテントプロセッサ１６２によりテキス
トまたはイメージのコンテントを処理している時に、構
造プロセッサ１５２よりライン１６０を通じて、処理後
の文書コンテント及び印刷命令が送出されるが、これら
はイメージャ１６４において結合され、イメージャは出
力イメージ１６６を出力する。

【００４０】図７の処理モデルは１個のＣＣＩデータ構
造と１個のピクチャー／ページセットプロローグデータ
構造しか示していないが、実際には構造の各レベルがそ
れ自体のＣＣＩデータ構造とピクチャー／ページセット
プロローグデータ構造を持っている。構造の様々なレベ
ルを管理するために、図８に示すスタック２０２のよう
なスタックが使用される。

【００４１】このスタックのボトムエントリー２１０
は、文書の処理中に常に存在する。ＣＣＩデータ構造へ
のポインタ２１４（pointer to ＣＣＩ data structur
e）は初めはヌル（null）を指している。それというの
も、コンテントを含むトークンシーケンスはまだ全く出
現していないので、カレント解釈コンテキスト（ＣＣ
Ｉ）の必要性がないからである。ＣＣＩデータ構造は、
トークンシーケンスエレメントの処理中にのみ使用さ
れ、構造プロセッサとコンテントプロセッサとの間の通
信リンクとして利用される。ボトムスタックエントリー
２１０のプロローグデータ構造へのポインタ２１２（po
inter to prologue data structure）は、プロローグデ
ータ構造中の値が文書内のエレメントにより変更される
までは、ピクチャー／ページセットプロローグデータ構
造のデフォルト値を指している。

【００４２】ＳＰＤＬ文書内のエレメントはまずパーサ
ー（parser）２００によって処理される。このパーサー
２００は、ＳＰＤＬ文書のデータストリームを受け取
り、同データストリーム中の様々なトークンを識別す
る。トークンであるピクチャービギン（picture_begi
n）、ピクチャーエンド（picture_end）、ページセット
ビギン（pageset_begin）及びページセットエンド（pag
eset_end）は、階層構造レベルの変化を指示する。パー
サー２００は、これらの構造エレメントを認識した時
に、データストリームの処理を扱うための適当なルーチ
ンをコールする。ソフトウエア、ハードウエアまたは両
者の組合せによる通常の種類の文法解析を用いることが
できる。パーサー２００は、例えば、図６のＣＰＵ１０
２上に実現してもよい。パーサー２００はまた、図７の
構造プロセッサ１５２の一部にしてもよい。さらに、こ
の文法解析を、例えば独立したプロセッサで行なっても
よい。説明の簡略化のため、文法解析メカニズムに関す
るこれ以上の説明は行なわない。

【００４３】図８のエレメント１８０〜１９０は、１つ
のＳＰＤＬ文書の様々な階層構造エレメントを表わして
いる。これらの構造エレメントは単に説明のためのもの
であって、簡略化した文書を示している。実際のＳＰＤ
Ｌ文書は、恐らく、トークンシーケンスのみならにず他
の構造エレメントも含むであろう。このエレメント１８
０〜１９０を含む文書の処理の開始前は、ピクチャー／
ページセットスタック２０２は空である。この文書を処
理中にピクチャービギン１８０に出会うと、プロローグ
データ構造へのポインタ及びＣＣＩデータ構造へのポイ
ンタを含む１つのエントリーが、ピクチャー／ページセ
ットスタック２０２にプッシュされる。ピクチャーエン
ド１８２に出会うと、スタック２０２上の上記エントリ
ーがポップされ、ピクチャー／ページセットスタック２
０２は再び空になる。

【００４４】次に、ページセットビギン１８４に出会
う。プロローグデータ構造へのポインタ２１２及びＣＣ
Ｉデータ構造へのポインタ２１４を含むエントリー２１
０が、ピクチャー／ページセットスタックにプッシュさ
れる。トークンシーケンスのコンテントに出会い、これ
がページセットビギンのレベルにあれば、ＣＣＩデータ
構造へのポインタ２１４は、ヌルを指す状態から、当該
トークンシーケンスに応じて生成されたＣＣＩデータ構
造を指すように変更される。ページセットビギン１８４
の後に、ピクチャービギン１８６に出会う。スタック２
０２のトップ、つまりエントリー２１０の上に、エント
リー２０４がプッシュされる。このエントリー２０４
は、プロローグデータ構造へのポインタ２０６と、ＣＣ
Ｉデータ構造へのポインタ２０８を含む。ピクチャービ
ギン１８６に対応したピクチャーが終わった後、ピクチ
ャーエンド１８８がスタック２０２よりエントリー２０
４をポップする。これでスタックに残っているエントリ
ーは、エントリー２１０だけである。ページセットエン
ド１９０がスタック２０２よりエントリー２１０をポッ
プする。

【００４５】簡単にするため、すべての文書のピクチャ
ー／ページセットスタックを常に参照番号２０２で示
し、最高位の階層構造エレメントがピクチャー／ページ
セットスタック２０２のエントリー２１０に対応し、ま
た、エレメント２０４が任意の文書の任意の次階層レベ
ルに対応するものとする。

【００４６】ＳＰＤＬ文書の実際のクリアテキストエン
コーディング(clear text encoding）においては、構造
タームは、始まりが＜picture＞、＜pageset＞のように
記され、他方、終わりを示すためには＜／picture＞、
＜／pageset＞のように記される。ＳＰＤＬにおけるク
リアテキストエンコーディングは、ＩＳＯドキュメント
文書８８７９：１９８６で定義され、ここに引用するこ
とにより本明細書に組み込まれるところの”ＳＧＭＬ”
(Ｓtandard Ｇeneralized Ｍarkup Ｌanguage)に従って
いる。さて、ＳＰＤＬ文書は、クリアーテキスト形式に
対立する形式であるバイナリ形式で表現することもでき
る。文書データストリームのバイナリエンコーディング
方式は、ピクチャー及びページセットのビギン（begi
n）及びエンド（end）条件の識別のために、特殊なタグ
をバイトカウント（byte count）とともに用いることが
できる。バイナリのＳＰＤＬ文書は、ＩＳＯ／ＩＥＣド
キュメント８８２４：１９９０に定義された”ＡＳＮ．
１”（Ａbstract Ｓyntax Ｎotation Ｏne）に従ってエ
ンコードされ、ＩＳＯ／ＩＥＣ８８２５：１９９０に定
義されたベーシック・エンコーディング規約に従う。な
お、ＩＳＯ／ＩＥＣ８８２４：１９９０及びＩＳＯ／Ｉ
ＥＣ８８２５：１９９０は、引用により本明細書に組み
込まれる。

【００４７】図９は、図８のピクチャー／ページセット
スタック２０２、並びに、プロローグデータ構造へのポ
インタ２０６及びＣＣＩデータ構造へのポインタ２０８
により指示されたデータ構造を示す。ピクチャー／ペー
ジセットプロローグデータ構造２２０及びＣＣＩデータ
構造２４０はそれぞれ、図７に示されているピクチャー
／ページセットプロローグデータ構造１５８及びＣＣＩ
データ構造１５４に相当する。

【００４８】ピクチャー／ページセットプロローグデー
タ構造２２０を見ると、階層構造におけるあるページセ
ットレベル（pageset level）がエントリー２２１に格
納されており、また、あるピクチャーレベル（peicture
level）がピクチャーレベルエントリー２２２に格納さ
れている。一連のポインタ２２３，２２４，２２５，２
２６，２２７，２２８，２２９，２３０，２３１は、外
部宣言（externaldeclaration）へのポインタ２２３、
情報宣言（informative declaration）へのポインタ２
２４、リソース定義（resource definition）へのポイ
ンタ２２５、リソース宣言(resource declaration）へ
のポインタ２２６、コンテキスト宣言（context declar
ation）へのポインタ２２７、辞書ジェネレータ（dicti
onarygenerator)へのポインタ２２８、状態変数テーブ
ル(state variable table)へのポインタ２２９、マシン
状態(machine state）へのポインタ２３０、ユーザ辞書
リンク(user dictionary link)へのポインタ２３１とい
うように、様々なアイテムの所在を明らかにするもので
ある。ピクチャー／ページセットプロローグデータ構造
２２０のアイテム２３２は、座標系の初期変換（initia
l transformation）を格納している。

【００４９】ＣＣＩデータ構造２４０はスタックエレメ
ント２０４のＣＣＩデータ構造へのポインタ２０８によ
り指示され、トークンシーケンスエレメントの処理中に
生成されるものであるが、これは文書のプレゼンテーシ
ョン処理中にコンテントプロセッサ及び構造プロセッサ
により用いられる様々なパラメータを格納している。Ｃ
ＣＩデータ構造２４０中のエレメントは、リソース宣言
へのポインタ２４２、コンテキストスタック（context
stack）へのポインタ２４４、オペランドスタック（ope
rand stack）へのポインタ２４６、状態変数テーブルへ
のポインタ２４８７、マシン状態へのポインタ２５０、
ユーザ辞書リンクデータ構造（userdictionary link da
ta structure）へのポインタ２５２からなる。処理のた
めに生成されたＣＣＩデータ構造は一時的なデータ構造
と考えてよく、コンテント部（すなわちトークンシーケ
ンスエレメント）に始めて出会った時に生成され、１つ
のトークンシーケンスが終了した時及びそのトークンシ
ーケンスの階層構造エレメントが終了した時に破棄され
る。

【００５０】図１０に典型的な状態変数テーブル３００
を示すが、同テーブルはＣＣＩデータ構造のポインタ２
４８及び／またはピクチャー／ページセットプロローグ
データ構造のポインタ２２９によって指示される。この
テーブル内の状態変数は、コンテントの処理用のグラフ
ィック変数を含む様々なパラメータを定義するために用
いられる。本発明を実際に実施する場合には、おそら
く、図１０の状態変数テーブル内に示された状態変数よ
りも多い状態変数が格納されることになろう。

【００５１】さて、文書の処理の詳細について述べる。
図１１及び図１２は、ＳＰＤＬ文書中のピクチャーの先
頭に出会った時に実行されるステップ群を示している。
図１１はピクチャー／ページセットプロローグデータ構
造を扱い、図１２は状態変数の処理を扱う。

【００５２】ピクチャーレベル（Ｐic_level）及びペー
ジセットレベル（ＰＳ_level）等のグローバル変数はど
のルーチンでも利用できる。一方、図９に見られるピク
チャー／ページセットスタック２０２中のエントリ２０
６で指示されたプロローグデータ構造２２０内に格納さ
れた変数であるピクチャーレベル（picture_level）２
２２とページセットレベル（pageset_level）２２１
は、ローカル変数である。図１１及び図１２のルーチン
は、例えば、処理中に、図５に示した文書のピクチャー
６１，７１または７５に出会った時に実行される。

【００５３】新しい文書データストリームの処理の初期
化時または”電源投入（power up）”時にＰic_levelが
ゼロに初期化される。ステップ４０１において、処理さ
れる階層レベルが最高の階層レベルでないと判定すると
（すなわち、処理の開始時、及び、上のレベル全てが処
理済みの場合）、処理の流れはステップ４０２に進み、
エラーチェックが行なわれる。何か問題が起こると、ス
テップ４０３でエラーフラグがセットされ、続いてステ
ップ４０４で図６のＣＰＵ１０２による他の処理へリタ
ーンする。問題が起こらなければ、処理は継続しステッ
プ４０５においてグローバル変数Ｐic_levelがインクリ
メントされる。

【００５４】ページの選択が必要な時には、ステップ４
０５の後に次の処理 If（Ｐic_level==１） then page-number is incremented が挿入される。この処理の内容は次のとおりである。ス
テップ４０５の後で、Ｐic_levelが１であるか調べられ
る。それが１ならば、”ピクチャービギン”（picture
begin）はピクチャー階層の最高レベルの始まり、つま
りページの開始を示している。したがって、page-numbe
rはインクリメントされる。この”page-number”は、電
源投入初期化時または処理システムのリセット時に、ゼ
ロに初期化される。”page-number”は、どのルーチン
によってもアクセス可能なグローバル変数であるのが理
想的である。Ｐic_levelはグローバル変数であるので、
レベル番号は他の全てのルーチンに適用され、多重レベ
ルも実現可能である。

【００５５】ステップ４０６で、図９のピクチャー／ペ
ージセットプロローグデータ構造２２０に対するメモリ
割り当てが起こる。このピクチャー／ページセットプロ
ローグデータ構造のアドレスへのポインタが、ステップ
４０６でスタック２０２にプッシュされる。ステップ４
０８では、まだトークンシーケンスに出会っておらず、
したがって処理すべきピクチャービギンに対するＣＣＩ
データ構造は存在しないので、ピクチャー／ページセッ
トスタックのＣＣＩデータ構造へのポインタにヌルがプ
ッシュされる。ステップ４０９において、プロローグデ
ータ構造２２０のピクチャーレベル（picture_level）
及びページセットレベル（pageset_level）がセットさ
れる。そして、処理の流れはプロローグデータ中のエン
トリーの処理及び状態変数処理のための図１２のフロー
チャートへ進む。

【００５６】図１２の最初のステップ４２０で、処理中
のピクチャービギンがピクチャー／ページセットスタッ
クの最初のエントリであるか調べる。そうであれば、ス
テップ４２２へ進み、割り当てられたプロローグデータ
構造の状態変数テーブル・ポインタは、デフォルトの状
態変数テーブルを指すように設定される。このステップ
は最初の階層レベルの処理中に行なわれので、使用する
必要のある状態変数で、それ以前に修正されたものはな
い。ステップ４２４において、割り当てられたプロロー
グデータ構造中のポインタは、前に定義された状態変数
・ポインタを除いて、全てヌルを指すように設定され
る。

【００５７】ステップ４２０で処理中のエントリーがピ
クチャー／ページセットスタックの最初のエントリーで
ないと判定したときは、処理の流れはステップ４２６に
進み、割り当てられたプロローグデータ構造中の、状態
変数テーブル・ポインタ以外のポインタは、ピクチャー
／ページセットスタックの１つ下のエントリーに関する
プロローグデータ構造と同じアドレスを指し示す。な
お、この下のスタックエントリーは上の階層レベルに対
応する。というのは、より低い階層レベルはピクチャー
／ページセットスタックのトップにプッシュされるから
である。処理の流れはステップ４２８に進み、ピクチャ
ー／ページセットスタックの該下のエントリーのＣＣＩ
データ構造へのポインタがヌルに設定されているか調べ
られる。ヌルに設定されているときは、処理の流れはス
テップ４３０へ進み、現プロローグデータ構造中の状態
変数テーブルへのポインタは、１スタックレベル下のプ
ロローグデータ構造の状態変数テーブルと同じアドレス
を指すように設定される。ステップ４２８で、ピクチャ
ー／ページセットスタック中の下のエントリーのＣＣＩ
データ構造へのポインタがヌルでないと判定したとき
は、この現プロローグデータ構造の状態変数テーブルへ
のポインタは、下のレベルのＣＣＩデータ構造の状態変
数テーブルと同じアドレスを指すように設定される。

【００５８】ステップ４３２より、処理の流れはステッ
プ４３４へ進み、現在の変換の値が、割り当てられたプ
ロローグデータ構造の初期変換エントリーにコピーされ
る。ステップ４３６でピクチャービギンの処理が完了
し、文書の次の処理のため構造プロセッサへリターンす
る。

【００５９】ページセットビギン（pageset bigin）の
ために行なわれる処理は、図１１及び図１２に示した処
理と同様であるが、いくつかの小さな変更がある。これ
らの変更としては、例えば、ピクチャーレベル（pictur
e_level）がＰic_levelと等しいか調べる代わりに、ピ
クチャーレベル及びＰic_levelが共にゼロであるか調べ
なければならない。さらに、ステップ４０５は、Ｐic_l
evelをインクリメントする代わりにＰＳ_levelをインク
リメントするように変更される。図１２の処理は、ペー
ジセットビギンに対しても全く同一でよい。

【００６０】図１３は、トークンシーケンスに出会った
時に文書の、ＣＣＩデータ構造を持つ直ぐ上の階層レベ
ルが存在しない場合に、ＣＣＩデータ構造を生成するた
めに用いられるプロセスのフローチャートを示す。図１
３に示したＣＣＩデータ構造生成用プロセスは、例え
ば、図５に示した文書のトークンシーケンス５３，５
５，５７，５９，６６，６８，７０，７３，７７が処理
される時に実行される。トークンシーケンス７４は、ト
ークンシーケンス７０により生成されたＣＣＩデータ構
造を用いるので、ＣＣＩデータ構造を生成しない。

【００６１】トークンシーケンスエレメントに出会い、
かつピクチャー／ページセットスタックのトップエント
リーがヌルを指している時に、ＣＣＩデータ構造を生成
するために、構造プロセッサは図１３のステップ６０２
をコールする。ステップ６０４は、図９に示されたＣＣ
Ｉデータ構造２４０のような新しいＣＣＩデータ構造の
ためにメモリを割り当てる。この生成されたデータ構造
のアドレスはアドレスポインタＰＴＲ_ＣＣＩとして記
憶され、ステップ６０６は、このポインタＰＴＲ_ＣＣ
ＩをＣＣＩデータ構造へのポインタへ、例えば図９のピ
クチャー／ページセットスタック２０２のロケーション
２０８へ書き込む。ステップ６０８は、ＣＣＩデータ構
造に対する状態変数テーブルを生成し、この状態変数テ
ーブルのアドレスを状態変数テーブルへのポインタへ、
例えばＣＣＩデータ構造２４０のポインタ２４８へ書き
込む。次にステップ６１０において、ピクチャー／ペー
ジセットプロローグデータ構造２２０の状態変数テーブ
ルへのポインタ２２９により指示された状態変数テーブ
ルの値が、ＣＣＩデータ構造の指示された状態変数テー
ブルへコピーされる。

【００６２】ステップ６１２は、ＣＣＩデータ構造２４
０内の様々なポインタの値を、ピクチャー／ページセッ
トプロローグデータ構造２２０内の対応エントリーに基
づいて割り付ける。すなわち、リソース宣言へのポイン
タ２２６をＣＣＩデータ構造のポインタ２４２へコピー
し、コンテキスト宣言へのポインタ２２７をＣＣＩデー
タ構造のポインタ２４４へコピーし、マシン状態へのポ
インタ２３０をＣＣＩデータ構造の同ポインタ２５０へ
コピーし、ユーザ辞書リンクへのポインタ２３１をＣＣ
Ｉデータ構造のポインタ２５２へコピーする。

【００６３】最後にステップ６１４は、トークンシーケ
ンスより上位の構造エレメントに基づいて適当なオペラ
ンドスタックを作成する。本ステップは、ＣＣＩデータ
構造のオペランドスタックへのポインタ２４６に対する
ヌルの書き込み、あるいは他のポインタ値の書き込みを
含むこともある。そして、ステップ６１６で処理流れは
構造プロセッサへ戻る。

【００６４】図１３のフローチャートに示されたプロセ
スは、トークンシーケンスが終わった時に、必要なら、
ＣＣＩデータ構造の値がピクチャー／ページセットプロ
ローグデータ構造へコピーされると仮定している。しか
し、トークンシーケンス（例えば図５のトークンシーケ
ンス７０）は、文書の階層レベルが１レベル下がった時
（例えばピクチャー７１に出会った時）に、そのＣＣＩ
データ構造が破棄されないことがある。

【００６５】この場合、ピクチャー７１は図１１及び図
１２に示したプロセスを実行させる。図１２のステップ
４２８に来た時に、トークンシーケンス７０のためのＣ
ＣＩデータ構造は破棄されてないので、ピクチャー／ペ
ージセットスタック内のトップエントリーの下のエント
リーに対するＣＣＩデータ構造中のポインタはヌルでは
ないと判定される。したがって、ステップ４３２が実行
され、当該新プロローグデータ構造中の状態変数テーブ
ルへのポインタを、スタックの下のエントリーに対する
ＣＣＩデータ構造の状態変数テーブルへのポインタと等
しい値に設定する。その結果、万一、トークンシーケン
ス７０より後でトークンシーケンス７４より前の何等か
のエレメントにより状態変数が修正されても、ピクチャ
ー７１用に生成された状態変数は修正されず、そして、
トークンシーケンス７０の処理時に用いられる状態変数
テーブルは修正されない。

【００６６】図５に戻って、それぞれのレベルに対する
ピクチャー／プロローグデータ構造及びＣＣＩデータ構
造を指し示す様々なレベルのピクチャー／ページセット
スタックを生成する例について述べる。図５のページセ
ット５０に出会った時に、図１１及び図１２に示された
ピクチャー用プロセスと類似したページセット用プロセ
スがコールされ、ピクチャー／ページセットスタックに
対して最初のエントリー（図９のピクチャー／ページセ
ットスタック２０２のエントリー２１０に対応する）が
プッシュされる。リソース定義５２はトークンシーケン
ス５３を含み、同トークンシーケンスはＣＣＩデータ構
造を生成させ、同データ構造はポインタ２１４により指
し示されることになる。トークンシーケンス５３が終わ
ると、ＣＣＩデータ構造へのポインタ２１４はヌルを指
すように設定され、ＣＣＩデータ構造は構造プロセッサ
が必要な情報を獲得した後に破棄される。同様に、トー
クンシーケンス５５，５７，５９に出会った時に、各ト
ークンシーケンスに対してＣＣＩデータ構造が生成さ
れ、これはトークンシーケンスの終わりで構造プロセッ
サが必要な情報を獲得後に破棄される。

【００６７】セットアッププロシージャ５８，６７に対
して、構造プロセッサは返されたＣＣＩの状態変数テー
ブルを取得し、同テーブルへのポインタにより、プロロ
ーグデータ構造中の状態変数テーブルへのポインタを置
き換える。状態変数の管理のために用いられる関連した
データ構造の操作に関する説明は、図３８乃至図４２に
より述べる。

【００６８】ピクチャー６２に出会った時に、同ピクチ
ャーは低い階層レベルであるので、ピクチャー／ページ
セットスタック２０２に対しエントリー２０４がプッシ
ュされる。トークンシーケンス６６が処理されている時
にＣＣＩデータ構造が生成され、これはトークンシーケ
ンス６６の終わりで、構造プロセッサが必要情報を取得
後に破棄される。同様の処理が、トークンシーケンス６
８に対しても行なわれる。

【００６９】トークンシーケンス７０は、他のトークン
シーケンス同様、ＣＣＩデータ構造を生成させる。しか
し、トークンシーケンス７０の下にピクチャー７１があ
るので、トークンシーケンス７０に対応したＣＣＩデー
タ構造は、トークンシーケンス７０の処理の終わりで破
棄されず、メモリに残る。ピクチャー７１は第３の階層
レベルを生成させ、第３のエントリーがピクチャー／ペ
ージセットスタック２０２にプッシュされる。トークン
シーケンス７３は、ピクチャー／ページセットスタック
の第３エントリーに対するＣＣＩデータ構造を生成させ
る。トークンシーケンス７３の終了時に、第３エントリ
ーのＣＣＩデータ構造は破棄され、階層レベルは再びピ
クチャー６１に対応した第２レベルへと変化する。した
がって、トークンシーケンス７０用に元々生成されたＣ
ＣＩデータ構造は、トークンシーケンス７４用に再び使
用される。トークンシーケンス７４が終わった時に、対
応のＣＣＩデータ構造は破棄される。また、トークンシ
ーケンス７４が終わった時に、ピクチャー６１が終わる
ので、ピクチャー／ページセットスタックの第２エント
リーはポップされる。

【００７０】ピクチャー７５は第２階層レベルであるの
で、新しい第２エントリーをピクチャー／ページセット
スタックにプッシュさせる。トークンシーケンス７７
は、同スタックの第２エントリーに対するＣＣＩデータ
構造を生成させる。そして、トークンシーケンス７７の
終わりは文書の終わりであるので、文書が終わった時に
全てのＣＣＩデータ構造が破棄され、かつピクチャー／
ページセットスタックの全エントリーがポップされる。

【００７１】１つのトークンシーケンスが終わった時
に、通常、そのＣＣＩデータ構造を削除し、かつ様々な
ポインタ操作を行なう必要がある。図９のＣＣＩデータ
構造２４０のようなＣＣＩデータ構造の削除方法を説明
する前に、様々な種類のの辞書の操作に関して詳細に述
べる。

【００７２】ＳＰＤＬ文書の処理中に、文書によって使
用された値（value）及びプロシージャを見つけるため
に４種類の辞書が使用される。すなわち、図１４に示す
ようなシステム辞書、図２７に示すようなユーザ辞書、
コンテキスト辞書及びトークンシーケンスにより生成さ
れるコンテント辞書とである。辞書は、キー及び値に対
応した順序付けられたオブジェクトペアの集合である。
文書のＳＰＤＬコンテント中でキーに出会った時は常
に、辞書中の値が同キーの代わりに用いられる。辞書の
値部分は整数、実数等の任意の種類の値、プロシージ
ャ、または任意の他の種類のオブジェクトである。

【００７３】図１４はシステム辞書の一例である。シス
テム辞書は、ＳＰＤＬ文書の全てのオペレータ（operat
or）をキーフィールドに格納しており、また、対応した
プロシージャを値フィールドに格納している。例えばＳ
ＰＤＬコンテント中で”add”に出会った時には、addに
対応した値がシステム辞書において検索され、そしてad
d に対応したプロシージャは、２つの値がオペランドス
タックよりポップされて、その種類がチェックされ、加
算され、その結果がオペランドへ改めてプッシュされる
ことを示す。システム辞書内で見つかるであろう他の種
類のプロシージャが図１４に示されているが、通常、さ
らに多くのエントリーがシステム辞書に存在するであろ
う。システム辞書は、ユーザやＳＰＤＬ文書によって修
正することができないもので、ＳＰＤＬ文書を処理する
システムの一部分である。

【００７４】２番目の種類の辞書はユーザ辞書である。
ユーザ辞書は、初めは空であるが、トークンシーケンス
エレメントによってエントリーの追加及び修正が可能で
ある。ユーザ辞書は、情報の書き込みが可能であるだけ
でなく、書き込み後にユーザによって変更可能である。
ユーザ辞書は、エントリーをユーザが修正可能な辞書
（すなわちリード／ライト辞書）であり、かつ、ユーザ
がオペレータ”dict”を使用して生成する必要のない辞
書である。ユーザ辞書内の値は、どのようなタイプの値
でもよく、整数、実数、プロシージャを包含する。概念
的には、ユーザ辞書は１個だけである。しかし、ある階
層レベルが修正した辞書を必要とするのに対して他の階
層レベルが、その修正した辞書を使用しない場合には、
システムは、様々な階層レベルについて同一のキーに対
し様々な値を記憶しておかなければならないので、ユー
ザ辞書に様々な階層レベルについて様々なエントリーが
存在することになろう。

【００７５】次の種類の辞書はコンテキスト辞書であ
る。システム辞書とユーザ辞書が１個ずつしかないのに
対して、各階層レベルに対し及び同一の階層レベル内に
多数のコンテキスト辞書が存在し得る。コンテキスト辞
書は読み出し専用辞書である。すなわち、コンテキスト
辞書は一旦定義されたならば、ユーザによって修正する
ことはできない。コンテキスト辞書は、辞書ジェネレー
タ構造エレメント下のトークンシーケンスにより生成さ
れる。コンテキスト辞書の生成に関するより詳細な説明
は、同一出願人の継続中の米国特許出願第０７／９３
１，８０８号（１９９２年８月１１日受理、”Ｍethod
and Ｓystem to Ｈandle ＤictionaryＧenerator and
Ｃontext Ｄeclaration in Ｓtandard Ｐage Ｄescript
ionＬanguage”）に見ることができ、同特許出願の開示
内容は引用により本明細書に組み込まれる。

【００７６】最後の種類の辞書はコンテント辞書で、こ
れはユーザにより定義された辞書であり、またトークン
シーケンスエレメントにより定義される。コンテント辞
書は、生成される時にはリード／ライト辞書であり、直
上位の構造エレメントの範囲内でのみ有効である。後に
より詳しくコンテント辞書について説明する。

【００７７】サーチする辞書内のキーが、様々な辞書の
いずれにおいても見つかる可能性がある。そこで、本発
明によれば、様々な辞書についてキーをサーチするため
のサーチ順が採用され、これは図１５に示すような”コ
ンテキストスタック”（context stack）とよばれるも
のによって定義される。コンテキストスタックは、トッ
プよりサーチされる。コンテキスト辞書及びコンテント
辞書は最初にサーチすべき辞書である。ユーザ辞書は同
スタックのボトムの次のものであり、システム辞書はボ
トムに置かれる。本出願の親出願においては、コンテキ
ストスタックはコンテキスト辞書との関連でのみ説明さ
れた。しかし、コンテキストスタックは全辞書について
のサーチ順を定義する。

【００７８】辞書内のあるキーをサーチする時には、最
初に、ＣＣＩデータ構造中のコンテキストスタックへの
ポインタを調べてコンテキスト辞書及びコンテント辞書
をサーチすべきか判定する。下に説明するコンテキスト
スタックリンクデータ構造（context stack link data
structure）により指し示されたコンテキスト辞書また
はコンテント辞書に当該キーが見つからないときは、Ｃ
ＣＩデータ構造中のユーザ辞書リンク構造（user dicti
onary link structure）へのポインタを調べて当該キー
がユーザ辞書に存在するか判定することによってユーザ
辞書がサーチされる。当該キーがコンテキスト辞書また
はコンテント辞書のいずれにも、またユーザ辞書にも見
つからない場合、システム辞書がサーチされる。システ
ム辞書は１つだけであり、かつ修正されないので、プロ
ローグデータ構造またはＣＣＩデータ構造にシステム辞
書へのポインタを置く必要はない。システム辞書は常に
同一ロケーションで見つかるので、文書の階層レベル毎
にシステム辞書のロケーションを管理する必要はない。

【００７９】コンテキストスタックは、４種類の辞書の
サーチ順を定義するスタックと見做される。しかし、コ
ンテキストスタックは、スタックなる用語の一般的な意
味でのスタックではない。コンテキストスタックなる用
語は、辞書に対するサーチ順要件の説明を簡単にするた
めに用いられている。コンテキストスタックにおいて、
ボトムのエントリーは常に同じであって、システム辞書
のアドレスを指す。コンテキストスタックの次に高いエ
ントリーはユーザ辞書リンク構造であり、これはピクチ
ャ／ページセットプロローグデータ構造内のポインタ２
３１またはＣＣＩデータ構造内のポインタ２５２に相当
する。ユーザ辞書リンク構造は後続のユーザ辞書リンク
構造を指し示すことができる。コンテキストスタックの
最も上のエントリーは、コンテキストスタックリンクデ
ータ構造により指示されるコンテキスト及びコンテント
辞書である。コンテキストスタックの中央のエレメント
である、ユーザ辞書リンク構造へのポインタは、修正す
ることが可能であり、かつ、ユーザ辞書のエントリーを
変更するために使用可能であって、しかも、コンテキス
トスタック内で上側のコンテキスト及びコンテント辞書
のサーチ順に影響を及ぼさないので、”コンテキストス
タック”は必ずしも一般的なスタックではないが、概念
的にはスタック類似の構造のものである。

【００８０】ここで、ＣＣＩデータ構造により使用され
る様々な辞書及び文書の処理時に使用されるピクチャー
／ページセットプロローグデータ構造について見ると、
３つのレベルの辞書がある。最高の辞書レベルはコンテ
キスト辞書及びコンテント辞書であり、これらはトーク
ンによってユーザに定義される辞書である。コンテキス
ト辞書は読み出し専用辞書である。したがって、コンテ
キスト辞書は、生成された後は修正することができな
い。コンテキスト辞書は、それが生成された階層レベル
において、該レベルより低い階層レベルに対してしか使
用されない。コンテキスト辞書及びコンテント辞書は、
最高の辞書レベルにあるので、キーに出会った時に最初
にサーチされる。そのキーがコンテキスト辞書またはコ
ンテント辞書の中のある１つに見つかれば、それ以上の
辞書サーチは不要である。そのキーがコンテキスト辞書
でもコンテント辞書でも見つからないときは、次に、そ
のキーについてユーザ辞書がサーチされる。そのキーが
ユーザ辞書で見つからないと、最後にシステム辞書がサ
ーチされる。

【００８１】コンテキスト辞書及びコンテント辞書の操
作並びに、それら辞書のサーチ順について説明する前
に、コンテキスト辞書の生成プロセスを簡単に説明する
必要がある。辞書ジェネレータ構造エレメント、例えば
図５に示した文書の辞書ジェネレータ５４に出会った時
に、同辞書ジェネレータ下のトークンシーケンス５５は
生成すべき１つの辞書を定義し、構造プロセッサは、そ
の辞書をコンテキスト辞書に分類して、図１６に示すよ
うな１つのコンテキスト辞書ジェネレータデータ構造
（context dictionary generator data structure）６
５０を生成する。このコンテキスト辞書ジェネレータデ
ータ構造は、ページセットレベル（pageset_level）６
５２、ピクチャーレベル（picture_level）６５４、当
該辞書の名前に対応した辞書識別子６５６、辞書サイズ
６５８、辞書データ構造へのポインタ６６０、及び次の
辞書ジェネレータへのポインタ（next）６６２に関する
情報を内容とするリンクリスト（linked list）であ
る。この辞書ジェネレータデータ構造へのポインタ２２
８は、図９のピクチャー／ページセットプロローグデー
タ構造２２０内にある。

【００８２】新たに生成された辞書ジェネレータデータ
構造中のエントリー”next”６６２は、２個以上のコン
テキスト辞書が生成されるならば、前に生成されたある
辞書ジェネレータデータ構造を指し示す。こうすること
で、新たに生成された辞書ジェネレータデータ構造は、
それ以前に生成された辞書ジェネレータデータ構造の前
に挿入され、後には挿入されない。

【００８３】辞書ジェネレータによりコンテキスト辞書
が生成されると、このコンテキスト辞書は、コンテキス
トスタックリンクデータ構造を用いてコンテキストスタ
ックのトップに置かれる。コンテキスト辞書及びコンテ
ント辞書のサーチ順は修正することができる。コンテキ
スト宣言は、コンテキスト辞書のサーチ順を定義しまた
は修正する。また、トークンシーケンス中に、コンテキ
ストスタックを操作可能なオペレータ（operator）があ
る。コンテキスト辞書に対するサーチ順は、コンテキス
トスタックリンクデータ構造（その一例が図１７に示さ
れている）によって定義される。コンテキストスタック
リンクデータ構造６８０は、図９に示したピクチャー／
ページセットプロローグデータ構造２２０のコンテキス
ト宣言へのポインタ２２７及び／またはＣＣＩデータ構
造２４０のコンテキストスタックへのポインタ２４２に
よって、指示される。コンテキスト宣言へのポインタと
コンテキストスタックへのポインタとは、名前が違うけ
れども、同様の目的をかなえるもので、ＣＣＩデータ構
造の初期生成時には同一であり、また図１５に示すよう
な同じ基本構造を有する。

【００８４】コンテキストスタックリンクデータ構造の
内容は、ページセットレベル６８２とピクチャーレベル
６８４（例えば該データ構造が生成されたレベル）、該
辞書の名前と同じ辞書識別子６８６、辞書データ構造６
７０のアドレスを含む辞書へのポインタ６８８、ヌルま
たは他のコンテキストスタックリンクデータ構造を指し
示すエントリー”next”である。コンテキストスタック
内に２つ以上のコンテキスト辞書がある場合、エントリ
ー”next”は、後続の辞書に対するコンテキストスタッ
クリンクデータ構造を指し示す。なお、コンテキストス
タックリンクデータ構造は、前述の米国特許出願におい
てはコンテキスト辞書データ構造と呼ばれていることに
留意されたい。図１７のコンテキストスタックリンクデ
ータ構造に関するより完全な説明は、本出願人による係
属中の米国特許出願第０７／９３１，８０８号（”Ｍet
hod and Ｓystem to Ｈandle Ｄictionary Ｇeneratora
nd Ｃontext Ｄeclaration in Ｓtandard Ｐage Ｄescr
iption Ｌanguage”，１９９２年８月１１日受理）にあ
り、当該米国特許出願は引用により本明細書に組み込ま
れる。

【００８５】コンテキストスタックリンクデータ構造の
使用例が図１８乃至図２０に示されている。図１８、図
５のピクチャー６１の開始時におけるピクチャー／ペー
ジセットスタック、プロローグデータ構造、コンテキス
トスタックリンクデータ構造及びコンテキスト辞書を示
している。ページセット５０のために生成され、ピクチ
ャー／ページセットスタック２０２のポインタ２１２に
よって指示されるピクチャー／ページセットプロローグ
データ構造７００は、コンテキスト宣言へのポインタ７
０２を持っている。このコンテキスト宣言へのポインタ
７０２はコンテキストスタックリンクデータ構造７０４
を指すが、該データ構造７０４はポインタ７０８によっ
て後続のコンテキストスタックリンクデータ構造７１０
を指す。これらコンテキストスタックリンクデータ構造
７１０，７０４はコンテキスト辞書７１８，７１６を指
すが、これらコンテキスト辞書は図５の辞書ジェネレー
タ５４，５６及びそれらのトークンシーケンス５５，５
７によりそれぞれ生成されたものである。

【００８６】図５のピクチャー６１に出会った時に、文
書の階層レベルが１レベル下がり、図１１のフローチャ
ートに記述されるように、プロローグデータ構造２２０
を指すポインタ２０６と、ヌルを指すＣＣＩデータ構造
へのポインタ２０８とを持つ１つのエントリーが、ピク
チャー／ページセットスタックに入れられる。プロロー
グデータ構造２２０はプロローグデータ構造７００と同
じエントリーを有する。したがって、コンテキスト宣言
へのポインタ２２７はコンテキスト宣言へのポインタ７
０２と同じコンテキスト辞書リンク構造を指す。第１及
び第２の階層レベル対するコンテキスト辞書のサーチ順
は、図１８に示されるように、初めにコンテキスト辞書
７１６、次にコンテキスト辞書７１８、という順となろ
う。

【００８７】ピクチャーエレメント６１の下で最初のト
ークンシーケンスに出会った時に、図１９に示したＣＣ
Ｉデータ構造２４０からなる解釈コンテキストを生成す
る必要がある。図１５において、辞書識別子６４は辞書
ジェネレータ５４，５６により生成されたコンテキスト
辞書を指定する。トークンシーケンス、例えば辞書ジェ
ネレータ６５の下のトークンシーケンス６６は、ＣＣＩ
データ構造２４０の生成を必要とし、そして、図１４の
フローチャートに示したプロセスにおいて述べられるよ
うに、ＣＣＩデータ構造２４０のエントリーはプロロー
グデータ構造２２０よりコピーされる。ＣＣＩデータ構
造中の値はピクチャー／ページセットプロローグデータ
構造２２０よりコピーされるので、コンテキストスタッ
クへのポインタ２４４は、ピクチャー／ページセットプ
ロローグデータ構造２２０中のコンテキスト宣言へのポ
インタ２２７と同じアドレスを指す。

【００８８】図２０は、図５のトークンシーケンス６６
の後におけるピクチャー／ページセットスタック、プロ
ローグデータ構造、コンテキストスタックリンクデータ
構造及びコンテキスト辞書を示しており、この時には、
辞書識別子６４は辞書ジェネレータ５６により生成され
た１つのコンテキスト辞書だけを指定する。コンテキス
ト辞書７３２は図５には示されていないエレメントによ
って前もって生成されている。コンテキスト宣言６３及
び辞書識別子６４は、コンテキストスタックリンクデー
タ７２６を生成した。コンテキストスタックリンクデー
タ構造７２０は、辞書ジェネレータ６５及びトークンシ
ーケンス６６によって生成されたものであるが、ポイン
タ７２２により辞書７３２を指す。コンテキストスタッ
クリンクデータ構造７２０のポインタ”next”７２４
は、２番目のコンテキストリンクデータ構造７２６を指
している。コンテキストスタックリンクデータ構造７２
６は、ポインタ７２８により、辞書ジェネレータ５６に
よって前に生成されたコンテキスト辞書７１６を指して
いる。コンテキストスタックリンクデータ構造７２６は
コンテキスト宣言６３により定義されるので、そのエン
トリー”next”はヌルを指している。文書の第２階層レ
ベルのコンテキスト辞書のサーチ順は、図２０に示され
るように、まずコンテキスト辞書７３２、次にコンテキ
スト辞書７１６、という順である。

【００８９】前述のように、コンテキストスタックリン
クデータ構造より構成されたコンテキストスタックの最
高レベルを修正する一つの方法は、辞書識別子を含んだ
コンテキスト宣言構造エレメントを用いる方法である。
しかし、コンテント中のトークンシーケンスを用いて、
辞書をコンテキストスタックデータ構造にプッシュした
り、それよりポップすることができる。トークンシーケ
ンス中の”ビギン”（begin）オペレータは、オペラン
ドスタック内の参照された辞書をコンテキストスタック
にプッシュする。この機能は、図２１のフローチャート
に示されたプロセスによって遂行される。

【００９０】トークンシーケンスで”ビギン”等のオペ
レータが見つかると、コンテキスト宣言データ構造にコ
ンテント辞書をプッシュするために使用される、図２１
に示したプロセスがコールされる。ステップ７６０は新
たなコンテキストスタックリンクデータ構造に用いられ
るメモリを割り当て、そして該割り当てたコンテキスト
スタックリンクデータ構造のアドレスがポインタptr_Ｃ
Ｌに格納される。ステップ７６２において、アクティブ
（active）のＣＣＩデータ構造中のコンテキストスタッ
クへのポインタの値が、新たに生成されたコンテキスト
スタックリンクデータ構造の”next”エントリーにコピ
ーされる。次にステップ７６４において、ポインタptr_
ＣＬがアクティブのＣＣＩデータ構造のコンテキストス
タックへのポインタに格納される。ステップ７６６は、
ステップ７３０で割り当てたコンテキストスタックリン
クデータ構造のページセットレベル及びピクチャーレベ
ルの各エントリーに−１なる値を格納する。ページセッ
トレベルとピクチャーレベルに−１を格納する理由は、
該コンテキストスタックリンクデータ構造があるトーク
ンシーケンスによって操作されたことを表示するためで
ある。後述するように、コンテキストスタックリンクデ
ータ構造より１つの辞書がポップされる場合、コンテキ
ストスタックリンクデータ構造に辞書がどのようにして
格納されたか（すなわち、それら辞書がコンテキスト辞
書、コンテント辞書のいずれかであるか）によって、メ
モリの割り当て解除のためのプロセスは様々である。最
後に、ステップ７６８は、コンテキストスタックにプッ
シュされた辞書へのポインタを、ステップ７６０で生成
したコンテキススタックリンクデータ構造の辞書ポイン
タに格納する。

【００９１】図２２は、トークンシーケンスがコンテン
ト辞書７４４をコンテキストスタックにプッシュした後
におけるピクチャー／ページセットスタック、ＣＣＩデ
ータ構造、プロローグデータ構造、コンテキストスタッ
クリンクデータ構造、コンテキスト辞書及びコンテント
辞書を示している。図２２に示された構造は、図５のト
ークンシーケンス６６で生成されると考えることがで
き、図１９に示した構造の次にできる構造である。

【００９２】コンテキスト辞書７４４は、トークンシー
ケンス６６中のオペレータ”dict”により生成されたと
考えることができる。トークンシーケンス６６に出会っ
た時に、図１９のＣＣＩデータ構造が生成される。トー
クンシーケンス６６は、オペレータ”ビギン”の実行時
に、図２１のプロセスによってコンテキストスタックリ
ンクデータ構造７３４を生成する。トークンシーケンス
６６の実行中に、図２２に示されたコンテキストスタッ
クリンクデータ構造７３４のページセットレベル７３６
とピクチャーレベル７３８とは−１になっているが、そ
の理由は、コンテキストスタックリンクデータ構造７３
４が構造プロセッサではなくトークンシーケンスによっ
て生成されたからである。コンテキストスタックリンク
データ構造７３４は、ポインタ７４０によって、前に生
成された辞書７４４を指し示す。コンテキストスタック
リンクデータ構造７３４のポインタ７４２は、２番目に
低いレベルのコンテキストスタックリンクデータ構造７
０４を指し示す。したがって、図２２に示されたデータ
構造により、コンテキスト辞書及びコンテント辞書がサ
ーチされる時には、まず辞書７４４がサーチされ、次に
辞書７１６と辞書７１８がサーチされる。これら辞書の
どれかにキーが見つかれば、辞書サーチは終わる。キー
が見つからないときは、次にユーザ辞書及びシステム辞
書がサーチされる。

【００９３】図２３は、トークンシーケンスを使って、
コンテキストスタックリンクデータ構造より１つの辞書
をポップするためのプロセスを示している。図２３のル
ーチンがコールされた時に、例えばトークンシーケンス
が”エンド”（end）オペレータを含んでいる時に、ス
テップ７８８はアクティブのＣＣＩデータ構造のコンテ
キストスタックポインタにより指示されたコンテキスト
スタックリンクデータ構造のアドレスを確認する。次
に、コンテキスト宣言により指示されたコンテキストス
タックリンクデータ構造はもはや使用されないので、こ
のコンテキストスタックリンクデータ構造の”next”の
値が、アクティブＣＣＩデータ構造のコンテキスト宣言
ポインタにコピーされる。ステップ７９２は、ページセ
ットレベルが−１であり、かつピクチャーレベルが−１
であるか判定する。これらの値が両方とも−１である場
合、コンテントスタックリンクデータ構造はコンテキス
トスタックへのプッシュにより生成されたのであるか
ら、指示された辞書が他のオブジェクトによって参照さ
れることはないので、該辞書用のメモリを解放できる可
能性がある。ページセットレベル及びピクチャーレベル
が−１の場合、ステップ７９４は、コンテキストスタッ
クリンクデータ構造の辞書が他のオブジェクトによって
参照されるか判定する。参照されないならば、ステップ
７９６において、当該辞書は消去され、その占有メモリ
は解放される。当該辞書が他のオブジェクトにより参照
される場合には、当該辞書は消去できないので、ステッ
プ７９８がコンテキストスタックリンクデータ構造とそ
のメモリを消去するだけである。ページセットレベルと
ピクチャーレベルの両方が−１ではない場合には、当該
辞書は後で必要になるかも知れないのでステップ７９６
で消去されることはない。その代わり、ステップ７９８
で、コンテキストスタックリンクデータ構造のメモリだ
けが解放される。メモリ解放はシステム資源を解放させ
て、処理中に使用メモリの割り当て解除を可能にする。

【００９４】図２４は、あるトークンシーケンスが、図
２０に示した文書構造のコンテキストスタックリンクデ
ータ構造より辞書７３２をポップして、辞書７５６を該
コンテキストスタックリンクデータ構造にプッシュした
後におけるピクチャー／ページセットスタック、ＣＣＩ
データ構造、プロローグデータ構造、コンテキストスタ
ックリンクデータ構造、コンテキスト辞書及びコンテン
ト辞書を示している。トークンシーケンス、例えば図５
のトークンシーケンス７０は、辞書をポップ及びプッシ
ュさせるが、ＣＣＩデータ構造２４０を生成する。該ト
ークンシーケンスが、辞書７３２をコンテキストスタッ
クリンクデータ構造よりポップさせるように命令する時
には、ポインタ２４４はもうコンテキストスタックリン
クデータ構造７２０を指し示さないでコンテキストスタ
ックリンクデータ構造７２６を指し示すことになる。該
トークンシーケンスがプッシュ（push）命令を含んでい
る時には、図２４に示すように、コンテキストスタック
リンクデータ構造７４６が生成され、同データ構造は、
ピクチャーレベル及びページセットレベルが−１であ
り、また、ポインタ２４４により指し示される。辞書７
５６は前に生成されたものであるが、ポインタ７５２に
より指示される。コンテキストスタックリンクデータ構
造７４６の”next”は、コンテキストスタックリンクデ
ータ構造７２０でなく、コンテキストスタックリンクデ
ータ構造７２６を指し示すが、これは辞書７３２がコン
テキストスタックリンクデータ構造よりポップされてい
るからである。トークンシーケンスの処理中に、プロロ
ーグデータ構造２２０中のコンテキスト宣言へのポイン
タ２２７は影響を受けないが、コンテキストスタックへ
のポインタ２４２は修正される。

【００９５】さて、ユーザ辞書の構成について説明す
る。ＳＰＤＬ（Ｓtandard ＰageＤescription Ｌanguag
e）の実施規格はユーザ辞書を１個だけにすることを指
示しているが、ユーザ辞書は修正可能であるので、文書
の様々な階層レベルでユーザ辞書内の様々なキー及び値
を使用可能である。したがって、概念上は、本発明にお
いて、単一のユーザ辞書をさまざまな小さなユーザ辞書
からできていると考えることができる。図２５に示すよ
うなユーザ辞書リンク構造(user dictionarylink struc
ture）が。様々な階層レベル内の様々な小ユーザ辞書を
管理するために用いられる。

【００９６】ユーザ辞書リンク構造８００は、図９のプ
ロローグデータ構造２２０のユーザ辞書リンクへのポイ
ンタ２３１、及び／または、ＣＣＩデータ構造２４０の
ユーザ辞書リンクへのポインタ２５２により指し示めさ
れる。このユーザ辞書リンク構造の内容は、ページセッ
トレベル８０２、ピクチャーレベル８０４、ユーザ辞書
へのポインタ８０６、及び、別のユーザ辞書リンク構造
かヌルを指すエントリー”next”である。ユーザ辞書、
例えばユーザ辞書８１０は、２つのカラムつまりキー
（key）カラム８１２と値（value）カラム８１４を持っ
ている点でコンテキスト辞書及びシステム辞書と似てい
る。ユーザ辞書は、任意のトークンシーケンスにより修
正でき、また、セットアッププロシージャ、例えば図５
のプロローグ５１内のトークンシーケンス５９を持つセ
ットアッププロシージャ５８により、内部にエントリー
を設定することができる。

【００９７】図２６は、オペレータ”def”、すなわち
ユーザ辞書の内容に対する書き込み（修正を含む）があ
る時に必ず使用されるプロセスを示している。ユーザ辞
書の内容修正とユーザ辞書への書き込みは、同様に扱わ
れる。ユーザ辞書に対する書き込みもしくは修正がある
場合、辞書内のキーがサーチされる。書き込み、修正い
ずれの場合にも、サーチ対象のキーが見つかったとき
は、同キーに対応した値が修正される。目的のキーが見
つからないときは、キーと値のペアーが辞書に書き込ま
れる。ステップ８２０は、当該ユーザ辞書リンクにおけ
る第１のユーザ辞書に対する初めての書き込み”def”
であるか判定する。ユーザ辞書の生成後、同ユーザ辞書
に対する２番目以降の書き込みがあったときには、ステ
ップ８２２で、既存のユーザ辞書に対して、ユーザ辞書
へ書き込みをするトークンシーケンスによって指示され
たエントリーを追加する。今回が、あるトークンシーケ
ンスにつきユーザ辞書の初めての書き込みであれば、処
理の流れはステップ８２０からステップ８２４へ進み、
１つのユーザ辞書リンク構造のためにメモリが割り当て
られる。また、この割り当てられたユーザ辞書リンク構
造に対するポインタptr_linkが決められる。次にステッ
プ８２６において、アクティブのＣＣＩデータ構造中の
ユーザ辞書リンク構造へのポインタが、新しく生成され
たユーザ辞書リンク構造のエントリー”next”にコピー
される。

【００９８】ステップ８２８において、新しく生成され
たユーザ辞書リンク構造へのポインタが、アクティブの
ＣＣＩデータ構造の、ユーザ辞書リンクへのポインタ用
エントリーに格納される。このエントリーとは、例え
ば、図９に示したＣＣＩデータ構造２４０のエントリー
２５２である。ステップ８３０は、該ユーザ辞書にメモ
リを割り当て、該ユーザ辞書の追加されるエントリーの
アドレスを決定する。ユーザ辞書を修正するには、ユー
ザ辞書内に小ユーザ辞書を生成する必要がある。その理
由は、より高い階層レベルのユーザ辞書は、後続の処理
の間、修正しない形にしておく必要があるので、修正さ
れてはならないからである。したがって、ユーザ辞書に
全くエントリーを追加しない修正の場合でさえも、該ユ
ーザ辞書の新しい部分を割り当てる必要がある。ステッ
プ８３２は、ポインタptr_udictを、該ユーザ辞書リン
ク構造の辞書ポインタに格納する。例えば、ptr_udict
は、図２５に示したユーザ辞書リンク構造８００の辞書
ポインタ８０６に格納される。最後に、ステップ８３４
において、追加または修正をすべきキー・値ペア（key-
value pai）が、新しく生成された辞書に書き込まれ
る。そして、処理の流れはコンテントプロセッサへ戻
り、トークンシーケンスの他の処理が行なわれる。

【００９９】１つのエントリーを持つユーザ辞書の例が
図２７に示されている。このユーザ辞書は、次に示すコ
ンテント ／ａｄｄ｛ｍｕｌ｝ｄｅｆ を含むトークンシーケンスによって生成される。このト
ークンシーケンスコマンドは、ユーザ辞書のキーカラム
へのエントリー”add”の格納と、対応した値カラムへ
の乗算を意味する｛mul｝の格納とを指示する。処理中
の文書で”add”に出会った時には、コンテキスト辞書
及びコンテント辞書において”add”がサーチされる。
これらの辞書で見つからないときは、ユーザ辞書がサー
チされて、”add”が見つかることになる。”add”に対
応する辞書内の値は”{mul}”である。文書中で”add”
に出会った時には、オペランドスタック上の最初の２つ
のエントリーが掛け合わされ、その結がオペランドスタ
ックにプッシュされる。例えば、キー”add”に対応す
る値が”{mul}”である時に、文書中にコマンド”2 3
add”があれば、まず２がオペランドスタックにプッシ
ュされ、そして３が２の上にプッシュされる。”add”
に出あうと、オペランドスタック内の上の２つの値が掛
け合わされ、その結果である６がオペランドスタックの
トップにプッシュされる。

【０１００】図２８乃至図３２は、図５の文書の処理中
に存在することになるピクチャー／ページセットスタッ
ク、プロローグデータ構造、ユーザ辞書リンク構造及び
ユーザ辞書を示している。図２８は、図５の文書の始ま
りにおける各種構造の状態を表わす。ピクチャー６１は
第２階層レベルにあるので、ピクチャー／ページセット
スタック２０２には２つのエントリーが存在し、したが
って、２つのプロローグデータ構造２２０，７００が存
在する。ユーザ辞書リンク構造９２０とユーザ辞書９４
０とは、セットアッププロシージャ５８とそのトークン
シーケンス５９によって生成されたものである。

【０１０１】トークンシーケンス６６または６８の処理
中の構造は、図２９で表わすことができる。図２９が図
２８と異なる点は、トークンシーケンスの処理中である
のでＣＣＩデータ構造が生成されていることである。こ
のＣＣＩデータ構造２４０中のユーザ辞書へのポインタ
２５２は、プロローグデータ構造２２０中のユーザ辞書
リンクへのポインタ２３１をコピーされているので、ポ
インタ２３１と同じユーザ辞書リンクを指す。

【０１０２】図３０は、ユーザ辞書９４２へのエントリ
ー書き込みプロセスにおけるセットアッププロシージャ
６７及びそのトークンシーケンス６８を示す。トークン
シーケンス６８が処理されている時にＣＣＩデータ構造
２４０が生成さる。この第２階層レベルで初めてユーザ
辞書に対する修正または書き込みがあった時に、ユーザ
辞書リンク構造９２６とユーザ辞書９４２が生成され
る。

【０１０３】トークンシーケンス６８の処理の終わり
で、ＣＣＩデータ構造２４０が破棄され、ユーザ辞書リ
ンクへのポインタ２５２はプロローグデータ構造２２０
のユーザ辞書リンクへのポインタ２３１にコピーされ
る。その結果として得られるデータ構造が図３１に示さ
れている。図３０及び図３１の第２階層構造についての
ユーザ辞書のサーチ順は、まず辞書９４２、次に辞書９
４０、の順である。

【０１０４】セットアッププロシージャ６７の後で、ユ
ーザ辞書に対しエントリーの追加及び修正をすることが
できる。例えば、トークンシーケンス７０は追加エント
リーをユーザ辞書に書き込むことができる。トークンシ
ーケンス７０の処理中に、図３２に示したＣＣＩデータ
構造２４０が生成される。ユーザ辞書への追加エントリ
ーを含むトークンシーケンス７０の部分に出会った時
に、ユーザ辞書リンク構造９３２が生成される。ユーザ
辞書リンク構造９３２は新たに生成された部分であるユ
ーザ辞書９４４を指し示し、また、その”next”ポイン
タによりユーザ辞書リンク構造９２６を指し示す。

【０１０５】図３３乃至図３７は、トークンシーケンス
エレメントが終わった時に用いられるプロシージャを説
明している。１つのトークンシーケンスエレメントが終
了した時に、図３３に示したプロセスがコールされ、ス
テップ１００２は直ぐ上位の構造エレメントが終了済み
であるか判定する。直ぐ上位の構造エレメントが終了済
みならば、ＣＣＩデータ構造は削除されるべきで、それ
をするためにステップ１００６及びステップ１００８に
記述されたプロセスをコールする。直ぐ上位の構造エレ
メントが終了済みでないとは、ステップ１００４は次の
構造エレメントがトークンシーケンス、または、あるピ
クチャーもしくはページセット内のピクチャーであるか
判定する。

【０１０６】１つのトークンシーケンスが終わった時
に、その直ぐ後に別のトークンシーケンスがあることが
ある。このようなことが起こるケースは、例えば図５の
セットアッププロシージャ６７の下に２つのトークンシ
ーケンスがある場合である。そして、仮に一方のトーク
ンシーケンスが状態変数を修正し、もう１つのトークン
シーケンス、例えば６８．５の位置にあるトークンシー
ケンスが、ユーザ辞書を修正したとする。そうすると、
トークンシーケンス６８．５（図示されていない）に出
会った時に、トークンシーケンス６８のＣＣＩデータ構
造は削除されるべきでない。

【０１０７】ピクチャー７１に出会った時に、トークン
シーケンス７０のＣＣＩデータ構造は削除されるべきで
ない。このトークン７０処理時に生成されたＣＣＩデー
タ構造は、トークンシーケンス７４の処理に必要である
からである。このピクチャー７１は、ピクチャーまたは
ページセット内部のピクチャーであり、したがって、エ
ラールーチンはコールされるべきでなく、処理の流れは
構造プロセッサに戻される。なお、ピクチャー７１に出
会った時に、ステップ１００２は直ぐ上位の構造エレメ
ント、すなわちピクチャーボディ６９が終わっていない
と判定するので、処理の流れはステップ１００４へ進
む。

【０１０８】ステップ１００６によりコールされたプロ
セスは、後で使う必要のある値をコピーする。ステップ
１００８によりコールされたプロセスは、もう必要のな
いデータ構造を削除する。

【０１０９】ステップ１００６がコールするプロセス
を、図３４及び図３５に示す。ある処理条件下で、ＣＣ
Ｉデータ構造はデータの一時記憶エリアとして用いら
れ、また、ＣＣＩデータ構造を生成させるトークンシー
ケンスが終わった時にＣＣＩデータ構造を削除できる。
しかし、文書のプレゼンテーションのための処理時に用
いられる、特定のパラメータを修正するには、そのパラ
メータを修正直後に格納する必要がある。したがって、
ある環境下で、ＣＣＩデータ構造の特定のパラメータが
プロローグデータ構造内の対応エントリーにコピーされ
た後に、ＣＣＩデータ構造は削除される。

【０１１０】ステップ１００６が図３４に示したプロセ
スをコールすると、ステップ１０２０は直ぐ上位の構造
エレメントがセットアッププロシージャであるか判定す
る。セットアッププロシージャは、先の処理のため状態
変数またはユーザ辞書を修正するのに用いられることが
ある。プロローグデータ構造内のポインタに対するこれ
ら修正をコピーしておく必要がある。すぐ上位の構造エ
レメントがセットアッププロシージャであるときには、
処理の流れはステップ１０２２へ進み、状態変数が修正
されたか判定する。修正されたときには、ステップ１０
２４によって、ＣＣＩデータ構造内の状態変数テーブル
へのポインタが、プロローグデータ構造内の対応したポ
インタへコピーされる。次に、ステップ１０２６はユー
ザ辞書が修正されたか判定する。修正されたときには、
ステップ１０２８で、ＣＣＩデータ構造内にあるユーザ
辞書リンクへのポインタが、プロローグデータ構造内の
対応したポインタへコピーされる。そして、処理の流れ
は図３５に示されたプロセスＢへ進む。

【０１１１】ステップ１０２０で、直ぐ上位の構造エレ
メントがセットアッププロシージャではないと判定した
ときには、処理の流れはステップ１０３０へ進み、その
構造エレメントがリソース仕様（source specificatio
n）であるか判定する。それがソース仕様であれば、ス
テップ１０３２オペランドスタックの必要な情報をセー
ブする。例えば、カラーリソース（color resource）仕
様の場合、オペランドスタックのトップにあるベクタ参
照（vector reference）を構造プロセッサでセーブしな
ければならない。パターン（pattern）及びフォーム（f
orm）リソース仕様の場合には、辞書参照がセーブされ
る。そして、処理の流れは図３５に示したプロセスＢへ
進む。

【０１１２】ステップ１０３４は、何かコンテキスト辞
書が定義されるか判定する。定義されるならば、ステッ
プ１０３６はオペランドスタックより辞書参照を取得す
る。そして処理の流れは図３３に示したプロセスに戻
り、ステップ１００８が図３６及び図３７に示されたＣ
ＣＩ削除ルーチンをコールし、同ルーチンが必要でなく
なったデータ構造を削除する。

【０１１３】図３６において、ステップ１１００はＣＣ
Ｉデータ構造により指し示されたコンテキストスタック
リンクデータ構造を取得する。ステップ１１０２は、ピ
クチャーレベル（picture_level）及びページセットレ
ベル（pageset_level）が共に−１であるか判定する。
両方とも−１ならば、トークンシーケンスによる辞書操
作が生じているので、該コンテキストスタックリンクデ
ータ構造は、他のどのＣＣＩデータ構造もしくはプロロ
ーグデータ構造によっても指し示されず、削除してよ
い。ステップ１１０４は、該コンテキストスタックリン
クデータ構造により指し示された辞書を取得する。ステ
ップ１１０６は、該コンテキストスタックリンクデータ
構造の”next”ポインタを格納する。次に、ステップ１
１０８は、該コンテキストスタックリンクデータ構造を
削除する。ステップ１１１０は、該辞書が辞書ジェネレ
ータのリンク中にあるか判定する。そうでないときは、
該辞書をステップ１１１２で消去できる。処理の流れは
ステップ１１１４へ進み、ステップ１１０６で得られた
情報を利用して次のコンテキストスタックリンクデータ
構造が取得される。得られたコンテキストスタックリン
クデータ構造のピクチャーレベル及びページセットレベ
ルが−１でない時には、処理の流れは図３７に示すプロ
セスＣへ進む。

【０１１４】図３７に示したプロセスにおいて、ステッ
プ１１２０はオペランドスタックを、もはや不要である
のでメモリから削除する。そしてステップ１１１２は、
最も上位の構造エレメントがセットアッププロシージャ
であるか判定する。セットアッププロシージャでなけれ
ば、ステップ１１２４で状態変数テーブルをメモリから
削除できるので、ユーザ辞書及びＣＣＩデータ構造のユ
ーザ辞書リンク構造はステップ１１２６で削除される。

【０１１５】ステップ１１２８はマシン状態をメモリよ
り削除し、ステップ１１３０はＣＣＩデータ構造を削除
し、ステップ１１３２はピクチャー／ページセットスタ
ックのトップエントリーであるＣＣＩデータ構造へのポ
インタにヌルを書き込む。そして、処理の流れは図３３
に示したプロセスへ戻り、結局、図３３の処理をコール
した構造プロセッサへ戻る。

【０１１６】なお、図３６及び図３５に示したプロセス
の完了後、処理直後のコンテント部を含む階層レベルが
終了する可能性がある。階層レベルが終了したときに
は、終了した該階層レベルのピクチャー／ページセット
プロローグデータ構造はメモリから削除され、プロロー
グデータ構造へのポインタ及びＣＣＩデータ構造へのポ
インタを保持しているピクチャー／ページセットスタッ
ク内のエントリーがポップされる。階層レベルの終了に
関するより詳細な説明が本出願による米国特許出願第０
７／８７６，６０１号（”Ｍethod and Ｓystem to Ｍa
nage Ｐictureand Ｐageset for Ｄocument Ｐrocessin
g”）に述べられており、これは引用により本明細書に
組み込まれる。

【０１１７】図５に示したセットアッププロシージャ５
８及びそれに関連したトークンシーケンス５９による状
態変数の操作について、図３８乃至図４２に示したデー
タ構造と関連させて説明する。

【０１１８】図３８は、セットアッププロシージャ構造
エレメントの始まりの時点におけるピクチャー／ページ
セットスタック２０２、プロローグデータ構造２２０及
びデフォルト状態変数テーブル４５０を示している。デ
フォルト状態変数テーブル４５０は、デフォルトの状態
変数を格納している。デフォルト状態変数は、ＲＯＭや
ディスク記憶装置等の非揮発性メモリに格納されること
が多い。したがって、デフォルト状態変数テーブルは読
み出し専用であるかもしれないので、その中の値を変更
することは不可能かもしれない。セットアッププロシー
ジャ５８の前に３つのトークンシーケンス（５３，５
５，５７）があるが、これらのトークンシーケンスは、
それぞれの処理中に生成されたＣＣＩデータ構造によっ
て指示される状態変数テーブル内の変数を変更するだけ
である。しかし、それら状態変数の変更は一時的であっ
て格納されない。

【０１１９】トークンシーケンス５９の先頭で、図１３
のステップ６０４に示すように、ＣＣＩデータ構造２４
０が割り当てられる。ステップ６０６で、新たに生成さ
れたＣＣＩデータ構造２４０へのポインタがピクチャー
／ページセットスタック２０２のトップエントリーのＣ
ＣＩデータ構造へのポインタ２１４に格納される。ステ
ップ６０８で、１つの状態変数テーブル４６０が生成さ
れ、そのポインタがＣＣＩデータ構造４２０の状態変数
テーブルへのポインタ２４８に格納される。ステップ６
１０において、プロローグデータ構造２２０内の状態変
数テーブルへのポインタ２２９により指示された状態変
数テーブル４５０の値が、新たに生成された状態変数テ
ーブル４６０へコピーされる。例えば、デフォルト状態
変数テーブル４５０のエントリー４５１，４５２，４５
３中の値Ｘ１，Ｘ２，Ｘ３が、状態変数テーブル４６０
のエントリー４６１，４６２，４６３へそれぞれコピー
される。ここで、図３９に示した如きデータ構造にな
る。

【０１２０】トークンシーケンス５９の処理期間に、状
態変数テーブル４６０の状態変数は修正されるかもしれ
ない。例えば、次のトークンシーケンス 10 10 moveto 10 setlinewidth は状態変数テーブルの Ｃurrent_Ｐosition(カレント位
置）とＣurrent_Ｓtroke_Ｗidth （カレントストローク
幅）を修正する。図４０は、状態変数が修正された後の
データ構造の状態を示している。

【０１２１】図４１は、コンテントプロセッサがトーク
ンシーケンス５９の処理を終了して構造プロセッサがセ
ットアッププロシージャ５８の終わりで制御を取得する
時の構造を示している。構造プロセッサは、図３４のス
テップ１０２４で述べたように、ＣＣＩデータ構造２４
０の状態変数テーブルへのポインタ２４８を、プロロー
グデータ構造２２０の状態変数テーブルへのポインタ２
２９へコピーする。したがって、状態変数は有効に修正
されたので、以後の処理では、修正後の値４６１，４６
２，４６３を持つ状態変数テーブル４６０を指し示す状
態変数テーブルへのポインタ２２９を使用する。

【０１２２】図４２は、当該セットアッププロシージャ
の終了後のデータ構造を示している。図３７のステップ
１１３０で述べたようにＣＣＩデータ構造は削除され、
また、図３７のステップ１１３２で述べたように、ピク
チャー／ページセットスタック２０２のＣＣＩデータ構
造へのポインタはヌルを指すように設定される。

【０１２３】構造プロセッサは、コンテントプロセッサ
へ制御を渡す前に、何等かの値をオペランドスタックに
プッシュするかもしれない。例えば、リソース定義構造
エレメントにカラーが定義される時には、構造プロセッ
サは、カラーネームの値に依存した値の単一エレメント
のタイプ識別子をプッシュするかもしれない。同様に、
辞書ジェネレータ構造エレメントが処理される時には、
構造プロセッサは、制御をコンテントプロセッサへ渡す
前に、オペランドスタックに辞書参照をプッシュしなけ
ればならない。したがって、トークンシーケンスの上位
構造エレメントに応じて、様々な値がオペランドスタッ
クにプッシュされる。

【０１２４】以上の説明に照らし、本発明の様々な修正
及び変形が可能であることは明らかである。例えば、ピ
クチャー／ページセットスタックが、各階層レベルにつ
きエントリーを１個しか持たないようにしてもよい。こ
のエントリーは階層レベルのプロローグデータ構造を指
し示させなければならない。そして、プロローグデータ
構造は階層レベルのためのカレント解釈コンテキスト
（ＣＣＩ）へのポインタを持つことになろう。このよう
な構成でも、プロローグデータ構造とＣＣＩデータ構造
の両方が実現されるであろうから、前述したと等価な結
果を得られよう。また、ＣＣＩデータ構造中にリソース
宣言へのポインタを持つ必要はないかもしれない。

【０１２５】

【発明の効果】以上に詳細に説明したように、本発明に
よれば、階層構造文書の処理中に、処理を実行するバー
チャルマシンの状態を定義する状態変数の好適な管理環
境を提供し、階層構造文書の処理の効率化・高速化を実
現できる等の多くの効果を得られるものである。

【図面の簡単な説明】

【図１】４ページの文書の例を示す図である。

【図２】１ページの文書の例とその階層構造エレメント
を示す図である。

【図３】文書の階層構造の説明図である。

【図４】ピクチャー、ページセット、プロローグ、ピク
チャーボディ（picture_body）及びページセットボディ
（pageset_body）の文法の説明図である。

【図５】典型的な２ページのＳＰＤＬ文書の構造を示す
図である。

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

【図７】ＳＰＤＬ文書を処理するために使用されるバー
チャルマシンもしくは処理モデルの説明図である。

【図８】ピクチャー／ページセットスタックと、同スタ
ックに対しプッシュまたはポップする様々な階層構造エ
レメントとを関連させて説明する図である。

【図９】ピクチャー／ページセットスタックと、同ピク
チャー／ページセットスタックのエントリーによって指
し示されたピクチャー／ページセットプロローグデータ
セット及びＣＣＩデータ構造の説明図である。

【図１０】状態変数テーブルの説明図である。

【図１１】ピクチャービギン（picture_begin）コマン
ドで実行されるプロセスにおけるピクチャー／ページセ
ットスタック及びピクチャー／ページセットプロローグ
データ構造の操作に関連する部分のフローチャートであ
る。

【図１２】ピクチャービギン（picture_begin）コマン
ドで実行されるプロセスにおける状態変数の操作に関連
する部分のフローチャートである。

【図１３】トークンシーケンス構造エレメントと出会っ
た時にカレント解釈コンテキストデータ構造を生成する
ために用いられるプロセスを示すフローチャートであ
る。

【図１４】システム辞書の一部を示す図である。

【図１５】コンテキストスタックの説明図である。

【図１６】コンテキスト辞書ジェネレータ（context di
ctionary generator）データ構造を示す図である。

【図１７】コンテキストスタックリンクデータ構造（co
ntext stack linkdata structure）を示す図である。

【図１８】文書処理中におけるピクチャー／ページセッ
トスタック、ＣＣＩデータ構造、プロローグデータ構
造、コンテキストスタックリンクデータ構造及びコンテ
キスト辞書の状態の一例を示す図である。

【図１９】文書処理中におけるピクチャー／ページセッ
トスタック、ＣＣＩデータ構造、プロローグデータ構
造、コンテキストスタックリンクデータ構造及びコンテ
キスト辞書の状態の別の例を示す図である。

【図２０】文書処理中におけるピクチャー／ページセッ
トスタック、ＣＣＩデータ構造、プロローグデータ構
造、コンテキストスタックリンクデータ構造及びコンテ
キスト辞書の状態の他の例を示す図である。

【図２１】コンテキスト辞書を、トークンシーケンスに
より指示された時に、コンテキストスタックリンクデー
タ構造へプッシュするために用いられるプロセスのフロ
ーチャートである。

【図２２】辞書がコンテキストスタックリンクデータ構
造へプッシュされた後の各種データ構造を示す図であ
る。

【図２３】トークンシーケンスによってコンテキストス
タックリンクデータ構造より辞書がポップされる時に実
行されるプロセスのフローチャートである。

【図２４】コンテキストスタックリンクデータ構造のプ
ッシュ及びポップが発生した後の各種のスタック及びデ
ータ構造を示す図である。

【図２５】ユーザ辞書（user dictionary）及びユーザ
辞書リンクデータ構造（userdictionary link data str
ucture）を示す図である。

【図２６】ユーザ辞書を操作するために用いられるプロ
セスのフローチャートである。

【図２７】１つのエントリーを含むユーザ辞書の例を示
す図である。

【図２８】文書のある処理ステップにおけるピクチャー
／ページセットスタック、ＣＣＩデータ構造、プロロー
グデータ構造、ユーザ辞書リンク（link）、ユーザ辞書
の状態を示す図である。

【図２９】文書のある処理ステップにおけるピクチャー
／ページセットスタック、ＣＣＩデータ構造、プロロー
グデータ構造、ユーザ辞書リンク、ユーザ辞書の状態を
示す図である。

【図３０】文書のある処理ステップにおけるピクチャー
／ページセットスタック、ＣＣＩデータ構造、プロロー
グデータ構造、ユーザ辞書リンク、ユーザ辞書の状態を
示す図である。

【図３１】文書のある処理ステップにおけるピクチャー
／ページセットスタック、ＣＣＩデータ構造、プロロー
グデータ構造、ユーザ辞書リンク、ユーザ辞書の状態を
示す図である。

【図３２】文書のある処理ステップにおけるピクチャー
／ページセットスタック、ＣＣＩデータ構造、プロロー
グデータ構造、ユーザ辞書リンク、ユーザ辞書の状態を
示す図である。

【図３３】トークンシーケンスのエンド（end）に出会
った時に用いられるプロセスのフローチャートである。

【図３４】ＣＣＩデータ構造が削除される前に必要な変
数のセーブのためのプロセスの一部を示すフローチャー
トである。

【図３５】ＣＣＩデータ構造が削除される前に必要な変
数のセーブのためのプロセスの一部を示すフローチャー
トである。

【図３６】不必要なＣＣＩデータ構造と、それに関連し
たデータ構造を削除するためのプロセスの一部を示すフ
ローチャートである。

【図３７】不必要なＣＣＩデータ構造と、それに関連し
たデータ構造を削除するためのプロセスの一部を示すフ
ローチャートである。

【図３８】状態変数の処理中に用いられるデータ構造を
示す図である。

【図３９】状態変数の処理中に用いられるデータ構造を
示す図である。

【図４０】状態変数の処理中に用いられるデータ構造を
示す図である。

【図４１】状態変数の処理中に用いられるデータ構造を
示す図である。

【図４２】状態変数の処理中に用いられるデータ構造を
示す図である。

【符号の説明】

１０，１２ ページセット １４，１５，１８，２０ ピクチャー １０２ ＣＰＵ １０４ ＲＡＭ １０６ ＲＯＭ １０８ ＥＥＰＲＯＭ １１０ クロック １１２ プリンタインターフェイス １１４ ホストインターフェイス １１８ 通信インターフェイス １２０ 記憶インターフェイス １２２ ディスプレイ／パネルインターフェイス １５０ ＳＰＤＬ文書 １５２ 構造プロセッサ １５４ ＣＣＩデータ構造 １５８ ピクチャー／ページセットプロローグデータ構
造 １６２ コンテントプロセッサ １６４ イメージャ １６６ 出力イメージ ２００ パーサー ２０２ ピクチャー／ページセットスタック ２２０ ピクチャー／ページセットプロローグデータ構
造 ２４０ ＣＣＩデータ構造 ３００ 状態変数テーブル ４５０ デフォルトの状態変数テーブル ４６０ 状態変数テーブル ６３０ コンテキストスタック ６５０ コンテキスト辞書ジェネレータデータ構造 ６８０ コンテキストスタックリンクデータ構造 ７００ ピクチャー／ページセットプロローグデータ構
造 ７０４，７１０，７２０，７２６ コンテキストスタッ
クリンクデータ構造 ７１６，７１８，７３２ コンテキスト辞書 ７３４ コンテキストスタックリンクデータ構造 ７４４，７５６ コンテント辞書 ７４６ コンテキストスタックリンクデータ構造 ８００ ユーザ辞書リンク構造 ８１０ ユーザ辞書 ９２０，９２６，９３２ ユーザ辞書リンク構造 ９４０，９４２，９４４ ユーザ辞書

フロントページの続き (56)参考文献 特開 平６−332718（ＪＰ，Ａ) 高橋亨，標準ページ記述言語（ＳＰＤ Ｌ）とその動向，情報処理，社団法人情 報処理学会，1992年 ６月15日，第33巻 第６号，ｐ．689−697 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/45 G06F 3/12 G06F 17/21

Claims (13)

(57)【特許請求の範囲】
1. 【請求項１】 階層構造文書の処理中に使用される状態
   変数を管理する方法であって、 文書のある階層レベルが第１階層レベルであるか判定す
   るステップ、 該文書の階層レベルが第１階層レベルであると判定した
   時に、デフォルトの状態変数を持つ状態変数テーブルを
   生成するステップ、 該文書の階層レベルが第１階層レベルより低いか判定す
   るステップ、 該文書の該階層レベルが第１階層レベルより低いと判定
   した時に、直ぐ上の階層レベルの状態変数テーブル内の
   状態変数と等しい状態変数を持つ状態変数テーブルを生
   成するステップ、を有することを特徴とする状態変数管
   理方法。
2. 【請求項２】 請求項１記載の状態変数管理方法におい
   て、 直ぐ上の階層レベルのコンテント部が処理されている時
   に、パラメータの管理のために用いられる、直ぐ上の階
   層レベルのためのデータ構造が存在するか判定するステ
   ップをさらに有し、 直ぐ上の階層レベルのためのデータ構造は存在しないと
   判定した時に、直ぐ上の階層レベルの状態変数テーブル
   の状態変数と等しい状態変数を持つ状態変数テーブルを
   生成するステップは、直ぐ上の階層レベルの構造部の状
   態変数と等しい状態変数を持つ状態変数テーブルを生成
   し、 直ぐ上の階層レベルのためのデータ構造は存在すると判
   定した時に、直ぐ上の階層レベルの状態変数テーブルの
   状態変数と等しい状態変数を持つ状態変数テーブルを生
   成するステップは、直ぐ上の階層レベルのコンテント部
   の状態変数と等しい状態変数を持つ状態変数テーブルを
   生成する、ことを特徴とする状態変数管理方法。
3. 【請求項３】 階層構造文書の処理中に使用される状態
   変数を管理する方法であって、 直ぐ上の階層レベルの処理中に、パラメータの管理のた
   めに用いられる、直ぐ 上の階層レベルのためのデータ構
   造が存在するか判定するステップ 、直ぐ上の階層レベルのためのデータ構造は存在しないと
   判定した時に、直ぐ上の階層レベルの構造部の状態変数
   と等しい状態変数を持つ状態変数テーブルを生成するス
   テップ、 直ぐ上の階層レベルのためのデータ構造は存在すると判
   定した時に、直ぐ上の階層レベルのコンテント部の状態
   変数と等しい状態変数を持つ状態変数テーブルを生成す
   るステップ、を有することを特徴とする状態変数管理方
   法。
4. 【請求項４】 請求項３記載の状態変数管理方法におい
   て、 文書の構造部が処理される時に構造部状態変数テーブル
   を生成するステップ、 文書のコンテント部の処理中であるか判定するステッ
   プ、 文書のコンテント部の処理中であると判定した時に、構
   造部状態変数テーブル中の状態変数と等しい状態変数を
   持つコンテント部状態変数テーブルを生成するステッ
   プ、をさらに有することを特徴とする状態変数管理方
   法。
5. 【請求項５】 請求項４記載の状態変数管理方法におい
   て、 文書のコンテント部の処理中であるか判定するステップ
   でコンテント部の処理中であると判定した後に実行され
   る以下のステップ、 コンテント部の処理中にコンテント部状態変数テーブル
   内の状態変数を修正するステップ、 直ぐ上位の構造エレメントがセットアッププロシージャ
   であるか判定するステップ、 直ぐ上位の構造エレメントはセットアッププロシージャ
   であると判定した時に、コンテント部の状態変数の修正
   された状態変数を文書の下位の階層部分のための状態変
   数として用いるステップ、 直ぐ上位の構造エレメントはセットアッププロシージャ
   ではないと判定した時に、構造部状態変数テーブルの状
   態変数を文書の下位の構造部のために使用するステッ
   プ、をさらに有することを特徴とする状態変数管理方
   法。
6. 【請求項６】 請求項４記載の状態管理方法において、 文書のコンテント部が終了したか判定するステップ、 文書のコンテントは終了したと判定した時に、コンテン
   ト部状態変数テーブルを削除するステップ、を有するこ
   とを特徴とする状態変数管理方法。
7. 【請求項７】 階層構造文書の処理中に使用される状態
   変数を管理するための方法であって、 文書の構造部を処理するステップ、 構造部状態変数テーブルを生成するステップ、 文書の該構造部に従属したコンテント部を処理するステ
   ップ、 構造部状態変数テーブル内の状態変数と等しい状態変数
   を持つコンテント部状態変数テーブルを生成するステッ
   プ、 文書の該コンテント部が終了したか判定するステップ、 文書の該コンテントは終了したと判定した時に、該構造
   部が状態変数を修正するための構造エレメントを含むか
   判定するステップ、 該構造部は状態変数を修正するための構造エレメントを
   含んでいると判定した時に、コンテント部状態変数テー
   ブル内の状態変数を構造部状態変数テーブルにコピーす
   るステップ、を有することを特徴とする状態変数管理方
   法。
8. 【請求項８】 階層構造文書処理中に使用される状態変
   数を管理するための方法であって、 文書の第１階層レベルの処理のために用いられる第１の
   状態変数を持つ第１の状態変数テーブルを生成するステ
   ップ、 文書の第１階層レベルの処理時に使用されるもので第１
   の状態変数テーブルを参照する第１のエントリーをスタ
   ックにプッシュするステップ、 文書の後続の階層レベルの処理のために使用される後続
   状態変数を持つ後続状態変数テーブルを生成するステッ
   プ、 文書の後続階層レベルの処理時に使用される後続エント
   リーをスタックにプッシュするステップ、 を有することを特徴とする状態変数管理方法。
9. 【請求項９】 請求項８記載の状態変数管理方法におい
   て、 第１のエントリーをスタックにプッシュした後に第１の
   状態変数テーブルを使用して該第１の階層レベルを処理
   するステップ、 後続エントリーをスタックにプッシュした後に後続状態
   変数テーブルを使用して該後続の階層レベルを処理する
   ステップ、をさらに有することを特徴とする状態変数管
   理方法。
10. 【請求項１０】 請求項８記載の状態変数管理方法にお
    いて、 処理中の文書の後続階層レベルが終わった時にスタック
    より後続エントリーをポップするステップ、 処理中の文書の第１階層レベルが終わった時にスタック
    より第１エントリーをポップするステップ、をさらに有
    することを特徴とする状態変数管理方法。
11. 【請求項１１】 請求項８記載の状態変数管理方法にお
    いて、 第１階層レベルのコンテント部の処理時に用いられる第
    １コンテント部状態変数テーブルに第１状態変数テーブ
    ルをコピーするステップ、 第１コンテント部状態変数テーブルへの参照を、スタッ
    クの第１エントリーに書き込むステップ、 第１コンテント部状態変数テーブルを使用して第１階層
    レベルのコンテント部を処理するステップ、をさらに有
    することを特徴とする状態変数管理方法。
12. 【請求項１２】 請求項１１記載の状態変数管理方法に
    おいて、 第１階層レベルのコンテント部を処理するステップは第
    １コンテント部状態変数テーブル内の状態変数を修正す
    るとともに、 コンテント部を処理するステップの後に実行される次の
    ステップ、 文書の該コンテント部の前に出現した構造エレメント
    が、より低い階層レベルの処理のために用いられる状態
    変数を修正するための構造エレメントであるか判定する
    ステップ、 文書の該コンテント部の前に出現した構造エレメントの
    判定のステップで、文 書の該コンテント部の前に出現し
    た後続エレメントは状態変数を修正するための構造エレ
    メントであると判定した時には、コンテント部状態変数
    テーブルを第１構造部状態変数テーブルへコピーし、そ
    うではないと判定した時には、コンテント部状態変数テ
    ーブルを、第１構造部状態変数テーブルにコピーするこ
    となく削除するステップ、をさらに有することを特徴と
    する状態変数管理方法。
13. 【請求項１３】 請求項８記載の状態変数管理方法にお
    いて、 後続状態変数テーブルを生成するステップは第１状態変
    数と等しい後続状態変数を得るための後続状態変数テー
    ブルを生成することを特徴とする状態変数管理方法。