JPH10100484A - コンピュータベースの文書処理方法 - Google Patents

Abstract

(57)【要約】 【課題】 表現性が高いと共にレンダリングが速く安価
である構造化文書表現を提供する。 【解決手段】 文書の解像度に依存しない構造化表現を
含むデジタル情報の第１セットがプロセッサに提供され
る。この第１表現は、種々の画像の集まり（例えばペー
ジ画像のセット）から取得可能である。プロセッサは、
デジタル情報の第１セットから文書の解像度依存構造化
表現を含むデジタル情報の第２セットを生成する。第２
構造化表現は、第１構造化表現から取得可能な画像の集
まりのうち特定の１つのロスレス表現であり、これはト
ークンのセット及び位置のセットを含む。デジタル情報
の第２セットは、特定の画像の集まりのサブ画像を表す
ピクセルデータを含むトークンを第１構造化表現から抽
出し、かつ第１構造化表現から位置を決定することによ
って生成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、プリント可能か又
は表示可能な文書ラスタ画像へのレンダリングに好適な
構造化文書表現に関する。本発明は更に、データ圧縮技
術に関する。

【０００２】

【従来の技術】構造化文書表現は、単なるピクセルのア
レイよりも高度で抽象的なレベルで編成される文書のデ
ジタル表現を提供する。

【０００３】公知の構造化文書表現技術は、文書のレン
ダリングが可能な速度と、文書の表現が可能な表現性
（expressiveness) 又は精巧さ（subtlety) との間にト
レードオフを有する。これは、図１（従来技術）におい
て概略的に示されている。連続体１に沿って左から右に
ゆくにつれ表現の表現性は上昇するが、レンダリング速
度は低下する。従って、純粋なテキスト表現であるＡＳ
ＣＩＩ（American Standard Code for Information Int
erchange）は迅速にレンダリングをするが、フォーマッ
ティング情報又は文書構造に関する他の情報に乏しく、
これは図１の左に示されている。ＰｏｓｔＳｃｒｉｐｔ
（商標名、アドビーシステムズ社（AdobeSystems, In
c.)、カリフォルニア州マウンテンビュー）及びＩｎｔ
ｅｒｐｒｅｓｓ（ゼロックスコーポレーション（Xerox
Corporation)、コネチカット州スタンフォード）などの
ページ記述言語（ＰＤＬｓ）は文書構造に関する情報を
大量に含むが、レンダリングをするためには大幅により
多くの時間を必要とし、これは連続体１の右に示されて
いる。

【０００４】連続体１は、程度が上昇してゆく文書構造
を有する文書表現の１つとして見ることが可能である。 ・ＡＳＣＩＩなどの純粋なテキスト表現はテキスト文書
の文字のみを有し、フォント、レイアウト又は他のペー
ジ記述情報に関する情報をもたず、グラフィック情報又
はテキスト以外の他の情報に関してはなおさらである。 ・インターネットのワールドワイドウェブ（World Wide
Web) 用の文書を表すために使用されるＨＴＭＬ（Hype
rText Markup Language)は、埋め込みグラフィック、画
像、オーディオ及びビデオレコーディング、及びハイパ
ーテキストリンキング能力をサポートするという点では
ＡＳＣＩＩよりも多少柔軟性がある。しかし、ＨＴＭＬ
もフォント及びレイアウト（即ち、実際の文書の外観）
情報に乏しい。異なるウェブクライアント（「ブラウ
ザ」）プログラム又は異なるコンピュータによって、異
なってはいるが同様に「正確な」方法でＨＴＭＬ文書を
レンダリングする（表示可能又はプリント可能な出力に
変換する）可能性がある。 ・ＰｏｓｔＳｃｒｉｐｔ及びＩｎｔｅｒｐｒｅｓｓなど
のページ記述言語は、ページレイアウト、グラフィック
ス及び記号形式で表現される他の文書属性の任意的な複
合構造を許容する全機能プログラミング言語である。 ・連続体１の中央にはＰＣＬ５（ヒューレット−パッカ
ード社、カリフォルニア州パロアルト）などのプリンタ
制御言語があり、これは曲線及び文字のドローイングの
ための基本要素を含んでいる。 ・連続体１の中央にあるが多少ＰＤＬ寄りであるのは、
クロスプラットホーム文書交換フォーマットである。こ
れは、ポータブルドキュメントフォーマット（Portable
Document Format、アドビーシステムズ社) 及びコモン
グラウンド（Common Ground 、コモングラウンドソフト
ウェア社(Common Ground Software)、カリフォルニア州
ベルモント）を含む。ポータブルドキュメントフォーマ
ット、即ちＰＤＦは、Ａｄｏｂｅ Ａｃｒｏｂａｔ（商
品名）と呼ばれるソフトウェアプログラムと共に使用す
ることができる。ＰＤＦは、あらゆる所与の基本要素
（利用可能な基本要素は「ドロー(draw)」、「フィル(f
ill)」、「クリップ」、「テキスト」などを含む）によ
って生じることが可能なドローイング動作及びレンダリ
ング動作の豊富なセットを含むが、例えば基本要素の構
成仕様を許容するプログラミング言語構造を含まない。

【０００５】公知の構造化文書表現技術は、レンダリン
グエンジン（例えば、ディスプレイドライバソフトウェ
ア、プリンタＰＤＬ分解ソフトウェア又は構造化文書表
現からピクセル画像を生成する他のソフトウェア又はハ
ードウェア）が文字フォントのセットへのアクセスを有
することを想定している。レンダリングエンジンは、既
に記憶されていて使用可能である必要なフォントを有す
るものと推定される。通常、文書自体はフォント情報を
供給しない。レンダリングエンジンが文書をレンダリン
グするように要求され、そのレンダリングエンジンがそ
の文書に対して利用可能である必要なフォントをもたな
い場合、レンダリングエンジンは信頼性をもって文書を
レンダリングすることができないであろう。

【０００６】ＰＤＬに対するフォントの基本的な重要性
は、例えば、PostScript LanguageReference Manual (2
d ed. 1990)（以下、PostScript Manual とする) とい
うアドビーシステムズ社のフォントに関するより進んだ
検討によって示されている。

【０００７】フォントに関する基本的な概念は、ラベリ
ング、即ち特定の文字又は記号に与えられる意味論的有
意性の概念である。フォントの各文字又は各記号は、固
有の関連した意味ラベルを有する。ラベリングは、フォ
ントの置換を可能にする。同一の意味ラベルを有する異
なるフォントの文字を、互いに置換することができる。
例えば、図２（従来技術）の各文字２１、２２、２３、
２４、２５、２６は、同一の意味論的有意性を有する。
各々は、英語に一般的に使用されるアルファベットの第
５文字である「Ｅ」の大文字を表している。しかし、各
々は異なるフォントで表されている。

【０００８】ＰＤＬ文書記述を入力として受け入れる公
知のプリンタが、図３（従来技術）に概略的に示されて
いる。プリンタ３０はＰＤＬ記述３５を受け入れ、これ
はレンダリングユニット３１によって解釈され、即ち分
解され、文書のページのラスタ画像３２を生成する。次
に、ラスタ画像３２は画像出力ターミナル（ＩＯＴ）に
送られ、これは画像３２をペーパーシート上の可視のマ
ークに変換する。マークはプリント出力として出力さ
れ、人間のユーザによって使用される。都合の悪いこと
に、レンダリングユニット３１が入力ＰＤＬ記述を分解
できる速度は、ＩＯＴ３３がペーパーシートにマーキン
グしてそれを出力３６として施すことができる速度と通
常合わせることができない。これは、１つにはＰＤＬ記
述の分解結果が明確ではないからである。前述のよう
に、ＰＤＬ記述３５などのＰＤＬ記述は特定の画像又は
画像のセットに対応せず、異なる方法でレンダリングさ
れる可能性がある。従って、レンダリングユニット３１
は、プリンタ３０の全体的なスループットを制限する障
害となる。

【０００９】データ圧縮技術は、文書のピクセル画像の
データアレイなど大きなデータのセットをよりコンパク
トな表現に変換し、この表現から初めの大きなデータセ
ットを完全に又は不完全に回復することができる。回復
が完全である場合、この圧縮技術はロスレス（損失のな
い）と呼ばれ、回復が不完全である場合、この圧縮技術
はロシー（損失のある）と呼ばれる。

【００１０】ロスレス画像圧縮に好適な公知のエンコー
ディング（符号化）技術は、例えばＣＣＩＴＴグループ
−４エンコーディング及びＪＢＩＧエンコーディングを
含む。ロシー画像圧縮に好適な公知のエンコーディング
技術は、例えばＪＰＥＧエンコーディング及び米国特許
第５，３０３，３１３号に開示されるような記号ベース
の圧縮技術を含む。

【００１１】ロシー技術と比較すると、ロスレス圧縮技
術はより大きな忠実度を提供するが、より低い圧縮比及
びより遅い圧縮解除速度を提供する。

【００１２】

【発明が解決しようとする課題】本発明は、表現性が高
いと共にレンダリングが速く安価である構造化文書表現
を提供する。

【００１３】

【課題を解決するための手段】本発明に従って、今まで
はロシー画像圧縮のみに使用されていた圧縮スキームで
ある記号ベースのトークンマッチングを使用して、ＰＤ
Ｌ表現又は他の構造化文書表現から生成されたオリジナ
ル文書画像のロスレス圧縮を達成する。テキスト及びグ
ラフィックスを含む文書はそのオリジナル構造化表現か
ら（それ自体が構造化表現である）トークンベース表現
にコンパイルされ、トークンベース表現はレンダリング
されるピクセル画像の生成に使用される。トークンベー
ス表現は高い圧縮比を得ることができ、フォントのセッ
トを参照せずに迅速かつ忠実にレンダリングすることが
できる。

【００１４】本発明の請求項１の態様は、コンピュータ
ベースの文書処理方法であって、文書の第１構造化表現
を含むデジタル情報の第１セットをプロセッサに提供す
るステップを含み、前記第１構造化表現は解像度に依存
しない表現であり、複数の画像の集まりが前記第１構造
化表現から取得可能であり、このような各取得可能な画
像の集まりは少なくとも１つの画像を含み、前記各集ま
りにおける各画像は前記文書の少なくとも一部分の画像
であり、前記各集まりにおける各画像は固有解像度を有
し、プロセッサを用いて、前記文書の第２構造化表現を
含むデジタル情報の第２セットを前記デジタル情報の第
１セットから生成するステップを含み、前記第２構造化
表現は特定の画像の集まりのロスレス表現であり、前記
特定の画像の集まりは前記第１構造化表現から取得可能
な前記複数の画像の集まりのうちの１つであり、前記第
２構造化表現は複数のトークン及び複数の位置を含み、
前記デジタル情報の第２セットの生成は前記第１構造化
表現から前記複数のトークンを抽出するステップを含
み、各トークンは前記特定の画像の集まりのサブ画像を
表すピクセルデータのセットを含み、前記第１構造化表
現から前記複数の位置を決定するステップを含み、各位
置は前記特定の画像の集まりにおけるトークンサブ画像
の位置であり、前記トークンサブ画像は前記トークンの
うちの１つからのサブ画像のうちの１つであり、少なく
とも１つのトークンサブ画像は複数のピクセルを有する
と共に前記特定の画像の集まりにおいて１つよりも多い
位置で生じ、このようにして生成された前記デジタル情
報の第２セットを後の使用のために利用可能にするステ
ップを含む。

