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

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の４３５、４５６、４８３、３９８及
び５２０ページにそれぞれ定義されている。特に、ｄｅ
ｆｉｎｅｆｏｎｔオペレータはビットマップフォントを
許容でき、従ってトークンビットマップを定義するため
に使用可能である。

【０１３９】ブラウズ−ナウ−プリント−レイター（Br
owse-Now-Print-Later) 特定のウェブ文書へのユーザアクセスを制御することが
望ましい場合がある。おそらく特権のためにお金を払っ
ている著作権を有する文書を含むウェブページをユーザ
がブラウズしており、サーバからこの文書をダウンロー
ドしようとすることを想定する。この後、ダウンロード
した文書のあらゆる数のデジタルコピーをユーザが作成
したり分配したりすることを止めるものは何もなく、従
って著作権を有する作品の価値を害する可能性がある。
従って、何らかの手段を用いて、ユーザがウェブの文書
をブラウズすることを可能にはするが、ユーザが文書の
高品質デジタルコピーを得ることを防げることが望まし
い。

【０１４０】同時に、ユーザによる文書の高品質プリン
トコピーの要求も満たされなくてはならない。

【０１４１】後述される本発明の実施の形態によると、
ＰＤＬ表現などのソース文書の解像度に依存しない構造
化表現はロスレスでそれぞれ異なる解像度の２つ（又は
それより多く）のＤｉｇｉＰａｐｅｒトークン化表現に
変換される。例えば、ＰＤＬオリジナルは、低解像度Ｄ
ｉｇｉＰａｐｅｒ表現及び高解像度ＤｉｇｉＰａｐｅｒ
表現としてエンコードされる。低解像度表現は、オンラ
インウェブブラウジング及びスクリーン表示に好適であ
るが、高品質プリントには不十分な解像度である。文書
の高品質プリントコピーの作成には、高解像度表現のみ
が好適である。

【０１４２】低解像度表現はウェブサーバに記入され、
従ってあらゆる全てのウェブユーザによる通常無料のオ
ンラインブラウジングが可能になる。文書に興味があ
り、これを読むために高品質のプリントコピーを望むユ
ーザは、ウェブサーバにプリントアウトのリクエストを
送る。これに応答して、サーバは委託プリント設備にコ
ンタクトをし、保護された通信チャネルを介して文書の
高解像度ＤｉｇｉＰａｐｅｒ表現をこの設備に提供す
る。委託プリント設備は、高解像度ＤｉｇｉＰａｐｅｒ
表現から文書のハードコピーをプリントし、これをリク
エストしたユーザに対して利用可能になる。ユーザはこ
れに応じて料金を請求され、適切な著作権使用料が著作
権所有者に流れる。重要なことに、ユーザは文書の高解
像度ＤｉｇｉＰａｐｅｒ表現に全くアクセスせず、従っ
て文書の高品質デジタルコピーの作成が有効に防止され
る。

【０１４３】このスタイルのウェブの使用を、ブラウズ
−ナウ−プリント−レイター（今ブラウズし、後でプリ
ントする）と呼ぶことができる。これは、図２５の概念
的な例において示される。ウェブユーザは、ＰＣ又は他
のローカルコンピュータにおいてウェブブラウザ（クラ
イアント）をランする。ユーザは、例えば表示されたウ
ィンドウ２５１０を眺め、ユーザはこれを介してブラウ
ザと対話をする。文書の低解像度表現２５２０をウィン
ドウ２５１０において眺めることができる。これは、低
解像度テキスト表現２５２１と、低解像度ラインアート
表現２５２２とを含む。ユーザは自由に低解像度表現２
５２０をダウンロードし、これを複写することさえ可能
である。低解像度表現２５２０は、文書が興味をもつも
のであるかどうかをユーザに示すには十分な画像である
が、ユーザが低解像度テキスト２５２１を楽に読んだり
又はラインアート２５２２の詳細を容易に認識したりす
るには十分な画像ではない。