【００１５】本発明の請求項２の態様は、請求項１の態
様において、前記提供ステップが前記文書のフォントベ
ースの第１構造化表現をプロセッサに提供することを含
み、前記生成ステップが前記文書のフォントレス第２構
造化表現を生成することを含む。

【００１６】本発明の請求項３の態様は、コンピュータ
ベースの文書処理方法であって、請求項１に記載のよう
に生成し、利用可能にした前記デジタル情報の第２セッ
トをプロセッサに提供するステップを含み、前記デジタ
ル情報の第２セットがこのように提供される前記プロセ
ッサを「デコーディング」プロセッサと呼び、前記デコ
ーディングプロセッサを用いて、少なくとも１つの画像
を含む画像の集まりを有するデジタル情報の第３セット
を前記デジタル情報の第２セットから生成するステップ
を含み、前記デジタル情報の第３セットによって含まれ
る画像の集まりにおける各画像は文書の少なくとも一部
分の画像であり、前記画像の集まりにおける各画像に
は、前記トークンサブ画像からなると共に少なくとも１
つの前記位置においてトークンサブ画像を含む前記デジ
タル情報の第３セットが含まれており、このようにして
生成された前記デジタル情報の第３セットを後の使用の
ために利用可能にするステップを含む。

【００１７】

【発明の実施の形態】本発明の特定の実施の形態による
と、ＰｏｓｔＳｃｒｉｐｔ又は他のＰＤＬ表現などの構
造化文書表現、あるいはＰＤＦ又は他の文書交換言語表
現はコンパイルされ、そうでなければ後述するＤｉｇｉ
Ｐａｐｅｒフォーマットなどのトークン化（tokenized)
ファイルフォーマットに変換される。トークン化表現
は、プリント、表示、記憶、伝送などが可能であるビッ
トマップ又はＣＣＩＴＴグループ４圧縮ビットマップな
どの文書画像の非構造化表現に迅速にレンダリングされ
ることが可能である。

【００１８】好適な実施の形態では、本発明の方法は、
コンピュータ又は他のプロセッサによって、文書の固有
の視覚的外観を定めない、解像度に依存しない初期構造
化文書記述を、文書の固有の視覚的外観を定める解像度
依存構造化文書記述に自動変換することを考慮してい
る。

【００１９】例えば、本発明を使用して、従来技術のＰ
ＤＬプリンタに固有のレンダリング速度の障害（図３に
関連するプリンタ３０の上の記述を参照）を取り除くこ
とによってプリンタのスループットを向上させることが
できる。ＤｉｇｉＰａｐｅｒファイルを予測可能な速度
で迅速にデコード（復号）できるため、この障害を取り
除くことができる。

【００２０】図４は、本発明の特定の実施の形態に従っ
て、完全な圧縮−圧縮解除サイクルにおいて文書の構造
化表現に適用される変換の全体的なシーケンスを示して
いる。変換されるべき文書は、ブラックとホワイトのテ
キスト及びグラフィックスを含む文書のような１つ又は
それより多くのバイナリ（二値）画像のセットとしてレ
ンダリング可能な文書であると想定される。文書のＰＤ
Ｌ表現４０は、文書のトークン化表現４２を生成するト
ークン化コンパイラ４１に入力される。トークン化表現
４２は、出力バイナリ画像４４を生成するレンダリング
エンジン４３に入力される。

【００２１】トークン化コンパイラ４１はコンプレッサ
（圧縮装置）とも呼ばれ、トークン化表現４２は圧縮表
現とも呼ばれる。トークン化表現４２は、それが出力ビ
ットマップ４４よりも小規模であるという意味で圧縮さ
れる。従って、入力ＰＤＬ文書表現からのトークン化文
書表現の生成（例えば、入力ＰＤＬ表現４０からのトー
クン化表現４２の生成）は変換シーケンスの圧縮段階と
呼ばれ、トークン化表現からの出力画像の生成（例え
ば、トークン化表現４２からの出力バイナリ画像４４の
生成）はシーケンスの圧縮解除段階と呼ばれる。

【００２２】図５は、ＰＤＬ表現４０がトークン化コン
パイラ４１に入力され、これによってトークン化表現４
２が生成される態様を再び示している。ここでは、トー
クン化コンパイラ４１がより詳細に示されている。トー
クン化コンパイラ４１は、ＰＤＬデコンポーザ４５を介
して入力ＰＤＬ表現４０を処理し、１つ又はそれより多
くのページ画像４６を生成することによって始まる。Ｐ
ＤＬデコンポーザ４５は、公知のプリンタ及びディスプ
レイにおいてＰＤＬファイルを出力画像にするために通
常使用されるものであり、例えばＰｏｓｔＳｃｒｉｐｔ
入力ファイル４０に対しては、プロセッサによって実行
されるＰｏｓｔＳｃｒｉｐｔインタプリタプログラムと
してＰＤＬデコンポーザ４５を実施することができる。
ページ画像４６は、文書のページを表すビットマップ又
は圧縮ビットマップである。ページ画像４６は、トーク
ン化装置即ちコンプレッサ４７によって圧縮される。コ
ンプレッサ４７はページ画像を受け取ってＤｉｇｉＰａ
ｐｅｒ又は他のトークン化データストリーム又はファイ
ルを構築し、次にコンプレッサ４７はこれを記憶して伝
送することができ、又は他の方法で更なる処理を可能に
する。従って、コンプレッサ４７の出力はトークン化表
現４２である。

【００２３】プロセッサによって実行されるソフトウェ
アプログラムとして、コンプレッサ４７を実施すること
が可能である。この実施の形態においてコンプレッサ４
７がトークン化（圧縮）を実行しうるステップは、図１
４及び付随のテキストを参照して後述される。この実施
の形態においてトークン化表現４２に好適なフォームで
あり、従ってコンプレッサ４７の出力に好適なフォーム
であるＤｉｇｉＰａｐｅｒファイルフォーマットは、図
１６〜図２３及び付随のテキストの１〜８のセクション
に関連して後述される。

【００２４】トークン化表現４２を生成するもう１つの
方法も図５に示されている。この方法によると、ＰＤＬ
デコンポーザ４５は標準のＰＤＬデコンポーザではなく
コンプレッサ４７に密接に結合されるような態様でトー
クン化コンパイラ４１がデザインされているため、中間
ページ画像４６は生成されない。この代わりの方法は、
入力ＰＤＬ記述４０のトークン化表現４２への直接的コ
ンパイルと呼ぶことができる。これは、矢印４９によっ
て示される。

【００２５】図６の一組の２つの図は、図４の変換シー
ケンスの圧縮段階及び圧縮解除段階が互いから分離可能
であることを示している。図（Ａ）では、圧縮段階が生
じている。ＰＤＬ文書記述６０はトークン化コンパイラ
６１に入力され、トークン化表現６２を生成する。次
に、トークン化表現６２は６３において後の使用のため
に保存される。例えば、ハードディスクのファイル、別
のコンピュータへのネットワーク又は出力デバイスにト
ークン化表現６２を記憶することができる。

【００２６】図６の図（Ｂ）では、圧縮解除段階が生じ
ている。６４では、圧縮解除及び出力を行うデバイスに
よってトークン化表現６５を得る。例えば、記憶装置か
らトークン化表現６５を検索することができ、又はネッ
トワークを介してこれを受け取ることができる。トーク
ン化表現６５はレンダリングエンジン６６に入力され、
これは、表示、プリント、ファックス、伝送などが可能
であるページ画像又はページ画像のセットとして文書を
出力する。

【００２７】好ましくは、トークン化表現６５は、解像
度がレンダリングエンジン６６の出力解像度とマッチす
る画像又は画像のセットから生成された（即ち、圧縮さ
れた）表現である。

【００２８】レンダリングエンジン６６としての使用に
好適なレンダリングエンジンのいくつかの例が図７〜図
８に示されている。図７は、ＤｉｇｉＰａｐｅｒファイ
ルなど、トークン化表現からの文書をプリントできるプ
リンタ７６を概略的に示している。プリンタ７６は、ト
ークン化表現７５のような入力トークン化表現を受け入
れ、この表現をプリント出力に変換するようにデザイン
されている。これは内蔵ＰＤＬデコンポーザを必要とし
ないため、この内蔵計算力は非常に小さくてよい。プリ
ンタ７６は、デコンプレッサ（圧縮解除装置）７１を用
いて入力トークン化表現７５を圧縮解除することによっ
て動作する。デコンプレッサ７１は、例えば、圧縮解除
ソフトウェアを実行する内蔵プロセッサとすることがで
きる。あるいは、専用ハードウェアにおいて実施が可能
である。デコンプレッサ７１は１つ又はそれより多くの
ラスタ画像７２のセットを生成し、これはプリント文書
の各ページ毎に１つである。ラスタ画像は、プリント出
力７７を生成する従来のＩＯＴ７３に提供される。

【００２９】図８は、入力トークン化表現が与えられた
文書を表示できるビジュアルディスプレイ８６を概略的
に示している。この概念は、プリンタ７６に類似してい
る。ディスプレイ８６は、トークン化表現８５などの入
力トークン化表現を受け入れ、デコンプレッサ８１を用
いてこれを圧縮解除する。デコンプレッサ８１は１つ又
はそれより多くのラスタ画像８２のセットを生成し、こ
れはプリント文書の各ページ毎に１つである。ラスタ画
像は、人間によって可読である出力を生成するカソード
レイチューブ（ＣＲＴ）又はフラットパネルモニタスク
リーンなどのディスプレイターミナル８３に提供され
る。

【００３０】図７〜図８に示されるレンダリングエンジ
ンの例７６、８６はプリントページ又はディスプレイペ
ージとしてすぐに可視である出力画像を生成するが、他
のレンダリングエンジンが他の種類の画像出力を生成す
ることが可能である。特に、レンダリングエンジン６６
としての使用に好適なレンダリングエンジンからの出力
は、エンコード（符号化）されたビットマップ（例え
ば、遠隔のファックス又は多機能デバイスによって受け
取られるＣＣＩＴＴグループ４伝送）でもよいし、又は
他の非構造化文書フォーマットでもよい。

【００３１】この実施の形態において、デコンプレッサ
７１及びデコンプレッサ８１などのデコンプレッサが圧
縮解除を行うことが可能であるステップは、図１５及び
付随のテキストに関連して後述される。

【００３２】図９は、図４の変換シーケンスの圧縮段階
を行うために好適な例示的システムのハードウェア構成
要素及びソフトウェア構成要素を示している。図９のシ
ステムは汎用コンピュータ１００を含み、これは接続１
２９などの１つ又はそれより多くの通信経路によって、
ローカルエリアネットワーク（ＬＡＮ）１４０及びここ
ではインターネット１８０として示されるワイドエリア
ネットワークに接続されている。コンピュータ１００
は、ＬＡＮ１４０を介してファイルサーバ１４１などの
他のローカルコンピュータと通信できる。コンピュータ
１００は、インターネット１８０を介してワールドワイ
ドウェブサーバ１８１などの他のローカルコンピュータ
及び遠隔コンピュータと通信することができる。理解さ
れるように、コンピュータ１００からインターネット１
８０への接続を種々の方法で行うことができ、例えば接
続１２９を直接介したり、ローカルエリアネットワーク
１４０を介したり又はモデム（図示せず）によって行う
ことができる。

【００３３】コンピュータ１００はパーソナルコンピュ
ータ又はオフィスコンピュータであり、これは例えばワ
ークステーション、パーソナルコンピュータ又は他のコ
ンピュータシステムとすることができる。説明のため
に、コンピュータ１００をハードウェア構成要素１０１
及びソフトウェア構成要素１０２に有意に分けることが
できる。