【０１４４】ウィンドウ２５１０にはハイパーテキスト
リンク２５２３もあり、例えばマウス又は他のポインテ
ィングデバイスを用いてユーザがこれを選択し、文書の
高解像度ハードコピーを注文することができる。矢印２
５２５で示されるような適切な支払い又はクレジットと
共にリクエストすると、ユーザの注文は文書の高解像度
表現と一緒にプリントショップ又は他の委託プリント設
備に伝送される。高解像度プリントコピー２５３０は、
高解像度表現から作成される。この後、プリントショッ
プは高解像度プリントコピーをユーザに郵便で送るか又
は配達することができ、あるいはユーザがプリントショ
ップを訪れてコピー２５３０をピックアップすることが
できる。ユーザは、（それぞれ高解像度テキスト表現２
５３１及び高解像度ラインアート表現２５３２として）
文書のテキスト及びラインアートを明確に示す高解像度
コピー２５３０を楽に読むことができる。一方、プリン
トショップ又は他の委託プリント設備は料金を集めて処
理し、適用するあらゆる著作権使用料を著作権所有者に
送る。

【０１４５】図２６は、本発明のブラウズ−ナウ−プリ
ント−レイターの実施の形態における文書エンコーディ
ング段階を示している。ＰＤＬファイルなどの解像度に
依存しないソース文書表現２６０１が、１つ又はそれよ
り多くの保護された通信チャネル２６０９を介してエン
コーダ２６１０、２６３０に提供され、これはそれぞれ
低解像度及び高解像度のＤｉｇｉＰａｐｅｒトークン化
フォーマットに変換される。エンコーダ２６１０、２６
３０は、例えば、異なるＤｉｇｉＰａｐｅｒエンコーデ
ィングプログラムをランする２つの異なるコンピュータ
でもよいし、又は入力パラメータを許容してエンコーデ
ィング解像度を制御するプログラムをランする単一のコ
ンピュータでもよい。低解像度（例えば、７２ｄｐｉ）
は、スクリーンディスプレイを生成するには許容可能で
あるが、高品質のプリントには許容不可能である。高解
像度（例えば、６００ｄｐｉ）は、高品質プリントに好
適である。保護通信チャネル２６０９は、例えば専用ハ
ードワイヤリンク、電話リンク又は適切に記号化された
ネットワーク経路が可能である。いずれにせよ、保護チ
ャネル２６０９をわたって送られる情報は、非認可の窃
信又はコピーを容易に受けない。

【０１４６】この実施の形態において、低解像度エンコ
ーダ２６１０によって形成される低解像度ＤｉｇｉＰａ
ｐｅｒ表現は保護されていない通信チャネル２６１１を
介してディスプレイサーバ又はサービス２６２０に提供
される一方、高解像度エンコーダ２６３０によって形成
される高解像度表現は保護チャネル２６３１を介してプ
リントサーバ又はサービス２６４０に提供される。保護
されていないチャネル２６１１は、例えば記号化されて
いないインターネット経路であってもよい。保護されて
いないチャネル２６１１をわたって送られる低解像度表
現は、非認可の窃信及びコピーを受ける。チャネル２６
０９のように、保護チャネル２６３１は、例えば専用ハ
ードワイヤリンク、電話リンク、好適に記号化されたネ
ットワーク経路又は非認可の窃信を容易に受けないあら
ゆる通信チャネルとすることが可能である。ディスプレ
イサーバ又はサービス２６２０及びプリントサーバ又は
サービス２６４０は、例えば２つの物理的に別個である
コンピュータ（サーバ）であってもよいし、単一コンピ
ュータ上で実施する２つの処理でもよい。プリントサー
バ又はサービス２６４０は高解像度ＤｉｇｉＰａｐｅｒ
表現の保管を委託されているため、それ自体が信頼でき
るものでなければならないことに注意する。