【００３４】ハードウェア構成要素１０１は、プロセッ
サ（ＣＰＵ）１０５、メモリ１０６、固定記憶装置１０
８、ユーザＩ／Ｏ１２０及びネットワークインターフェ
イス１２５を含む。

【００３５】プロセッサ１０５は、例えばマイクロプロ
セッサか又はマルチ処理用に構成されるプロセッサの集
まりとすることができる。

【００３６】メモリ１０６は、ＲＯＭ、ＲＡＭ、仮想メ
モリ又は他のメモリ技術を含むことが可能である。固定
記憶装置１０８は、例えば磁気ハードディスク、フロッ
ピーディスク又は他の固定読み書きデータ記憶技術を含
むことができ、ＣＤ−ＲＯＭ又は他の大容量記憶技術に
よって提供できるような大容量記憶装置又はアーカイブ
記憶装置を更に含むことが可能である。（ファイルサー
バ１４１は、プロセッサ１０５が使用可能な追加の記憶
能力を提供することに注意する。）

【００３７】ユーザＩ／Ｏ（入力／出力）ハードウェア
１２０は、ＣＲＴ又はフラットパネルディスプレイなど
のビジュアルディスプレイモニタ、英数字キーボード及
びマウス又は他のポインティングデバイスを通常含み、
必要に応じて、プリンタ、光学スキャナー又はユーザ入
出力のための他のデバイスを更に含むことが可能であ
る。

【００３８】ネットワークＩ／Ｏハードウェア１２５
は、コンピュータ１００と外界との間に接点を提供す
る。より詳細には、ネットワークＩ／Ｏ１２５によって
プロセッサ１０５は接続１２９、ＬＡＮ１４０及びイン
ターネット１８０を介して他のプロセッサ及びデバイス
と通信することができる。

【００３９】ソフトウェア構成要素１０２は、オペレー
ティングシステム１５０、アプリケーションプログラム
１６０などのオペレーティングシステム１５０の制御下
のタスクのセット、そして重要なことにトークン化コン
パイラソフトウェア１６５を含む。オペレーティングシ
ステム１５０により、プロセッサ１０５は固定記憶装置
１０８、ユーザＩ／Ｏ１２０及びネットワークインター
フェイス１２５など種々のデバイスを制御することもで
きる。プロセッサ１０５は、メモリ１０６及びコンピュ
ータシステム１００の他の構成要素と関連してオペレー
ティングシステム１５０及びそのタスク１６０、１６５
のソフトウェアを実行する。

【００４０】ソフトウェア構成要素１０２は、本発明に
従ってトークン化コンパイラとして機能する能力をコン
ピュータ１００に提供する。

【００４１】図９では、トークン化能力は主にタスク１
６５によって提供されている。

【００４２】図１０は、図４の変換シーケンスの圧縮解
除段階を多様な方法で実行できるシステムを示してい
る。図１０の例示的なシステムは、図９のシステムのス
ーパーセットとして示されている。特に、このシステム
はコンピュータ１００、ファイルサーバ１４１、ウェブ
サーバ１８１、ＬＡＮ１４０及びインターネット１８０
を含む。更に、図１０のシステムは種々のシステム構成
要素２００を加えており、これらを使用して文書のトー
クン化表現をレンダリングできる。構成要素２００は、
第２の汎用コンピュータ２１０、ネットワークプリンタ
２２０、プリントサーバ２３０及び「スマート（smar
t)」多機能デバイス２４０を含む。

【００４３】図１０のシステムの動作において、先にＰ
ＤＬ表現からトークン化表現に変換された文書（例え
ば、コンピュータ１００内のトークン化コンパイラ１６
５によって生成された文書；ファイルサーバ１４１又は
ウェブサーバ１８１からの文書）がネットワーク接続２
２９を介して構成要素２１０、２２０、２３０、２４０
のうちの１つ又はそれより多くにおいて利用可能にな
る。これらの構成要素の各々はレンダリングエンジンと
して、特にデコンプレッサとして機能することができ
る。各々は、プロセッサが文書のトークン化表現を得る
ことを可能にする通信ソフトウェアと、プロセッサがト
ークン化表現を特定の出力形式に好適な画像データに変
換することを可能にする圧縮解除ソフトウェアとを含む
ものと想定される。圧縮解除ソフトウェアは構成要素に
内在してもよいし、あるいはトークン化表現と共にＬＡ
Ｎ１４０又はインターネット１８０から接続２２９を介
してダウンロードされてもよい。

【００４４】コンピュータ２１０は、コンピュータ１０
０に類似する特徴及びハードウェア構成要素を備える汎
用コンピュータが可能である。また、コンピュータ１０
０のように、コンピュータ２１０は１つ又はそれより多
くのタスクを制御するオペレーティングシステムを含む
ソフトウェアを有する。しかし、コンピュータ１００は
圧縮ソフトウェアを有するが、コンピュータ２１０は圧
縮解除ソフトウェアを有する。（もちろん、コンピュー
タのメモリに圧縮ソフトウェア及び圧縮解除ソフトウェ
アの双方をロードすることができ、いくつかの場合では
単一のコンピュータが圧縮コンピュータ１００及び圧縮
解除コンピュータ２１０の双方として動作できることに
注意する。）

【００４５】コンピュータ２１０は、ディスプレイモニ
タ２１１、ローカルプリンタ２１２、モデム２１３、固
定記憶デバイス２１４及びネットワーク出力ハードウェ
ア２１５に接続して示されている。コンピュータ２１０
はこれらのデバイスを制御でき、特にこれらの各々に適
切な圧縮解除ソフトウェアをランすることができる。

【００４６】例えば、ディスプレイモニタ２１１に適切
な圧縮解除ソフトウェアを実行することにより、コンピ
ュータ２１０のプロセッサはディスプレイモニタ２１１
が表示可能な形式にトークン化表現を圧縮解除すること
ができる。従って、コンピュータ２１０及びディスプレ
イモニタ２１１は共にビジュアルディスプレイ用のレン
ダリングエンジンとして機能する。同様に、コンピュー
タ２１０及びローカルプリンタ２１２は文書のトークン
化表現をハードコピー出力としてレンダリングすること
ができる。コンピュータ２１０が圧縮解除の動作を行う
ため、ローカルプリンタ２１２は内蔵計算ハードウェア
が殆どないか又は全くない「ダム（dumb) 」プリンタで
もよい。

【００４７】更に、コンピュータ２１０は人間によって
すぐに可読ではないがそれにもかかわらず有用である形
式で文書画像をレンダリングすることができる。コンピ
ュータ２１０は、非構造化（例えば、ＣＣＩＴＴグルー
プ−４）圧縮フォーマットの画像データを出力する圧縮
解除ソフトウェアをランすることができ、モデム２１３
によって電話回線をわたってこの画像データを伝送する
ことができる。コンピュータ２１０はまた、圧縮されて
いない画像データ又は圧縮された画像データを後の検索
のために固定記憶装置２１４に出力することもでき、圧
縮されていない画像データ又は圧縮された画像データを
ネットワーク出力デバイス２１５に出力して他の場所
（例えば、ＬＡＮ１４０内の別のコンピュータ又はイン
ターネット１８０）に伝送することもできる。後述する
ように、圧縮解除された文書がハイパーテキストリンク
又は他の注釈を含む場合、コンピュータ２１０はこのよ
うな注釈のうちユーザが示した選択物を解釈し、画像デ
ータと共にネットワークを介してこれらの選択物を伝送
することが可能である。

【００４８】ネットワークプリンタ２２０は、ＣＰＵ及
びメモリを含む独自の内蔵計算ハードウェアを有するプ
リンタである。従って、ローカルプリンタ２１２とは異
なり、ネットワークプリンタ２２０はホストコンピュー
タ又はサーバに助けられずに独自の圧縮解除を行うこと
ができる。従って、ネットワークプリンタ２２０は完全
に独立したレンダリングエンジンであり、トークン化入
力ファイルをハードコピー出力に変換することができ
る。この点では、図７に示されたプリンタ７６に類似し
ている。

【００４９】図１０をひき続き参照すると、プリントサ
ーバ２３０は、「ダム」プリンタを制御できると共にこ
のようなプリンタによってプリントされるファイルの一
時的な記憶に使用されうるコンピュータである。汎用コ
ンピュータ２１０は人間ユーザによって対話式に使用さ
れるコンピュータと想定されるが、プリントサーバ２３
０はプリンタ及びプリントジョブの制御に主に使用され
るコンピュータである。このプロセッサは圧縮解除ソフ
トウェアを実行して画像を生成し、すぐプリントするた
めにＩＯＴ２３１に送るか、プリントの前に予備の検査
を行うためにプレス前ビューア２３２に送るか、後のプ
リントのために又はプリプレス（prepress) ビューイン
グのためにプリントサーバ２３０の固定記憶装置にスプ
ールする（一時的に記憶する）ことが可能である。

【００５０】多機能デバイスは、プリント機能、コピー
機能、走査機能及びファクシミリ機能の組み合わせを提
供する独立型デバイスの種類である。多機能デバイス２
４０は「スマート」デバイスであり、独自のプロセッサ
及びメモリを有し、ホストコンピュータ又はサーバから
援助されずに独自のトークン化ファイルを圧縮解除する
ために十分な計算力を有するものと想定される。ここで
は、ネットワーク出力デバイス２４２を介してネットワ
ークに出力を提供するものとして示されている。多機能
デバイス２４０がペーパーユーザインターフェイスをサ
ポートするソフトウェアを有する場合、出力データは画
像データの他にハイパーテキストリンクセレクション又
は他の情報を含むことができる。多機能デバイス２４０
はまた、圧縮画像データをファクシミリマシン２４１に
提供するものとして示されている。例えば、多機能デバ
イス２４０は通常の電話によってファクシミリマシン２
４１にコンタクトし、ＣＣＩＴＴグループ−４フォーマ
ットの圧縮画像データをファクシミリマシン２４１に送
ることができる。ファクシミリマシン２４１は、あらゆ
る他のファックス通信のように多機能デバイス２４０か
らファックス通信を受け取り、文書のコピーをプリント
アウトする。

【００５１】好適な実施の形態では、トークン化コンパ
イラによって生成されたトークン化文書表現は、図１６
〜図２３を参照して後述するＤｉｇｉＰａｐｅｒフォー
マットで編成される。ＤｉｇｉＰａｐｅｒフォーマット
の詳細を容易に理解するため、まず図１１〜図１３を参
照していくつかの簡略化トークン化フォーマットを考慮
する。これらの簡略化フォーマットは、本発明において
使用されるトークン化表現において基本的であるいくつ
かの概念を例示する目的で表され、ＤｉｇｉＰａｐｅｒ
を含むがこれに限定されない。

【００５２】図１１は、非常に簡略化された例によって
トークン及び位置の概念を示している。画像１１００が
示される１ページの入力文書は、テキスト１１０１を含
む。この文書をトークン化表現１１１０に変換すること
ができる。トークン化表現１１１０は、トークン１１１
１のセット（又は辞書）と位置１１１２のセットとを含
む。

【００５３】トークン１１１１の各々は、文書内のどこ
かで生じる形を表している。各トークンの形は、ビット
マップとして記憶される。位置１１１２の各々は、トー
クンのうちの１つが配置されるべき場所、即ちトークン
の形が文書内で生じる場所を表している。例えば、第１
のトークンに関連する形「ｔ」は、（Ｘ、Ｙ）座標が順
序対（１０、２０）である位置に現れる。第２のトーク
ンと関連する形「ｈ」は、（Ｘ、Ｙ）座標が順序対（２
０、３０）である位置に現れる。一般に、位置１１１２
の各々は、トークンインデックス、即ちトークン１１１
１のうち特定した１つのトークンを示すインデックス
と、示されるトークンの形が文書内で現れる場所を示す
（Ｘ、Ｙ）座標対とを含む。

【００５４】文書画像１１００からトークン化表現１１
１０を生成するために、コンピュータは文書画像内に現
れる異なる形を検出し、それらが現れる場所を注釈する
ことができる。コンピュータは各形を見つけ、その形が
すでにトークン辞書にあるかを決定し、なければその形
を辞書に加え、いずれの場合でも位置のセットにその位
置を記憶する。

【００５５】トークン化表現１１１０から画像を再構築
するために、コンピュータは位置１１１２を連続的に読
み取り、各位置毎に、リストされた（Ｘ、Ｙ）座標にイ
ンデックスがリストされているトークンの形を転送する
ことができる。

【００５６】トークン１１１１のセットはフォントでは
ないことに注意する。本発明による文書のトークン化表
現は、意味論的ラベリングの概念、文字のセットの概
念、文字コードのセットを文字名のセットにエンコード
したりマッピングしたりすることを含まない。「ｔ」、
「ｈ」、「ｉ」などの形は、形としてのみ、即ち特定の
ビットマップとして処理され、アルファベットの文字又
は文字コードのより大きなセットのメンバーとしては処
理されない。これらの形は、固定された順序ではなく文
書画像１１０１に現れた順で辞書に現れる。

【００５７】記号的意味を全くもたない形を含め、文書
内に繰り返し生じるあらゆる形をトークンの形として使
用できる。反対に、２つの異なる形として（例えば、２
つの異なるサイズ又は２つの異なる書体で）レンダリン
グされるべきアルファベットの所与の文字は、２つの異
なるトークンとして割り当てられる。

【００５８】画像１１００のような１ページの文書画像
に関しては、ページ情報をトークン化表現にエンコード
する必要はない。より長い文書の複数ページの画像に関
しては、トークン化表現はどのトークンの形がどのペー
ジに現れるかに関する情報を含むべきである。このため
に、文書の各ページ毎に位置の別個のセットを維持する
ことができる。

【００５９】図１２及び図１３は、複数ページのトーク
ン化フォーマットに関するいくつかの可能性を示してい
る。図１２は文書のトークン化表現（カプセル化とも呼
ばれる）１２００を示しており、このレンダリング画像
の長さはｎページである。トークン化表現１２００は、
ファイルヘッダ１２０５と、トークン及びその形を含む
辞書ブロック１２０６とによって始まる。この後には、
複数ページの文書画像のページのためのブロックのシー
ケンスが続く。ブロック１２１１、１２１２及び１２１
５はページ１に関し、ブロック１２２１、１２２２及び
１２２５はページ２に関し、（エリプシス１２５０によ
って表されるように）残りのページも同様であり、これ
はページｎに関するブロック１２９１、１２９２及び１
２９５を含む。

【００６０】表現１２００の各ページ毎に、ページヘッ
ダブロック、位置ブロック及び残留ブロックがある。例
えば、ブロック１２１１はページ１のヘッダブロックで
あり、ブロック１２１２はページ１の位置ブロックであ
り、ブロック１２１５はページ１の残留ブロックであ
る。ページヘッダブロックは新しいページの始まりを示
し、追加のページ特有の情報を含むことができる。位置
ブロックは、現行ページのどの位置にどのトークンを配
置すべきかを記録する。残留ブロックは、文書中に１度
しか現れない形など、このページに現れるがトークン辞
書にはない形がある場合にそれを記憶する。

【００６１】図１３は、複数ページの文書のトークン化
表現１３００を示している。最初の２ページのみが示さ
れており、残りの文書はエリプシス１３５０で示されて
いる。フォーマットは図１２のトークン化表現１２００
のものと類似しているが、ファイルにわたって複数の辞
書ブロックがインターリーブしている。トークン化表現
１３００はファイルヘッダ１３０５で始まり、次にペー
ジ１の辞書ブロック１３１０、ページヘッダ１３１１、
位置ブロック１３１２及び残留ブロック１３１５が続
く。辞書ブロック１３１０は、文書画像のページ１に現
れる全ての形を含む。この後、トークン化表現１３００
はページ２の追加の辞書ブロック１３２０に続き、この
後にページ２のページヘッダ１３２１、位置ブロック１
３２２及び残留ブロック１３２５が続く。辞書ブロック
１３２０は、文書画像のページ２に初めて現れる全ての
形、即ちページ１のレンダリングには不要であったがペ
ージ２のレンダリングに必要な形を含む。従って、これ
らの新しい形はページ２のレンダリングに使用される辞
書に加えられる。このフォーマットは、全てのページが
処理されるまでこの態様で続く（エリプシス１３５
０）。文書画像の後に続くページをレンダリングするた
めに何度も現れる形の新しいセットが必要である度に、
追加の辞書ブロックをフォーマットに含むことができ
る。

【００６２】トークン化表現のフォーマットを拡張し
て、容易にトークン化されない情報を許容することがで
きる。例えば、文書のソース構造化表現がブラック及び
ホワイトのテキストとカラー写真とを含む場合、ＪＰＥ
Ｇ又は他の圧縮技術を用いてカラー写真の画像を圧縮
し、本発明によるＤｉｇｉＰａｐｅｒ又は他のトークン
化圧縮を用いてブラック及びホワイトのテキストを圧縮
することができる。トークン化フォーマットがこのよう
な拡張をサポートする場合、ＪＰＥＧによって圧縮した
写真、即ちそのポインタをそのページの位置ブロックの
拡張セクションに記憶することができる。特に、位置ブ
ロック拡張は位置依存情報を有することができ、辞書ブ
ロック拡張は文書中の１つよりも多くの場所で再び使用
される情報を有することができる。

【００６３】拡張を使用して、例えばワールドワイドウ
ェブ（World Wide Web) ページなどのハイパーテキスト
文書のトークン化圧縮をサポートすることができる。ウ
ェブページとして意図されるＨＴＭＬ文書が本発明によ
るトークン化表現に圧縮される場合、その表示可能なテ
キスト及びビットマップグラフィックをトークン化し、
そのリンク情報（即ち、ユニバーサルリソースロケー
タ、即ちＵＲＬの情報）を拡張内に記憶することができ
る。

【００６４】拡張を使用して、テキスト文書に埋め込ま
れたアクティブスプレッドシートなど、埋め込みオブジ
ェクトを含むオブジェクトのトークン化圧縮をサポート
することも可能である。

【００６５】図１４は、構造化文書表現をトークン化表
現にコンパイルするステップのシーケンスを示してい
る。構造化文書表現をワーキングメモリに読み込み（ス
テップＡ）、従来のＰＤＬデコンポーザによって各ペー
ジに１つであるビットマップ画像のセットにレンダリン
グする（ステップＢ）。この後、コンプレッサによって
トークン化圧縮を行う（ステップＣ、Ｄ及びＥ）。ま
ず、ビットマップ画像を分析してその中の形を識別する
（ステップＣ）。次に、同一の形が複数現れた場合に同
一のトークンに割り当てられるように、これらの形を分
類する（ステップＤ）。この後、ハイパーテキストリン
ク又は埋め込み非バイナリ画像構成要素などのあらゆる
拡張と共に、トークン辞書、位置情報及び残留物をエン
コードする（ステップＥ）。これによってトークン化圧
縮表現の構築を完了し、次にこれを出力する（ステップ
Ｆ）。

【００６６】形を識別するステップ（ステップＣ）は、
あらゆる他の適切な技術を使用することができるが、こ
の特定の実施の形態では連結要素分析を用いて行われ
る。形を分類するステップ（ステップＤ）は、この特定
の実施の形態では非常に簡潔なロスレス識別子を用いて
行われる。このロスレス識別子では、２つの形のビット
が同一である場合のみこれらは互いにマッチするものと
みなされる。

【００６７】ステップＢにおいて使用されるＰＤＬデコ
ンポーザは、例えば図５のデコンポーザ４５でありう
る。ステップＣ〜ステップＥにおいて使用されるコンプ
レッサは、例えば図５のコンプレッサ４７でありうる。
（図５の矢印４９による直接的コンパイラは、ステップ
ＡからステップＥに直接に進む。）

【００６８】図１５は、トークン化表現を出力画像にレ
ンダリングするステップを示している。トークン化表現
をワーキングメモリに読み込ませる（ステップＧ）。こ
の後、デコンプレッサがファイルのブロックを読み取る
とループが開始する（ステップＨ）。次のブロックが辞
書ブロックである場合（ステップＩ）、辞書ブロックを
読み取り（ステップＪ）、ワーキングメモリに記憶され
た辞書内にすでにあるあらゆるトークンにそのトークン
を加える（ステップＫ）。あるいは、次のブロックがペ
ージヘッダである場合（ステップＬ）、そのページを圧
縮解除してレンダリングする（ステップＭ〜ステップ
Ｑ）。即ち、ページの位置ブロックを読み取り、ワーキ
ングメモリに目下記憶されている辞書のトークンのセッ
トに関してブロックを解釈する（ステップＭ）。残留ブ
ロックも読み取る（ステップＮ）。次に、ページの位置
ブロックからの情報と目下記憶されている辞書のトーク
ンとを用いて、トークン化記号をページのビットマップ
画像に変換する（ステップＯ）。トークンの個々のビッ
トマップを、（例えばｂｉｔ−ｂｌｔ動作を用いて）ペ
ージを構築しているより大きなビットマップに転送す
る。また、この時点であらゆる拡張を処理する。次に残
留物をレンダリングし、これらのビットマップも同様に
より大きなビットマップに転送する（ステップＰ）。デ
ィスプレイスクリーン、ＩＯＴ、固定記憶装置、ネット
ワーク、ファックス又は他の出力メカニズムに完成した
ページ画像を出力する（ステップＱ）。トークン化表現
全体（又はそのあらゆる所望の部分）を処理する（ステ
ップＲ）までループを続ける（ステップＨ）。

【００６９】ＤｉｇｉＰａｐｅｒフォーマット 便宜上１〜８で番号づけされている次のいくつかのセク
ションは、本発明の好適な実施の形態において使用され
る文書のトークン化表現用のフォーマットを詳細に表し
ている。図１６〜図２３を参照して説明されるフォーマ
ットはＤｉｇｉＰａｐｅｒフォーマットと呼ばれ、図１
１〜図１３に関連して前述した簡略化トークン化表現よ
りも好ましい。

【００７０】セクション１は、ＤｉｇｉＰａｐｅｒフォ
ーマットのデザインに影響を及ぼしたデザイン基準を述
べている。セクション２は、より高レベルのデータスト
リーム構造を参照せずにこのフォーマットにおける圧縮
データストリームの構成要素の概要を述べている。セク
ション３〜セクション５は、これらの構成要素の各々を
より詳しく説明している。セクション６は、ハフマンツ
リーを構築するために使用されるアルゴリズムを述べて
いる。セクション７は、構成要素をカプセル化するより
高レベルのデータストリームの説明をしている。セクシ
ョン８は、このデータストリームフォーマットのいくつ
かの追加のアスペクトを述べている。