【０１４７】図２７は、本発明のブラウズ−ナウ−プリ
ント−レイターの実施の形態におけるデコーディングの
簡潔な例を示している。図２７の実施の形態では、文書
の低解像度及び高解像度ＤｉｇｉＰａｐｅｒ表現の双方
が単一サーバ２７０５に記憶されている。サーバ２７０
５はユーザ２７９０から遠隔に位置しており、著作権所
有者によって委託されている。サーバ２７０５は、ディ
スプレイサービス２７０６及びプリントサービス２７０
７を提供する。

【０１４８】ディスプレイサービス２７０６は、保護さ
れていないチャネル２７１１及びネットワーク２７１０
（例えば、インターネット）を介してウェブブラウザソ
フトウェアプログラムをランするクライアントコンピュ
ータ２７２０に低解像度表現を提供する。クライアント
２７２０は委託されていない。即ち、クライアント２７
２０を使用する人物（ここではユーザ２７９０）は、文
書の非認可コピーの作成を控えることを当てにされてい
ない。同様に、保護されていないチャネル２７１１は、
非認可の人物による窃信を受けやすい。クライアント２
７２０は、低解像度ディスプレイ出力２７２５を生成す
るウェブブラウザソフトウェアをランし、ユーザ２７９
０はこの出力をオンライン２７２９で眺めることができ
る。

【０１４９】ディスプレイサービス２７０６は、クライ
アント２７２０からのハードコピーリクエストを受け入
れてこれを安全にプリントサービス２７０７に通信する
こともできる。この実施の形態では、このようなリクエ
ストを受け取ると、プリントサービス２７０７は保護さ
れた専用通信チャネル２７３１を介して高解像度Ｄｉｇ
ｉＰａｐｅｒ表現をプリンタ２７３０に提供する。プリ
ンタ２７３０は委託されている。即ち、プリンタ２７３
０を作動する人物又は設備は非認可コピーを作成しない
ことを当てにされており、更にプリントコピーのユーザ
への提供に関連する金銭的な計算を処理することを当て
にされている。プリンタ２７３０は、高品質の高解像度
プリンタ出力２７３５を生成すると共に２７３３で示さ
れるようなインボイスなどを作成する。プリント出力２
７３５がユーザ２７９０に物理的に配達されると（２７
３９）、ユーザ２７９０はこれを読むことができる。配
達２７３９は、例えば郵便、空輸又は陸運などによって
行うことができる。あるいは、ユーザ２７９０はプリン
タ２７３０を保有する設備からプリント出力２７３５を
ピックアップすることができる。通常は、ユーザの便宜
を向上させると同時に文書の安全性を確実にするため
に、プリンタ２７３０は、ユーザ２７９０の比較的近く
に位置するがユーザ２７９０の家屋内ではなく、又は少
なくとも適切な認可なしではユーザ２７９０がアクセス
することができないプリントサービスビューロー、コピ
ーショップ又は他の設備に配置される。

【０１５０】図２８は、本発明のブラウズ−ナウ−プリ
ント−レイターの実施の形態におけるデコーディングの
より複雑な例を示している。図２８の実施の形態では、
文書の低解像度ＤｉｇｉＰａｐｅｒ表現はディスプレイ
サーバ２８０６に記憶されており、１つ又はそれより多
くの高解像度ＤｉｇｉＰａｐｅｒ表現はプリントサーバ
２８０７に記憶されている。ディスプレイサーバ２８０
６は、保護されていないチャネル２８１１を介してネッ
トワーク２８１０をわたって委託されていないクライア
ント２８２０ａ、２８２０ｂ及び２８２０ｃと通信し、
またディスプレイサーバ２８０６は保護されたチャネル
２８３１を介してプリントサーバ２８０７と通信する。
保護チャネル２８３１は、ディスプレイサーバ２８０６
とプリントサーバ２８０７との間を直接ランするか又は
場合によってはネットワーク２８１０を通ることが可能
である。ディスプレイサーバ２８０６は文書の低解像度
ＤｉｇｉＰａｐｅｒ表現をクライアント２８２０ａ、２
８２０ｂ及び２８２０ｃに伝送し、クライアントはこれ
を低解像度ディスプレイ出力２８２５ａ、２８２５ｂ及
び２８２５ｃとして各々のユーザ（図示せず）に表示す
ることができる。

【０１５１】ディスプレイサーバ２８０６はまた、クラ
イアント２８２０ａ、２８２０ｂ及び２８２０ｃからの
ハードコピー出力のリクエストを受け取ることができ
る。ディスプレイサーバ２８０６は、保護チャネル２８
３１を介してこれらのリクエストをプリントサーバ２８
０７に転送する。好ましくは、プリントサーバ２８０７
へのリクエストはディスプレイサーバ２８０６から保護
されていないチャネルではなく保護チャネルをわたって
通信され、妨害者が適切な認可なしでプリントコピーを
リクエストすることを防ぐ。

【０１５２】ディスプレイサーバ２８０６からハードコ
ピー出力リクエストを受け取ると、プリントサーバ２８
０７はインボイスを処理できるように計算サーバ２８３
３に知らせ、保護チャネル２８３１を介してネットワー
ク２８１０をわたって委託プリンタ２８３０に文書の高
解像度ＤｉｇｉＰａｐｅｒ表現を伝送し、プリンタ２８
３０はこの表現から高解像度プリント出力２８３９を生
成する。

【０１５３】図２８はまた、ディスプレイサーバ２８０
６からクライアント２８２０ａ、２８２０ｂ及び２８２
０ｃへの通信を窃信する非認可の窃信者２８９０を示し
ている。チャネル２８１１が保護されていないため、こ
のような窃信は可能である。しかし、窃信者２８９０は
文書の低解像度表現しか窃信することができない。保護
チャネル２８３１を介してプリントサーバ２８０７から
又はプリントサーバ２８０７に送られる高解像度表現は
アクセスできない。

【０１５４】図２７及び図２８の実施の形態に共通のい
くつかの点は注目に値する。各実施の形態において、双
方のサーバ又はサービスは著作権所有者又は他の正当な
文書保有者によって委託されており、これらの間のリン
クは保護されている。同様に、出力プリンタも委託され
ている。サーバ及びプリンタのいずれも、非認可のユー
ザにアクセスできない。クライアント及びユーザは委託
されておらず信用に値しないものとみなされ、従ってこ
れらとの通信は保護されない。

【表１】

【表２】

【表３】

【表４】

【表５】

【表６】

【表７】

【表８】

【表９】

【表１０】

【表１１】

【表１２】

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図２５】ウェブユーザの側から示されるようなブラウ
ズ−ナウ−プリント−レイターウェブアクセスの概念的
な例である。

【図２６】ブラウズ−ナウ−プリント−レイターアプリ
ケーションのための本発明のエンコーディング段階を示
している。

【図２７】ブラウズ−ナウ−プリント−レイターアプリ
ケーションのための本発明のデコーディング段階の実施
の形態の簡潔な例を示している。

【図２８】ブラウズ−ナウ−プリント−レイターアプリ
ケーションのための本発明の実施の形態のより複雑な例
を示している。

【符号の説明】

４０ 文書の入力ＰＤＬ表現 ４１ トークン化コンパイラ ４２ トークン化表現 ４３ レンダリングエンジン ４４ 文書の出力画像表現 ４７ コンプレッサ １００ 汎用コンピュータ １０５ ＣＰＵ １６５ トークン化コンパイラソフトウェア １１１１ トークン １１１２ 位置 ２７０５ 遠隔サーバ ２７１０ ネットワーク ２７２０ クライアント ２７２５ 低解像度ディスプレイ出力 ２７３０ 専用プリンタ ２７３５ 高解像度ディスプレイ出力 ２７９０ ユーザ

フロントページの続き (72)発明者 ジョン スィーリー ブラウン アメリカ合衆国 94301 カリフォルニ ア州 パロ アルト ウェイバーリー ストリート 1110 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 3/12

Claims (3)

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