【００７１】１．導入部 このコーディングフォーマットのデザインに影響を与え
た基準は以下を含む： ・複数ページ文書のために得られる圧縮は単一ページ文
書のために得られる圧縮よりもかなり優れているため、
単一ストリームで複数ページをエンコードすることが可
能であるべきである。 ・このフォーマットでエンコードされる文書がファイル
に記憶される場合、全ての先行ページを完全にパーズす
ることを必要とせずにあらゆる所与のページを再生成す
ることが可能であるべきである。 ・フォーマット内の個々の値のコーディングは、優れた
圧縮の目的と首尾一貫して出来るだけ簡潔であるべきで
ある。これにより、低コストデバイスにおける実施が可
能になる。

【００７２】２．データストリーム構成要素 データストリームは、多数のページからなる文書をエン
コードする。データストリームは、いくつかの辞書ブロ
ック、位置ブロック及び残留ブロックを含む。全てのバ
イトはＭＳＢからＬＳＢに埋められる。他の方法が指定
されない限り、全ての３２ビット値は符号を付けられ
ず、本明細書末尾の表１（以下、表２〜表１２も同様に
本明細書の末尾に示す）を使用してエンコードされる。

【００７３】２．１．辞書ブロック 辞書ブロックは、トークンの数に関する情報を含む。各
トークンのビットマップ（及び関連サイズと幅）が辞書
ブロックに記憶されている。各トークンに関するいくつ
かの他の情報もまた、辞書ブロックに記憶されている。
詳細には、各トークンの使用数（その使用カウント）が
トークンと共にエンコードされる。これにより、デコー
ダ（復号装置）は各トークンの数のエンコーディングを
示すハフマンツリーを構築することができる。

【００７４】辞書ブロックはページ同士の間に任意的に
インタリーブすることが可能であるが、最初の位置ブロ
ックの前に少なくとも１つの辞書ブロックがなくてはな
らない。

【００７５】２．２．位置ブロック 位置ブロックは多数の三重対を含み、その各々が、Ｘ座
標、Ｙ座標及びトークンの数を含んでいる。あらゆる所
与の位置ブロックにおいて参照されるトークンは、（デ
ータストリームにおいて）その位置ブロックの前にある
一定の辞書ブロックにおいて定義されていなければなら
ない。

【００７６】各位置ブロックは、全ての先行辞書ブロッ
クを結合したものに対して解釈される。即ち、各位置ブ
ロックはこれらのブロックのあらゆるトークンを含むこ
とが可能である（しかし、サブセクション３．３を参照
のこと）。従って、デコーダは全ての辞書ブロックにあ
る全てのトークンを考慮し、各トークンに関連する使用
カウントに基づいてハフマンツリーを構築し、位置ブロ
ックにエンコードされたトークンの数をデコードしなく
てはならない。このハフマンツリーの構築に関する詳細
は、セクション６において述べられる。

【００７７】１ページあたり最大１つの位置ブロックを
設けることが可能である。

【００７８】２．３．残留ブロック 残留ブロックは、ページの全ての非トークン部分を含む
ビットマップをエンコードする。どのタイプのどのブロ
ックも参照せずにデコードが可能である。

【００７９】１ページあたり最大１つの残留ブロックを
設けることが可能である。

【００８０】３．辞書ブロックのエンコーディング 辞書ブロックは、（先行辞書ブロックからのトークンと
共に）後に続く位置ブロックのデコードに使用されるべ
きトークンのセットを含む。

【００８１】辞書ブロックのフォーマットは図１６に示
されている。辞書ブロック１６００はすぐに後述される
最初の値１６１０を含み、これはトークンカウント及び
辞書クリアリングコードのいずれかである。この後には
フラグ１６２０が続き、これは、この辞書ブロックのた
めにどの使用カウントエンコーディング表を使用するか
を示す。更に、辞書ブロック１６００は、例えば高さク
ラス１（１６３０）、高さクラス２（１６４０）及び
（エリプシス１６５０で示されるような）追加の高さク
ラスなどの高さクラスを含む（セクション３．１を参
照）。高さクラスの後には、ＥＮＤコード１６６０及び
辞書拡張セクション１６７０が続く。

【００８２】辞書ブロックの最初の値１６１０は、この
ブロックに記憶されているトークンの数を示す（符号の
付いていない）３２ビット値である。この値、即ちトー
クンカウントは、表１のエンコーディングを用いてそれ
自体が記憶されている。トークンの数が０であると指定
された場合、（０の新しいトークンを含む辞書ブロック
は有用ではないため）最初の値１６１０は辞書クリアリ
ングコードである。辞書クリアリングコードの詳細に関
しては、サブセクション３．３を参照のこと。

【００８３】トークンカウント１６１０の後は１ビット
フラグ１６２０であり、これは、この辞書ブロックのた
めにどの使用カウントエンコーディング表を使用するか
を示す。ビットが０であれば、トークン使用カウントの
エンコーディングに表３を使用し、ビットが１であれ
ば、表４を使用する。

【００８４】３．１．高さクラス 辞書ブロックに記憶されている全てのトークンはその高
さ及び幅によって分類され、高さクラス、即ち同一の高
さを有するトークンのグループにグループ化される。一
定の高さを有する全てのトークンは、同一の高さクラス
にある。高さクラス内では、トークンは幅の増加に従っ
て分類される。

【００８５】高さクラスのフォーマットが図１７に示さ
れている。高さクラス１７００は、最初のコード１７１
０、最初のトークンの幅１７２０、トークン１の使用カ
ウント１７３０、トークン２のデルタ幅１７４０、トー
クン２の使用カウント１７５０、（エリプシス１７６０
で示されるような）追加のトークンの追加のデルタ幅及
び使用カウント、ＥＮＤコード１７７０、圧縮トークン
画像の（バイト単位の）サイズ１７８０及び圧縮トーク
ン画像１７９０そのものを含む。

【００８６】３．１．１．トークンの高さのエンコーデ
ィング 高さクラスの最初のコード１７１０は、前の高さクラス
との高さの差である。クラスは最も小さい（短い）もの
から現れるため、これらのデルタは常に正の数である。
デルタは表２に従ってエンコードされるが、各高さクラ
スの高さは前のクラスの高さと少なくとも１の差がある
ため、エンコードの前に高さデルタを１だけ減分する。
最初の実際の高さクラスの前に高さが０である仮想の高
さクラスが存在するため、最初のクラスの高さは直接エ
ンコードされる。最後の高さクラスの後には、有効高さ
デルタコードの代わりに表２のＥＮＤコードが続く。

【００８７】３．１．２．トークンの幅のエンコーディ
ング 各高さクラス内では、トークンは幅の増加に従って分類
される。各トークンの幅は前のトークンの幅との差とし
て表され、これは常に正の数である。最初のトークンの
幅１７２０は、直接（即ち、幅が０である仮想トークン
からのデルタとして）エンコードされる。幅は、表２を
用いてエンコードされる。幅デルタｗのエンコーディン
グは、高さデルタとしてのｗ＋１のエンコーディングと
全く同一であることに注意する。各高さクラス内の最後
のトークンの後には、表２のＥＮＤコードが続く。

【００８８】３．１．３．使用カウントのエンコーディ
ング 各トークンは、関連する使用カウントを有する。これ
は、概念では、辞書ブロックと次の辞書ブロックとの間
の全ての位置ブロックにおいてトークンが生じる回数で
ある。いくつかの場合では、それは正確にこの値ではな
い可能性がある（即ち、デコーダはトークンがこれらの
位置ブロックにおいて正確な回数を生じていることを当
てにすべきではない）。これらの使用カウントは、トー
クンの数のハフマンコーディングを構築するためだけに
使用されるべきである（セクション４を参照のこと）。

【００８９】いくつかのトークンは単一使用トークンで
ある。これは、このトークンが１度だけ使用されること
をコンプレッサが保証することを意味し、従ってデコン
プレッサはこのトークンを使用した後にメモリを消去で
きる。通常、このようなトークンは大きいため、これに
よってデコンプレッサにもたらされうるメモリ節約は大
きい。単一使用トークンに関しては、使用カウントは実
際は１であるが、この辞書ブロックと次の辞書ブロック
との間で１回だけ使用されたが理論的に後で再び使用さ
れる可能性のある他のトークン（シングルトン(singlet
ons)）との区別をつけるために、０でエンコードされ
る。単一使用トークンは、使用後に完全に消去されては
ならない（例えこれらがもはや生じないとしても、ハフ
マンツリーの構築の際にこれらを考慮しなくてはならな
い）が、維持する必要のある唯一の情報は（トークンの
ハフマンコードを計算する際に結合を解くために必要で
ある）トークンのサイズ及び辞書ブロック内のトークン
の位置である。画像情報は消去することができる。

【００９０】これは無駄にみえる。なぜなら、単一使用
トークンはある位置ブロックで生じた後は再び生じない
ため、トークンの数のコードスペースの部分が無駄に感
じるからである。しかし、トークンの使用が生じる位置
ブロックをデコンプレッサがスキップした（とばした）
と想定してみる。例えば、誰かがこのフォーマットで記
憶されたファイルを対話的にブラウジングしていて、単
一使用トークンが使用されたページをスキップしてしま
ったためにこのことが生じる可能性がある。その場合、
デコンプレッサは、スキップしたページの位置ブロック
を完全にパーズすることができないため、単一使用トー
クンが使用されていたことが分からない。（場合によっ
ては多くのスキップしたページの）この余分なパージン
グは、ファイルの部分同士の間に不要な依存性を取り込
んでしまうため、対話式の使用には好ましくない。

【００９１】いくつかのアプリケーションでは、シング
ルトン及び単一使用トークンはトークン辞書に記憶され
ず、これらが生じるページの残留ブロックにエンコード
される場合がある（通常これはより優れた圧縮を生じ、
デコーダのメモリ要件を低減する）。これらが辞書ブロ
ックにある場合、使用カウントのエンコードには表３を
使用すべきであり、これらが辞書ブロックにない場合は
表４を使用すべきである。（辞書ブロックヘッダ内の）
使用カウントフラグビットは、どちらの表を使用したか
を示す。表４は、０又は１の使用カウントをエンコード
できないことに注意する。

【００９２】３．１．４．トークン画像のエンコーディ
ング 高さクラス内の全てのトークン画像は同一順で左から右
に連結しており（即ち、幅の増加に従って分類されてお
り）、最初（最短の）トークン画像が一番左に位置して
いる。次に、この単一画像はＣＣＩＴＴグループ−４に
よって圧縮される。グループ−４圧縮はＥＯＬコードを
使用せず、バイトをＭＳＢからＬＳＢに埋める。

【００９３】エンコーディングの（バイト全体の）長さ
は、表１を用いて３２ビット値として書き込まれる。次
に圧縮画像が書き込まれ、これはファイル内の次のバイ
ト境界において始まる。次の高さクラスは圧縮画像の後
に続くバイト境界において始まる。従って、高さクラス
のグループ−４圧縮画像はバイト境界において始まり、
終わる。

【００９４】いくつかの場合では、高さクラスの画像を
圧縮するグループ−４はそのサイズを増大する。このこ
とが生じると、エンコーダは画像ビットマップを圧縮さ
れないままで記憶する場合がある。これは、記憶された
ビットマップの長さが０バイトであることによって示さ
れる。どの高さクラスも空ではないため、これは圧縮の
結果としてあり得ないバイトカウントであり、従ってデ
コーダはこの状況を認識することができる。この時点で
高さクラスビットマップのサイズはデコーダにおいて既
知であり、従ってデコーダは実際に占めるバイトの数を
認識している。ビットマップの各行は、バイト境界にお
いて終わるように埋め込まれる。

【００９５】３．２．辞書ブロック拡張 最後の高さクラスの後、辞書ブロックは拡張を含むこと
ができる。目下、辞書ブロックのこのセクションは大部
分は定義されていない。このセクションは、辞書ブロッ
ク内のトークンに関する追加の情報（例えば、決定され
ている場合、トークンが表すＡＳＣＩＩ文字など）を記
憶するために使用されることが予期される。

【００９６】この実施の形態において定義されている拡
張セクションの唯一の部分は長さフィールドである。最
後の高さクラスのすぐ後には、辞書ブロック拡張セクシ
ョンのバイト単位のサイズを示す（表１のエンコーディ
ングを用いて記憶された）３２ビット値が続く。拡張セ
クションがある場合、拡張セクション自体は次のバイト
境界において始まる。拡張がない場合、０の長さが与え
られるべきである。

【００９７】３．３．辞書クリアリングコード 辞書ブロックのトークンの数フィールドの値が０である
場合、この辞書ブロックの前には辞書クリアリングコー
ドがくることを示している。このようなクリアリングコ
ードはデコンプレッサにおける記憶要件を低減すると共
に、ハフマンツリーのトークンの数、従って後に続く位
置ブロックにおいてトークンの数をエンコードするため
に必要なビットの数を減少させることによって記憶効率
を向上させる。クリアリングコードは、デコンプレッサ
に記憶されるトークン辞書をクリアすべきであることを
示している。しかし、先行辞書ブロックからのいくつか
のトークン（将来有用である可能性が最も高いとコンプ
レッサが認識したもの）を維持することができる。

【００９８】このクリアリングセクションのフォーマッ
トは図１８に示されている。辞書クリアリングセクショ
ン１８００は、維持するべきトークンの数を示す値１８
１０を含み、維持されたトークンのハフマンコードがこ
の後に続く（例えば、第１の維持トークンのコード１８
２０、第２の維持トークンのコード１８３０などで、追
加のコードはエリプシス１８４０によってここに表され
ている）。ハフマンコードの後には、この辞書ブロック
にある新しいトークンの数を示す値１８５０が続く。

【００９９】クリアリングセクションは、その存在を示
す「この辞書ブロック内のトークンは０である」という
フラグのすぐ後に生じる。維持すべきトークンの数１８
１０は、表１を用いてエンコードされる。このセクショ
ンの最後の値は、この辞書ブロック内の新しいトークン
の数であり、辞書ブロックは通常通りに処理される。フ
ァイル内のこの位置の位置ブロックに対してそうであっ
たように、ハフマンツリーを構築しなければならないこ
とに注意する。

【０１００】４．位置ブロック 位置ブロックは、（トークン位置、トークン数の）対の
シーケンスを記憶することによってバイナリ画像をエン
コードする。位置ブロックは、それが表す画像矩形のサ
イズを含まず、これはファイルフォーマットの一定の他
の層に託されている。

【０１０１】（先行辞書ブロックが辞書クリアリングコ
ードを含まない限り（サブセクション３．３を参照))、
ファイル内で位置ブロックの前にくるあらゆる辞書ブロ
ックから、あらゆる位置ブロック内で使用されるトーク
ンを引き出すことができる。これらのトークンは、ハフ
マンコードによって参照される。全ての先行辞書ブロッ
クを（論理的に）連結し、次にこれらのブロック内のト
ークンの使用カウントのハフマンツリーを構築すること
によって、ハフマンコードが計算される。このツリー
は、新しい辞書ブロックがファイル内に現れる度に再構
築しなければならないことに注意する。ハフマンツリー
を構築するためのアルゴリズムは、セクション６におい
て述べられる。

【０１０２】この論述のために、この位置ブロックによ
ってエンコードされる画像矩形の左上部角の座標が
（０、０）であると想定する。ブロック内の全ての座標
は相対的であり、全てがこの左上部位置に相対してエン
コードされるため、実際の座標はどの数でもよい。座標
は画像を下方向にゆくにつれ、また画像を横切って右方
向にゆくにつれて増加する。通常は、Ｙ座標はトークン
のインスタンスの垂直位置を表しており、Ｘ座標はその
水平位置を表している。しかし、（中国語テキストにお
いて生じるような）テキストフローの主方向が垂直であ
る文書用に意図される転置エンコーディングモードが存
在する。この場合、トークン位置のＸ座標は画像におけ
るその垂直位置を表し、Ｙ座標はその水平位置を表す。

【０１０３】トークンのためにエンコードされる位置
は、通常のエンコーディングモードでは左下部角のピク
セルの位置であり、転置エンコーディングモードでは左
上部角のピクセルの位置である。

【０１０４】位置ブロック１９００のフォーマットが図
１９に示されている。最初の値１９１０は、表１を用い
てエンコードされたこの位置ブロックに存在するトーク
ンの数である。この後には、このブロック内で使用され
るエンコーディングに関する情報が続く。ここでのフィ
ールドは以下の通りである。モードデルタＸ値 この符号が付いていない４ビット
フィールド（フィールド１９２０）は、モードデルタＸ
値を示す。全てのデルタＸ値がエンコードされる前にこ
れらのデルタＸ値からこの値を引き、デコーディングの
際に再び加えなくてはならない。ストリップの高さ この２ビットフィールド（フィー
ルド１９３０）は、画像が分割されるストリップの高さ
を示す。０、１及び３の３つの値が目下定義されてお
り、これらは１、２及び４個のピクセルのストリップ高
さをそれぞれ示している。最初のＸエンコーディング表フラグ この２ビットフ
ィールド（フィールド１９４０）は、各ストリップ内の
最初のＸ位置をエンコードするためにどのエンコーディ
ング表を使用したかを示している。表５及び表６を参照
のこと。２及び３の値が目下定義されていない。デルタＸエンコーディング表フラグ この２ビットフ
ィールド（フィールド１９５０）は、各ストリップ内の
デルタＸ値をエンコードするためにどのエンコーディン
グ表を使用したかを示している。表７、表８及び表９を
参照のこと。３の値が目下定義されていない。デルタＹエンコーディング表フラグ この２ビットフ
ィールド（フィールド１９６０）は、ストリップ同士の
間のデルタＹ値をエンコードするためにどのエンコーデ
ィング表を使用したかを示している。表１０、表１１及
び表１２を参照のこと。３の値が目下定義されていな
い。転置フラグ この１ビットフィールド（フィールド１
９６５）は、位置ブロックが通常通りにエンコードされ
ている場合は０、転置してエンコードされている場合は
１を含む。

【０１０５】この初めのエンコーディング情報に続き、
この画像に現れるトークンの位置及び識別がエンコード
される。画像は、ストリップサイズフィールドによって
エンコードされたサイズのストリップ（１、２又は４個
のピクセル）に分割される。通常の座標エンコーディン
グモードでは、ストリップは画像を水平スライスに分割
し、転置エンコーディグモードでは、ストリップは画像
を垂直スライスに分割する。明確にするため、通常のエ
ンコーディングモードのコンテクストで（行に関して）
ストリップを後述する。

【０１０６】位置ブロック１９００では、ストリップは
ストリップ１（１９７０）と、ストリップ２（１９８
０）と、（エリプシス１９８５で示される）追加のスト
リップとを含む。ストリップの後には、位置拡張セクシ
ョン１９９０が続く。

【０１０７】位置ブロックの最初のストリップの最初の
行は、画像の最上行である。ストリップは、上から下に
エンコードされる。一定のトークンの呼出しを含むスト
リップのみが実際にコード化される。空でない各ストリ
ップは、これと先行する空でないストリップとの間でス
キップされたストリップの数をエンコードする。各スト
リップ内では、トークンはＸ位置の増加に従って分類さ
れる。

【０１０８】単一ストリップのフォーマットが図２０に
示されている。ストリップ２０００は、先行ストリップ
とのＹ差分２０１０、第１トークンのＸ位置２０２０及
びＹ位置２０３０、第１トークンのハフマンコード２０
４０、第２トークンに対するデルタＸ位置２０５０、第
２トークンのＹ位置２０６０、第２トークンのハフマン
コード２０７０及び（エリプシス２０８０で示されるよ
うな）追加トークンの追加のデルタＸ、Ｙ及びハフマン
コード情報を含む。ストリップの終わりはＥＮＤコード
２０９０である。

【０１０９】ストリップの最初の値（例えば、ストリッ
プ２０００の最初の値２０１０）は、このストリップの
開始するＹ位置と先行ストリップの開始するＹ位置との
差である。ストリップはストリップ高さによって割り切
れる行から開始するように制限されているため、エンコ
ーダは実際の差をストリップ高さで割り、次にこれをエ
ンコードする。エンコーディングは、表１０〜表１２の
うちの１つを用いて行われる。使用された表は、位置ブ
ロックのヘッダの「デルタＹエンコーディング表フラ
グ」によって示される。画像の最上部の上には仮想の空
ではないストリップがあり、これは第１ストリップのＹ
位置のオフセットを計算するために使用される。

【０１１０】各ストリップ内の最初のトークンのＸ位置
は、表５又は表６を用いてエンコードされる。使用され
た表は、位置ブロックのヘッダの「最初のＸエンコーデ
ィング表フラグ」によって示される。Ｘ位置は、先行ス
トリップの最初のＸ位置からのオフセットとして（又
は、最初のストリップの場合は絶対値として）エンコー
ドされる。

【０１１１】ストリップ内の各トークンのＹ位置は、ス
トリップ高さ（１、２又は４のストリップ高さ）に依存
して０、１又は２ビットでエンコードされる。この値
は、ストリップの最上部からこのトークンの参照位置
（その左下部の角）までの行の数である。

【０１１２】ストリップの各トークンのＸ位置（最初の
もの以外）は、トークンのＸ位置をとり、これから先行
トークンのＸ位置を差引き、先行トークンの幅を足すこ
とによって（標準エンコーディングモードで）エンコー
ドされる。これにより、このトークンの左下部の角と先
行トークンの右下部の角の右にあるピクセルとの間のＸ
の差が計算される。転置エンコーディングモードでは、
ストリップの各トークンのＸ位置は、このトークンのＸ
位置と先行トークンのＸ位置との差をとり、先行トーク
ンの高さを足すことによってエンコードされる。従っ
て、転置エンコーディングモードでは、エンコードされ
るものはこのトークンの左上部の角と先行トークンの左
下部角の下のピクセルとの垂直の差である。

【０１１３】いずれの場合でも、位置ブロックヘッダに
与えられるモードデルタＸ値は、エンコードされる前に
この値から差し引かれる。これは、エンコードされる最
も一般的な値が常に０であることを確実にする。得られ
た符号つきの値のために使用されるエンコーディング表
は「デルタＸエンコーディング表フラグ」値によって与
えられ、これは表７〜表９のうちの１つである。

【０１１４】ストリップの最後のトークンは、デルタＸ
コードの代わりに（適切なデルタＸエンコーディング表
から引き出される）ＥＮＤコードによってフラグが立て
られる。ストリップは常に空ではないため、最初のＸエ
ンコーディング表のうちのいずれにおいてもＥＮＤコー
ドをエンコードすることはできない。

【０１１５】画像の終わりのコード（end-of-image cod
e)はなく、その代わりに最後のストリップはこの画像矩
形の可能な範囲の外にあるＹ位置によってフラグが立て
られる。この位置は本物のストリップを開始しないた
め、この後に続くトークン位置はない。代わりに、（図
１６の）辞書ブロック拡張１６７０に類似する位置ブロ
ック拡張セクション１９９０がこの後に続く（図１９を
参照）。目下、定義されているセクション１９９０の唯
一の部分は長さフィールドである。これは、位置ブロッ
ク拡張セクションのバイト単位のサイズを示す３２ビッ
ト値（表１のエンコーディングを使用して記憶される）
であり、これは次のバイト境界において開始する。０の
長さは、空の拡張セクションを示すために使用される。

【０１１６】５．残留ブロック各ページのビットマップ
は、このページに使用された辞書からのトークンを示す
位置ブロック及び残留ビットマップの２つの部分にエン
コードされる。残留ビットマップは、位置ブロックにお
いてエンコードされなかったページ上の全てのマークを
エンコードする。デコーディングの際、ページの位置ブ
ロックによって指定されたトークンをまず非圧縮ビット
マップに書き込み、次にＯＲ動作によってこのビットマ
ップを残留ブロックと組み合わせる。残留ブロックに記
憶されるビットマップは、元のページビットマップより
も小さくすることが可能である。残留ビットマップが空
（全てが白）である場合、（長さフィールドを含む）残
留ビットマップフィールドは全て０を含み、エンコード
された残留ビットマップはない。

【０１１７】図２１は、残留ブロック２１００のフォー
マットを示している。実際にエンコードされた残留ビッ
トマップ以外の全てのフィールドは、符号が付いていな
い１６又は３２ビット値である。これらはそれぞれ２又
は４バイトとしてエンコードされ、最も大きなバイトが
最初に現れる（ビッグエンドエンコーディング）。

【０１１８】残留ビットマップの左エッジ このフィールド（フィールド２１１０）は、元のビット
マップに対する残留ビットマップの左エッジ位置を示
す。これは、２バイト値である。残留ビットマップの最上エッジ これは２バイト値（値２１２０）であり、元のビットマ
ップに対する残留ビットマップの最上エッジの位置を示
す。残留ビットマップの幅 これは２バイト値（値２１３０）であり、残留ビットマ
ップの幅を示す。残留ビットマップの高さ これは２バイト値（値２１４０）であり、残留ビットマ
ップの高さを示す。エンコードされた残留ビットマップの長さ これは４バイト値（値２１５０）であり、エンコードさ
れた残留ビットマップのバイト単位の長さを示す。エンコードされた残留ビットマップ これは、残留ビットマップのＣＣＩＴＴグループ−４エ
ンコード表現２１６０である。グループ−４圧縮はＥＯ
Ｌコードを使用せず、バイトをＭＳＢからＬＳＢに埋め
る。サブセクション３．１．４の辞書高さクラスの場合
と同様、このビットマップを必要に応じて圧縮しないま
ま記憶できる。これは、０のバイトカウント値によって
フラグが立てられる。

【０１１９】６．ハフマンエンコーディング ハフマンツリーの構築に使用するアルゴリズムは以下の
通りである。 ・トークン使用カウントのアレイを構築する。使用カウ
ントが０であるトークンは、１の使用カウントを有する
ものとみなされる（これらは単一使用トークンであ
る）。アレイの順序は、現時点までにトークンがファイ
ル内に生じた順でなくてはならない。辞書クリアリング
コードの後、あらゆる維持されたトークンの順序は、維
持されたトークンが維持されたトークンのリストに現れ
る順序である。 ・２つの最低値エレメントの現行アレイを走査する。タ
イの場合は、アレイの開始に最も近いエレメントを常に
選択する。これは、使用カウントの１次キーと、アレイ
の位置の２次キーとを備える優先待ち行列を使用して行
うことが可能である。 ・これらの２つのエレメントの併合を表すツリーノード
を生成する。その使用カウントは、使用カウントの合計
である。 ・アレイにおいて、これらの２つのエレメントのうちの
第１エレメント（アレイの開始点に最も近いもの）をこ
の併合ノードと取り替える。アレイから第２エレメント
を取り除く（が、これを忘れない）。 ・アレイが単一ノードのみを含むまでこれを続ける。 ・このツリーを使用して、各トークンのハフマンコード
長を見つける。即ち、各トークンまでツリーをトラバー
スし、この経路の長さがそのトークンのコードのビット
数である。 ・「標準ハフマンコード」割り当てアルゴリズムを使用
して、コード自体を割り当てる。

【外１】

【０１２０】７．ブロックのカプセル化 これらのブロックの現行のカプセル化は非常に簡潔であ
るが、他のより複雑なカプセル化も可能である。ここに
記載されるものは最小のものであるが、パーズするには
非常に容易であり、過度の困難を生じずにページへのラ
ンダムアクセスを可能にする。このカプセル化のフィー
ルドは、図２２に示されている。

【０１２１】識別ヘッダ これは、０×５４ ０×０３ ０×６ｆ ０×８ｄ ０
×５０のバイトを含む５バイトフィールド（フィールド
２２１０）である。ファイルバージョン これは、使用されるカプセル化のバージョンを含む１バ
イトフィールド（フィールド２２２０）である。目下、
この値は９である。エンコードされた辞書ブロックの長さ これは、辞書ブロックのバイト単位の長さを示す４バイ
ト値（値２２３０）である。この値は、より高レベルの
カプセル化における全ての他の数値と同様、ネットワー
クバイト順（ＭＳＢが最初）に記憶される。辞書ブロック これは、セクション３に記載のフォーマットにおける辞
書ブロック（辞書ブロック２２４０）である。目下、辞
書ブロックは１つのみであり、辞書クリアリングコード
は使用されていない。これらをサポートするためにカプ
セル化を変更することは難しくない。ページの数 これは、このファイル内のページの数を示す２バイト値
（値２２５０）である。ページ これらの各々（例えば、エンコードされたページ１（２
２６０）、エンコードされたページ２（２２７０）、エ
リプシスで示されるような追加のエンコードされたペー
ジ２２８０）は、図２３に示されるようにエンコードさ
れる。ページ２３００のフィールドは、以下の通りであ
る。ページファイル名 これは、このページが由来するフ
ァイルの名前又は他の識別情報を示すＮＵＬ終端ストリ
ングである。ページ幅 これは、このページのビットマップの幅を
示す２バイト値（値２３２０）である。ページ高さ これは、このページのビットマップの高
さを示す２バイト値（値２３３０）である。エンコードされた位置ブロックの長さ これは、ペー
ジの位置ブロックのバイト単位の長さを示す４バイト値
（値２３４０）である。位置ブロック これは、セクション４に記載のフォー
マットにおける位置ブロック２３５０である。残留ブロック これは、セクション５に記載のフォー
マットにおける残留ブロック２３６０である。残留ブロ
ックの長さは最初の数バイトを走査することによって容
易に測定可能なため、残留ブロックの長さをエンコード
する必要はない。

【０１２２】７．１．ＴＩＦＦ内への埋め込み ＴＩＦＦは、ＣＣＩＴＴグループ−４圧縮ビットマップ
を記憶するために目下一般的に使用されている。このサ
ブセクションでは、辞書ブロック、位置ブロック及び残
留ブロックをＴＩＦＦファイル内に埋め込んでＴＩＦＦ
がトークン圧縮ビットマップを表すことを可能にする態
様を簡潔に説明する。

【０１２３】デコンプレッサは、圧縮解除を正確に行う
ために位置ブロックの前にある全ての辞書ブロックを参
照する必要があるため、これらの辞書ブロックは出来る
だけ見つけ易いものでなくてはならない。好ましくは、
１ページあたり最大１ブロックがそのページの最上レベ
ルディレクトリに（タグとして）記憶される。デコンプ
レッサは特定のページにたどり着くためにファイルを通
過し、従ってデコンプレッサは必要である全ての辞書ブ
ロックを通過しなければならない。デコンプレッサは、
実際にランしてトークン圧縮バイナリ画像に入るまでは
これらをパーズする必要はないが、これらの位置（及び
順序）を記憶する必要がある。

【０１２４】一方、位置ブロックは、バイナリ画像のた
めに利用可能な情報を出来るだけ多く再使用するべきで
ある。位置ブロックは通常のバイナリ画像として記憶さ
れるべきであるが、その場合は可変圧縮方法を使用する
（ＴＩＦＦ仕様は、使用される圧縮方法による圧縮画像
のタグ付けを可能にする）。

【０１２５】残留ブロックもまた、対応する位置ブロッ
クと同一のページにバイナリ画像として記憶されうる。
同一ページに複数の画像を記憶することは、ＴＩＦＦ仕
様では可能である（しかし、これらを組み合わせる態様
は適切に指定されていない）。

【０１２６】８．更なる検討 ここに説明するものは、現行のＤｉｇｉＰａｐｅｒフォ
ーマット及びこのフォーマットの可能な変更物に関連す
る追加の検討である。

【０１２７】（ａ）現行フォーマットでは、位置ブロッ
クはページ全体を表す。いくつかのアプリケーション
（特に、ファックス出力デバイス）では、ページをスラ
イスに分割することができる。これは、最初のページス
ライスがデコードされるとページのプリントを出来るだ
け速く開始することができるという意味である。各ペー
ジスライスは、位置ブロック及び残留ブロックを含む。

【０１２８】トップレベルのフォーマットは、辞書ブロ
ックがページ内で（ページスライス同士の間で）生じる
ということを許容するためにわずかに変更を施さなくて
はならない。これは、単一ページへの容易なアクセスを
可能にする目的と相反する。後に続くページをデコード
可能にするには、デコーダはページを読み通してこれら
の辞書ブロックをピックアップしなければならない。し
かし、各ページスライスの位置ブロックを完全にデコー
ドする必要はない。

【０１２９】（ｂ）コーダが各ページのトークンを分類
する態様、コーダが辞書ブロック及び辞書クリアリング
コードを配置する場所、エンコーディング表の選択、ペ
ージをページストリップに分割する態様などに依存し
て、あらゆる所与の文書は多数の表現を有することがで
きる。エンコーダ及びデコーダのメモリ要件は、適切に
生成されうる又はデコードされうる表現を制限する可能
性がある。（ファックス出力デバイスへの伝送のよう
に）エンコーダ及びデコーダが直接交信する場合、これ
らはメモリ限度を決めることができ、エンコーダは、
（ページ画像バッファメモリ要件を低減するために）各
ページを分割して十分小さいストリップにすると共に
（トークン辞書メモリ要件を低減するために）辞書クリ
アリングコードを挿入することによってデコーダがこの
限度を越えないことを確実にすることができる。このよ
うな制約は、圧縮を劣化する傾向がある。

【０１３０】文書がファイルに圧縮されると、このよう
な取り決めは不可能になるため、このような記憶ファイ
ルから解読するデコーダは（潜在的に）多量のメモリを
使用する準備をしなくてはならない。しかし、このよう
な状況において、デコーダは一定の強力な汎用コンピュ
ータにおいてランする傾向があるため、この要件は面倒
ではない。一方、ファックスマシンに関しては、コスト
要件によってはメモリ使用が厳しく制約される状況にな
る可能性があるが、幸いにもこれらは取り決めが可能な
状況である。

【０１３１】（ｃ）エンコードされたトークン高さクラ
ス及び残留ビットマップは、ＣＣＩＴＴグループ−４を
使用して圧縮されるか、あるいはグループ−４が実際に
これらのサイズを増大する場合では圧縮しないまま記憶
される。グループ−４圧縮及び圧縮解除を行うシステム
（ハードウェア及びソフトウェアの双方）は一般的であ
り、非常に簡潔であるため、これを選択した。これらの
ビットマップは、あらゆる好適なロスレスバイナリコン
プレッサ、例えばＪＢＩＧを用いて記憶することが可能
である。

【０１３２】ＤｉｇｉＰａｐｅｒファイルフォーマット
を十分に説明した。次に、本発明の更なる用途を述べ
る。一般に、本発明は、素早く高品質の文書レンダリン
グを必要とするあらゆる状況において用途を見出すこと
ができる。

【０１３３】本発明は、ワールドワイドウェブ文書など
の対話式文書に特に好適である。（特にＨＴＭＬと比較
して）トークン化表現の表現性のため、ＤｉｇｉＰａｐ
ｅｒフォーマットでエンコードされるウェブ文書をプリ
ント媒体に匹敵する忠実性でレンダリングすることがで
きる。

【０１３４】図２４のフローチャートは、ウェブサーバ
と、Javaプログラミング言語をサポートするウェブクラ
イアント（ブラウザ）プログラムをランするクライアン
トコンピュータとの間の簡潔な対話を示している。クラ
イアントコンピュータは、ＤｉｇｉＰａｐｅｒフォーマ
ットでエンコードされる新しいウェブページを示すハイ
パーテキストリンクをクライアントコンピュータのユー
ザが選択したことを示すコマンドを受け取る（ステップ
ＡＡ）。コンピュータは選択されたリンクをたどること
でこれに応答し（ステップＢＢ）、選択されたページを
ダウンロードし始める。最初にダウンロードするもの
は、Java言語プログラム、即ちアプレット(applet)であ
り（ステップＣＣ）、クライアントコンピュータはこれ
を自動的に実行し始める。Javaアプレットを実施するこ
とにより、クライアントコンピュータは、ウェブページ
の可読内容を構成する表示可能テキスト及びグラフィッ
クスのＤｉｇｉＰａｐｅｒトークン化表現を含むデータ
ファイルをダウンロードする（ステップＤＤ）。アプレ
ットはまたＤｉｇｉＰａｐｅｒデコンプレッサソフトウ
ェアを含み、これによってトークン化表現がダウンロー
ドされるとクライアントコンピュータはこれをレンダリ
ングでき（ステップＥＥ）、得られたウェブページを表
示できる（ステップＦＦ）。ＤｉｇｉＰａｐｅｒ表現
は、ダウンロードされたウェブページに埋め込まれたハ
イパーテキストリンクをサポートする拡張を含むことが
でき、アプレットは圧縮解除ページのユーザが選択した
新しいリンクを認識できる（引き続きステップＦＦ）。
ユーザが次にすることに依存して（ステップＧＧ）、ア
プレットはダウンロードされたＤｉｇｉＰａｐｅｒペー
ジのユーザが選択したリンクに応答して新しいページに
リンクする（ステップＢＢ）か、又は制御をブラウザに
戻すことができる（ステップＨＨ）。新しいウェブペー
ジが選択された場合、アプレットは制御されたままであ
る。特に、新しく選択されたページがＤｉｇｉＰａｐｅ
ｒページである場合、アプレットは再びダウンロードさ
れる必要はない（ステップＢＢ）。ユーザが、例えば目
下表示されているページの内容にさほど関連していない
ブラウザ機能を選択した場合、アプレットを終わらせる
か又は中断し、制御をメインブラウザプログラムに戻す
ことができる（ステップＨＨ）。

【０１３５】ＤｉｇｉＰａｐｅｒトークン化文書表現に
デコンプレッサアプレットがバンドルされている場合、
得られるパッケージは本質的にはセルフレンダリングフ
ァイルフォーマットであることが、この例によって示さ
れている。

【０１３６】ブラウザが産業標準のJava言語をサポート
する限り、ブラウザはＤｉｇｉＰａｐｅｒ用に指定され
てイネーブルされる必要はない。

【０１３７】本発明の多くの他の実施の形態が可能であ
る。特に、ＤｉｇｉＰａｐｅｒファイルフォーマットは
トークン化表現に好適なフォーマットであるが、他の構
造化文書表現を使用することができる。１つの可能性
は、ＰＤＬの非常に減少されたサブセットを使用するこ
とである。このサブセットは、種々の記号のビットマッ
プを示したりレンダリング画像内のどこに記号が配置さ
れるかを示すのに十分ないくつかのオペレータと、所望
の位置において記号を引き出すための基本的なコマンド
を含むだけでよい。例えば、ＰｏｓｔＳｃｒｉｐｔで
は、サブセットはｉｍａｇｅｍａｓｋ、ｍｏｖｅｔｏ、
ｒｍｏｖｅｔｏ、ｄｅｆｉｎｅｆｏｎｔ及びｓｈｏｗと
いうオペレータが可能であり、これらのオペレータは P
ostScript Manualの４３５、４５６、４８３、３９８及
び５２０ページにそれぞれ定義されている。特に、ｄｅ
ｆｉｎｅｆｏｎｔオペレータはビットマップフォントを
許容でき、従ってトークンビットマップを定義するため
に使用可能である。

【表１】

【表２】

【表３】

【表４】

【表５】

【表６】

【表７】

【表８】

【表９】

【表１０】

【表１１】

【表１２】

【図面の簡単な説明】

【図１】従来技術の構造化文書表現における表現性対レ
ンダリング速度のトレードオフの略図である。

【図２】従来技術の異なるフォントにおける文字「Ｅ」
の例である。

【図３】従来技術において入力ページ記述言語ファイル
からの文書をプリントするプリンタの略図である。

【図４】本発明による完全な圧縮−圧縮解除サイクルに
おいて構造化文書表現に適用される変換の全体的なシー
ケンスを示している。

【図５】入力ページ記述言語ファイルをトークン化表現
に変換するコンプレッサの略図であり、図４の圧縮段階
において構造化文書表現に適用される変換をより詳細に
示している。

【図６】圧縮段階及び圧縮解除段階が互いから分離可能
である態様を示す一連の図である。

【図７】トークン化表現からの文書をプリントするプリ
ンタの略図である。

【図８】トークン化表現からの文書を表示するディスプ
レイビューアの略図である。

【図９】文書の構造化表現を文書のトークン化表現に変
換するために好適なシステムのハードウェア構成要素及
びソフトウェア構成要素を示している。

【図１０】文書のトークン化表現をプリント可能又は表
示可能ページ画像などのレンダリング画像に変換するた
めに好適な構成要素を含むシステムを示している。

【図１１】例示的で非常に簡略化されたトークン化ファ
イルフォーマットにおけるトークン及び位置を示してい
る。

【図１２】例示的で簡略化されていると共にインターリ
ーブされていないトークン化ファイルフォーマットにお
いて表される文書の辞書ブロック及びページ（位置ブロ
ック及び残留ブロックを含む）のカプセル化の図であ
る。

【図１３】例示的で簡略化されていると共にインターリ
ーブされたトークン化ファイルフォーマットにおいて表
される文書の辞書ブロック及びページ（位置ブロック及
び残留ブロックを含む）のカプセル化の図である。

【図１４】文書圧縮ステップのフローチャートである。

【図１５】文書圧縮解除ステップのフローチャートであ
る。

【図１６】好適な実施の形態のトークン化ファイルフォ
ーマットにおいて、辞書拡張を含む辞書ブロックのフォ
ーマットを示している。

【図１７】好適な実施の形態のトークン化ファイルフォ
ーマットにおいて、高さクラスのフォーマットを示して
いる。

【図１８】好適な実施の形態のトークン化ファイルフォ
ーマットにおいて、辞書クリアリングセクションのフォ
ーマットを示している。

【図１９】好適な実施の形態のトークン化ファイルフォ
ーマットにおいて、位置拡張を含む位置ブロックのフォ
ーマットを示している。

【図２０】好適な実施の形態のトークン化ファイルフォ
ーマットにおいて、ストリップのフォーマットを示して
いる。

【図２１】好適な実施の形態のトークン化ファイルフォ
ーマットにおいて、残留ブロックのフォーマットを示し
ている。

【図２２】好適な実施の形態のトークン化ファイルフォ
ーマットに表される文書の辞書ブロック及びページのカ
プセル化を示している。

【図２３】好適な実施の形態のトークン化ファイルフォ
ーマットに表される文書のページの位置ブロック、残留
ブロック及び他のエレメントを示している。

【図２４】トークン化ファイルとして圧縮されたウェブ
ページを組み込むワールドワイドウェブビューアの動作
を示すフローチャートである。

【符号の説明】

４０ 文書の入力ＰＤＬ表現 ４１ トークン化コンパイラ ４２ トークン化表現 ４３ レンダリングエンジン ４４ 文書の出力画像表現 ４７ コンプレッサ １００ 汎用コンピュータ １０５ ＣＰＵ １６５ トークン化コンパイラソフトウェア １１１１ トークン １１１２ 位置

Claims (3)

【特許請求の範囲】
1. 【請求項１】 コンピュータベースの文書処理方法であ
   って、 文書の第１構造化表現を含むデジタル情報の第１セット
   をプロセッサに提供するステップを含み、前記第１構造
   化表現は解像度に依存しない表現であり、複数の画像の
   集まりが前記第１構造化表現から取得可能であり、この
   ような各取得可能な画像の集まりは少なくとも１つの画
   像を含み、前記各集まりにおける各画像は前記文書の少
   なくとも一部分の画像であり、前記各集まりにおける各
   画像は固有解像度を有し、 プロセッサを用いて、前記文書の第２構造化表現を含む
   デジタル情報の第２セットを前記デジタル情報の第１セ
   ットから生成するステップを含み、前記第２構造化表現
   は特定の画像の集まりのロスレス表現であり、前記特定
   の画像の集まりは前記第１構造化表現から取得可能な前
   記複数の画像の集まりのうちの１つであり、前記第２構
   造化表現は複数のトークン及び複数の位置を含み、前記
   デジタル情報の第２セットの生成は前記第１構造化表現
   から前記複数のトークンを抽出するステップを含み、各
   トークンは前記特定の画像の集まりのサブ画像を表すピ
   クセルデータのセットを含み、 前記第１構造化表現から前記複数の位置を決定するステ
   ップを含み、各位置は前記特定の画像の集まりにおける
   トークンサブ画像の位置であり、前記トークンサブ画像
   は前記トークンのうちの１つからのサブ画像のうちの１
   つであり、少なくとも１つのトークンサブ画像は複数の
   ピクセルを有すると共に前記特定の画像の集まりにおい
   て１つよりも多い位置で生じ、 このようにして生成された前記デジタル情報の第２セッ
   トを後の使用のために利用可能にするステップを含む、 コンピュータベースの文書処理方法。
2. 【請求項２】 前記提供ステップが前記文書のフォント
   ベースの第１構造化表現をプロセッサに提供することを
   含み、前記生成ステップが前記文書のフォントレス第２
   構造化表現を生成することを含む、請求項１に記載の方
   法。
3. 【請求項３】 コンピュータベースの文書処理方法であ
   って、 請求項１に記載のように生成し、利用可能にした前記デ
   ジタル情報の第２セットをプロセッサに提供するステッ
   プを含み、前記デジタル情報の第２セットがこのように
   提供される前記プロセッサを「デコーディング」プロセ
   ッサと呼び、 前記デコーディングプロセッサを用いて、少なくとも１
   つの画像を含む画像の集まりを有するデジタル情報の第
   ３セットを前記デジタル情報の第２セットから生成する
   ステップを含み、前記デジタル情報の第３セットによっ
   て含まれる画像の集まりにおける各画像は文書の少なく
   とも一部分の画像であり、前記画像の集まりにおける各
   画像には、前記トークンサブ画像からなると共に少なく
   とも１つの前記位置においてトークンサブ画像を含む前
   記デジタル情報の第３セットが含まれており、 このようにして生成された前記デジタル情報の第３セッ
   トを後の使用のために利用可能にするステップを含む、 コンピュータベースの文書処理方法。