JPH0778799B2 - テキストコーディング方法 - Google Patents

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明はデジタルコンピュータにおいて高速のテキスト
処理を可能にするようにドキュメント内のテキストをコ
ーディングする方法に関する。詳細には、テキストの各
ワードは、そのワードの特性を記述する情報パケットと
して参照される数（本書ではトークンとして参照され
る）として表わされる。これにより、動作においては、
各文字ではなくて各数すなわちトークンを処理してテキ
スト処理機能を実行する。このトークン表示は辞書がコ
ンパクトになるという特性の他に、WYSIWYGエディタ中
の全ての機能の実行を改善する。殊に、テキストが改行
を決定しテキストを表示する速度を、テキストを一度に
一文字でなく、一度に一トークン処理することによって
著しく大きくしている。

〔従来の技術〕

代表的なワード・プロセッシング方式において、各パラ
グラフには１つもしくはそれ以上の文字例があるから、
表示したり印字したりする前に、適当な長さの行に分割
する必要がある。例えば、典型的な改行アルゴリズムは
主内部ループを有していて、同ループは先の文字群の幅
の和に現在の文字の幅を加算してその新たな合計を所望
の行幅と比較する。このプログラムは、当該行内の文字
数が行中におさまる文字数を超えるまでこのループを実
行することになる。文字数が行中におさまる文字数を超
える時点で、そのプログラムはその行を最後のワードで
終えるか、それとも現在のワードにハイフン分割してて
そのハイフン後の部分を次行の初めにおくかする。

この処理に関連する２つの問題がそのプログラムの実行
を遅くする原因となっている。第１に、上記ループは行
内の文字の全てについて実行せねばならない。第２に、
ハイフン分割が可能な場合は、マージンを超過した文字
の前後関係を推論せねばならない。即ち、その文字がス
ペースであるか句読点であるかワードの一部であるのか
を判断する必要がある。一般的に、ページ付けのような
全文字の処理やドキュメント内のスクロールを必要とす
る操作は全て非常に遅い。更に、ハイフン分割、スペル
チェック、サーチ、及び置換の如き、ドキュメントを一
連のワード群として解釈することに依存する操作も非常
に遅い。

米国特許第4,181,972号（キャセイ）は、ワードを自動
的にハイフン分割する手段と方法に関するもので、文字
長さではなく入力ワードの長さに応答する手段を開示し
ている。このキャセイ特許は、将来の使用のために、得
られたワードの長さを記憶しないし、ハイフン分割が必
要とされる場合、キャセイ特許の方法ではテキスト全体
を一字毎に走査している。また、同方法によれば、全体
のワードの長さに基づいて区切り点を計算することをせ
ず、その代わりとして、子音／母音の組合せ間での有効
な区切り点のテーブル（メモリに記憶されている）を使
用することを教示している。

米国特許第4,092,729号（ローゼンバウム外）と第4,02
8,677号（ローゼンバウム）は、同様に区切り点のテー
ブルを用いたハイフン分割法を開示する。ローゼンバウ
ム外の特許ではワード長さによってハイフン分割を実行
している。この方法は本書に開示する発明とは異なって
いる。即ち、ローゼンバウム外の特許では、ハイフン分
割が必要とされる時にワードが文字から組立られ、その
後で区切り点を有する語を含む辞書と比較される。本書
に開示した発明では、ドキュメントがコーディングされ
る時にワードが組立てられており、行の区切りの計算中
に辞書を参照する方法を使用することはない。

現在、ドキュメント処理のためにテキストを表わすため
の優れた方法が必要とされている。作文機能の計算を少
なくする自然な方法は一度に一文字ではなく一度に一ワ
ードとして計算できるデータ構造を作りだすことであろ
う。この場合のテキストの内部表現は、次の対で定義さ
れるトークンである。

〈型、データ〉 ここで、型はトークンの各クラスに対する一義的な識別
子であり、データは特定型のトークンに関係するデータ
である。トークンは次の通り更に簡潔な形でも表現でき
る。

〈型、ポインタ〉 ここで、ポインタはそのトークンに関係するデータのア
ドレスである。この形式のトークンはエントリーの長さ
が同一であるため操作がより容易になる。トークンを更
に簡潔に表現するには、トークン型をデータブロック内
に含める場合であり、このことによって１つのポインタ
に対する基本トークンオブジェクトを減らすことができ
る。型の情報はデータブロック内に依然存在するから、
この形式のポインタは依然１つのトークンとして適切に
参照できる。過去の幾つかの試みにおいて、一種のトー
クン形式であるテキストの内部表現を使用した。しか
し、それらは全て迅速なテキスト作成に適用できないと
いう欠点をもっていた。

従来方式の多くのものはトークンをコンピュータプログ
ラムを編集するために使用していた。例えば、コピロッ
ト「対話形式プログラミングシステムにおける多重処理
方法」（ダニエルカール、1974年７月、博士論文、スタ
ンフォード大学）を参照されたい。スワインハートは、
コンパイラがプログラムを機械命令に翻訳するために使
用するソースコード（テキスト）とそれに対応するパー
ズ木（構文解析木）との間の関係を維持するためにトー
クンを使用している。編集操作が終るたびに、変化した
ソースコードの行を再走査してトークン化し、パーズ木
は再構築され、最終的にパーズ木の正確さをチェックす
る。これらの方式は、Lispの如き言語で書かれたプログ
ラムを作り修正したりするには人気があるが、かなり遅
く骨の折れるものである。プログラムに対してなされた
変更が、エラーを導入するのではなく除去するのは極め
て好ましく、ユーザへの利益となる。

第２の公知の方法では基本テキスト単位としてトークン
を使用してコンピュータプログラミング言語の要素でな
くて英単語（ワード）を表現している。「辞書依存式テ
キスト処理システム」と題するレキシコンテキスト（ジ
ョン・フランシス・ハーヴェイ、1971年８月、修士論
文、マサチュセッツ工科大学）では、一つのトークン
が、ワードに対するテキストを含むレキシコン（辞書）
エントリーを指示しており、その後、ハッシュ機能を使
用して各トークンに対して一義的に定義できるエントリ
ーと関連するデータを検索するようになっている。この
コーディング法は非常に一般的であるが性能を犠牲にし
ている。

〔発明が解決しようとする課題〕

更に、ハーヴェイの方法は原則としてオペーレーティン
グシステムに対する自然言語インターフェースとして使
用されるため、レキシコン（辞書）はグローバルであっ
て特定の文書から独立している。このアーキテクチャは
情報が単一の中央処理装置で処理されるような環境にお
いて、しかも、遭遇するワードの全体が予め知られてい
る場合に実際的である。しかし、複数のワードをそのグ
ローバルな辞書に追加することができても、処理装置が
ネットワークやその他の通信装置に接続されない分散型
環境においては依然問題が存在することになろう。この
場合、辞書は急速に大きくなって、ある装置で書かれた
文書が他の装置で正確に解釈することができないことが
ある。この方法のもう一つの大きな欠点は主辞書内にエ
ラーが発見された場合、その欠陥辞書によってコーディ
ングされた文書は解釈できないし、たとえ、その文書を
再構築することが可能であっても全て処理しなおさなけ
ればならない点である。主辞書は非常に大きく設計する
必要があるから、その辞書を主メモリ内に常駐したまま
にすることは実行不能であろう。主メモリ内に常駐しな
い大辞書は大きな性能上の不利益を蒙ることになろう。

本発明は、トークンを使用してテキストを表現する方法
に関し、特にWYSIWYGエデイタに適用した場合にテキス
トを効率的に編集すべく設計されている。本発明は、コ
ンピュータプログラムエデイタに使用される木構造のも
のではなく、単純なリンク構造のリストを使用する。ト
ークンは、そのトークンと関連するデータを直接指示し
ており、これによってハッシュ機能を除去しており、ま
た、データブロックの長さは可変であるにもかかわら
ず、データブロックは全トークンに対して一様に定義す
ることができる。辞書は各ドキュメントに限定されてお
り、分散的環境に適したシステムを得ることができる。

本発明の方法は、改行及びその他のマクロドキュメント
動作（ページ付け、サーチ、置換、スペル訂正等）を高
速ドキュメント作成システムに使用することができる。
また、本発明は、印字文字を表示しドキュメントをスク
ロールしドキュメントの位置にマウスクリックを定める
等の対話動作の性能を向上するのに使用できる。本方法
は、ハイフンのついたテキストを希望する場合に特に効
率的である。性能は、アルゴリズムが、リガチャ（合
字）、カーニング（字間を詰めること）、外部テキスト
等を支援するように拡大されても低下しない。本発明の
方法は、長いワード多く含んでいるドイツ語のテキスト
や、ハイフン分割や、そのハイフン分割に伴うスペルの
変更や、何度もハイフン分割を必要とするワードに大変
に適している。

〔課題を解決するための手段〕

本発明によれば、各々が１つ若しくはそれ以上の文字コ
ードで構成されるアトムのストリングから構成されるテ
キストをメモリに受取り該テキストをコーディングする
方法であって、前記アトムのストリングが、ある時間に
おいて、複数の前アトムと１つの現在アトムと１つの次
アトムを含んでおり、該アトムのストリングは、文字、
数字、句読点記号及びスペースのストリングからなる複
数のワードから構成されて、トークンのリスト及び対応
するデータブロックのアレイとして前記メモリに記憶さ
れている、テキストコーディング方法が提供され、本発
明においては、前記メモリを、ゼロのデータブロックと
ゼロのトークンのリストを用いて開始することによって
イニシャライズし、その後、以下のステップの反復によ
って前記リスト及びアレイの全体を作っている。かかる
ステップは、前記アトムのストリング内の現在アトムが
該ストリング内の１つの前アトムと同じかどうかを判定
し、もしそうならば、前記の前アトムのトークンと同じ
トークンを、前記メモリのトークンのリストの最後に加
えて、前記次アトムに進み、前記現在アトムが前記前ア
トムと同じでないならば、１つの新トークンを前記メモ
リのトークンのリストの最後に加え、該新トークンに対
応して、前記メモリ内に、前記現在アトムの文字ストリ
ングを含むデータブロックを追加し、次のアトムに進む
ことから成ることを特徴としている。

上記のように、本発明の方法は、ドキュメント中のテキ
ストを、ワード、句読点記号、スペース等の一連の『ア
トム』に分解し、それぞれに番号（すなわちトークン）
を付与することから構成される。一例として、あるドキ
ュメントにおいて“of"というワードすなわちアトムに
最初に出会った時、そのアトム“of"に番号すなわちト
ークン“301"を付与したとすると、そのドキュメント内
の他の全ての“of"に同じトークン（番号）“301"を付
与する。

ドキュメント内の各トークンに対して属性リストのテー
ブルが構成される。以下はスペース以外のアトムに対し
て維持される属性のリストである。

text:アトム内の文字群。

lastFont:本テーブル内に納められるトークン属性を計
算するために使用されるフオントの表示特性を示すコー
ド。

displayBitMap:フオントlastFont内のアトムテキストの
ビットマップ。

notPunctuation:アトムが句読点であるかどうかを示す
ブール。

atomMetrics:スクリーンとプリンタ装置内のトークンの
文字数とワード幅を含むレコード。この情報はlastFont
が参照するフオントから導出される。

breakPoint:トークン内の各区切り点についてエントリ
ーを一つ有するアレイ。もしエントリーがハイフン分割
点であれば、エントリーはハイフンの幅を含めハイフン
分割点の前のワード部分の距離情報を含む。もしハイフ
ンがユーザにより挿入された分割できないハイフン分割
点の場合にはハイフンの幅は含まれない。

スペースに対応するトークンは他のトークンとは異なっ
て取扱われる。そのスペースのトークンは、それを処理
するルールが他のトークンとは大きく異なっているた
め、スペーストークンと関連する属性の集合を有しな
い。

テキスト処理機能は、各逐次的に現れるトークン（以
下、単に逐次的トークンという）を用いて現在のトーク
ン属性にアクセスすることによって進められる。このた
め、ドキュメントを古典的に一度に一文字処理するアル
ゴリズムが著しく高速にされ、同様に、ドキュメントを
一連のアトムとして解釈するテキスト機能も著しくスピ
ードアップする。

改行アルゴリズムは、各逐次的トークンを用いてトーク
ン属性中の距離情報にアクセスできる。もし行幅が一定
長さを超えると、通常は、現在の行が前のトークンで終
わる。テキストがその右端で行揃え（ジャスティファ
イ）される場合には、ワードの間のスペースは伸ばせば
よい。もし、その行を十分に拡張できない場合には、ス
ペースを詰めすぎたトークンに対応するトークンを調べ
てそれがハイフン分割可能かどうかを判断する。

このようなトークン・バイ・トークン法（すなわちトー
クンによりテキストを処理する方法）によれば改行がよ
り効率的になるばかりでなく、文書が一連のアトム（例
えば、ワード、スペース、句読点）として解釈されるに
応じてその他の編集機能もスピードアップすることがで
きる。例えばスペルチエックの場合、一ドキュメント中
に１つのワードがどれ程多く使用されようとも、そのワ
ードのスペルは１回チエックするだけでよい。何故なら
ば、そのワードが出て来るたびに同じトークンが使用さ
れるからである。アルゴリズムは２つの段階で進行す
る。まず、アルゴリズムはアトムテーブル内のエントリ
ーを全てチエックした後、文書の隣り合うワードあるい
は分割されたワードを走査する。

本発明の方法によってコーディングされたテキストから
トークン全体だけでなく文字を挿入したり削除する作業
が非常に効率的に行える。一方、個々の文字の場合に
は、迅速な修正を可能にする特別のトークンが使用され
る。本発明のようにトークン全体を挿入したり削除する
作業は、トークンのストリングを修正するだけであるか
ら、前記個々の文字の場合よりも更に高速である。タイ
プ・イン中のスクリーン彩色も非常に高速である。何故
ならば、それら操作の全ては文書のデータ構造を更新
し、新たな行終了点を判断し、スクリーン上のテキスト
を彩色することを含み、これらは本発明の手法により利
益を受けるからである。

サーチと置換の機能もまた、１ワードだけをサーチして
いる場合に、アトムテーブル内のテキストのみを処理す
るだけで済むから好都合である。もし多数のワードをサ
ーチしている場合にも、一連の文字ではなく、ドキュメ
ントをアトム列について走査するだけでよい。

また、本発明のテキストコーディング方法によれば、非
常にコンパクトな外部フォーマットが可能になる。トー
クン属性を、基本の属性と、その基本のトークン属性か
ら計算できる派生属性（即ち、トークン内の文字と区切
り点の位置）に分離することができる。ファイル上に書
き出すにはは基本トークン属性のみが必要される。新た
なエデイットセションがそのファイルについて開始され
ると、基本属性を用いて派生属性を追加する。

〔実施例〕

以下、本発明のテキストコーディング方法について、更
に詳細に説明する。

データ構造 本発明に係るテキストをコーディングする方法は、ドキ
ュメントをアトムに解析してそのアトムに相当するトー
クンのアレイを構築する作業を含む。アレイ内の少数の
エントリーはトークンにしない。これらは特殊なエント
リーであり、頻度の少ない文字（連続したスペースの如
き）をコーディングするのに要求されたり、非常に大き
なドキュメントをコーディングするのに要求されたりす
るだけである。

第１図のテキストは、テキストをトークンにコーディン
グするのに必要なデータ構造の型を定義している。第１
図で使用されるコンピュータ言語は、メサ（Mesa:ゼロ
ックス開発環境メサ言語便覧、ゼロックス社、1985年）
である。メサはパスカル（パスカルユーザ便覧・報告、
キャサリーン・ジャンスンならびにニコラスワース、シ
ュプリンガー出版社、1974年）に類似しており、モジュ
ラII（モジュラIIによるプログラミング、ニコラスワー
ク、シュプリンガー出版社、1982年）に類似している。
デイレクトリ節は、インターフェーストークンからオフ
セットした型が改行メサで使用されることを宣言する。
次に、ファイルの機能がデータ型と手順を定義すること
であるからファイルは、DEFINITIOSファイルと宣言され
る。

コーディングされたトークンアレイを定義するデータ構
造はエンコーデイッドテキスト（Encoded Text）であ
る。アレイ中の各要素はエントリーである。コーディン
グされたテキスト内の各エントリーはメモリの１ワード
中におさまる。エントリーは、トークン及びエスケープ
の２つのバリアントを有するレコードである。

トークンバリアントは２つのフイールドより成る。即
ち、トークンが参照するアトムに対応する番号と、トー
クンの後にスペースが来るかどうかを示すブールとであ
る。性能を最大にするために、各アトムに付与されるト
ークンは、それを用いてそのトークンに対する属性の、
メモリ内のロケーションを判断できるのを可能にするよ
うに選択される。

Entryレコードのエスケープバリアントは、それ自体バ
リアントレコードとなる。このバリアントは、トークン
エントリーによっては表現できない情報をコーディング
するのに使用される。ChangeBaseエスケープバリアント
は大きなドキュメントをコーディングするために必要と
される。トークンバリアントのオフセットは14ビットの
みで構成されるため、直接アドレス指定可能なトークン
の数は限られている。ChangeBaseエスケープはトークン
属性のアドレススペースを変更することを可能にし、こ
れにより、非常に多くのトークン属性をアドレス指定す
ることが可能になる。

スペースエスケープバリアントは連続スペースを表現す
るために使用される。これは、トークンエントリーがア
トムの後に１個のスペースが続くかどうかをコーディン
グすることしかできないために必要である。スペースバ
リアントはパラメータを有しない。

ZeroWidthSpaceエスケープバリアントはアトム内のハイ
フン分割しない区切り点を表現するために使用される。
これはXICSマークアップ言語では滅多に使用されない特
長である（ゼロックスインテグレーテッドコンポジショ
ンシステムユーザガイド、ゼロックス社、1987年）。こ
のZeroWidthSpaceバリアントはパラメータを有しない。

第２図は、第４図のテキストから作り出されるトークン
のリストである。この図では、列毎にエントリーが１個
あるように、コーディングされたテキストの各エントリ
ーの内容を含む。わかりやすくするために、各トークン
のテキストは、第２図中の各トークンエントリーのすぐ
右側に含まれている。第２図の第１列はChangeBaseバリ
アントであるエスケープエントリーを含む。ChangeBase
バリアントは、そのトークン属性についてのアドレスス
ペースを第１のアドレス空間にセットする。トークン属
性のアドレスは、ChangeBaseエントリー中に定義された
ベースアドレスとトークンエントリー中のオフセットと
を結合することによって計算される。第２図の第２列は
トークンバリアントエントリを含む。各アトムについて
は２個のアイテムがある。即ち、そのアトムを識別する
番号とアトムの後にスペースが存在するか否かを示すビ
ットである。本発明にかかるテキストコーディング方法
では、アトム間のスペースは先行するアトムの一部とな
る。例えば、第１のワード“The"、は 〔SpaceFollows:TRUE,offset:1〕 という値を付与される。

同様にして、第２のワード“approach"は 〔SpaceFollows:TRUE,offset:20〕 となる。

８番目のエントリーは再び“the"という語となるが、小
文字“t"を備えている。このアトムは文字幅が普通の場
合同一でないために大文字“T"を有する本来の“The"と
同一のトークンを付与することはできない。16番目のエ
ントリーは左括弧である。次のようにコーディングされ
る。

〔spaceFollows:FALSE,offset:323〕 リスト上の28番目のアイテム、“or"というワードはリ
スト上の17番目のワードと同じワードである。それらは
同一の属性を持つから同一のトークンを使用する。同様
にして、25番目のエントリーと27番目のエントリーのコ
ンマは同じトークンを有する。

各トークンは、第３図に示すように関連する属性のリス
トを備えている。属性のセットは２つのレコードより構
成される。即ち、TokenProps.ObjectとレコードTokenPr
opの１例とである。これらレコードの両方ともMACHINED
EPENDENTと宣言され、メサコンパイラをしてフィールド
を可能な限り少ないワード数のメモリに詰めこませる。
値をアクセス回数の少ない順に配列することによってト
ークン属性にアクセスするために必要とされるメモリ参
照の数を最小限にすることができよう。メサプログラミ
ング言語では中間長アレイはレコードの終りにしか配置
できないため、最適順序を実現するためには２個のレコ
ードが必要になる。

Objectレコード中の最初のレコードはアトムが句読点で
あるかどうかを示すブールである。このフィールドはど
こで適法の区切りが行われるかを判断するために改行計
算中に使用される。

次のものは、フォントの型、サイズ、ストレス及びウエ
ート（強勢）を識別する番号である。この番号は最後の
フォントを示し、この最後のフォントから、アトムMetr
ics,breakPointアレイ（存在する場合）およびデイスプ
レイビットマップが計算される。従って、もしアトムが
処理中の現在のフオントが既にアトムが処理された最後
のフオントと同一であるならば、属性レコード中の値は
まだ正しいものであるため、アクセスされるだけで再計
算されることはない。同一でない場合には、属性レコー
ド中の値は現在トークン処理する前に再計算する必要が
ある。

第３のフィールドはAtomMetricsと呼ばれ、同様にToken
Propsインターフェース中で定義される。このレコード
はアトム全体についての距離情報を含んでいる。AtomMe
trics内の値は、マイカ（１インチの1/2540と定義され
る機械独立単位）及びピクセル（表示スクリーン上の単
位）単位でのアトムの長さと、バイト単位でのアトムテ
キストの長さである。英文字テキストは、各文字につい
て１バイトを要するのが普通であるが、別の言語や特殊
技術記号を表わすにはそれ以上のバイトが１文字あたり
必要となるかもしれない。１文字あたり１バイト以上を
要する国際文字や特殊記号をコーディングする方法につ
いてはゼロックス文字コード基準（ゼロックス文字コー
ド基準、ゼロックス社、1986年）を参照されたい。

atomMetricsに続くのはbreakPointCountで、アトムが行
と行とに分解できる位置数に相当する。行の区切り点は
普通ワードにハイフンをつけることによって判断され
る。“１ワード”には手で挿入されたゼロ幅スペースが
含まれる。このコーディングではアトム“the"は区切り
点をもたない。Object中の最後のフィールドはbreakPoi
ntアレイである。このアレイはアトム中に区切り点がな
ければ全く省略することができる。第11図はアトム“Th
e"の属性のメモリのレイアウトを示す。もしアトム中に
区切り点が存在すれば、breakPointアレイの各要素は元
のワードをハイフン分割することによって形成された分
割後のワードの最初の部分より構成される。例えば、３
音節ワードの“document"は“doc−”と“docu−”を記
述する情報である２個の区切り点を有する。これが、第
12図に示されている。

各breakPointアレイ中の最初の要素は、如何に望ましい
区切り点であることを表わすパラメータである区切り点
の型から構成される。これが改行アルゴリズムによって
使用される。バイトカウントとは交替的に表示される。
長さは、機械独立単位すなわちマイカとピクセルにおけ
る各選択肢の長さである。

属性を記述する第２のレコードはObjectTrailerレコー
ドである。トレイラーレコードはトークン属性中に常に
存在する。ObjectTrailer中の最初のフィールドはrefer
enceCountである。これは、一組の属性に対するスペー
スを解放すべき時を定めるため、エデイタのダイナミッ
クメモリ管理プログラムによって使用される。典型的に
はこれは基準カウントがゼロに達する時に行われる。

次のフィールドはラスタであり、これはRasterDataと呼
ばれるレコードであってアトムの格納されたスクリーン
解像を記述する情報である。第１のアイテムであるbp1
は各水平走査線における総ピクセルである。もし、例え
ば、ビットマップが16のビットワードに分割されれば、
この数は、アトムの像が文字“i"の場合のように小さな
“幅”を有するものであっても、16ビットの倍数にな
る。ピクセル内の像の実際の幅はatomMetrics中に記述
される。第２のアイテムはこのアトムについてビットマ
ップ全体を格納するために必要とされるメモリの全ワー
ド数である。例えば、１アトムのピクセルの幅が30ビッ
トで１画像が14ピクセルの高さであれば、ビットマップ
は28ワードを要することになろう。この数は次のように
して導き出される。

height^*bpl/bits−per−word ここで、bplは、画像幅以上の、メモリの１ワード中の
ビットの最小の倍数であると規約によって定められてい
る。height（高さ）は画像の高さである。ベースライン
は画像の上部からテキストが重なる走査線へ至る走査線
数である。ビットは画像の最初のワードに対する２ワー
ドポインタであり,RasterDataレコード中のフィールド
の表示については第13図を参照されたい。

トレイラーレコードの最終フィールドはテキストと呼ば
れる。これはトークン中に文字を含むアレイである。ア
レイの長さは先に定義したAtomMetrics中に格納され
る。トークンのサーチを最適化するために、テキストフ
ィールドに割当てられるバイトの数は実際にはトークン
中の文字数を超えるかもしれない。割当てられる文字数
は、アルゴリズムが実行される特定の機種に応じて、通
常２もしくは４の倍数である。

第５図はMesaソースコードで改行を計算するためのデー
タと手順を定める。ファイルのディレクトリー部分はLi
neBreak.mesa中に参照される他のインターフェースファ
イルの要素を定める。LineBreak.mesaはファイルの機能
がデータ型と手順を定義するから、DEFINITIONSファイ
ルとして宣言される。

SuffixCharはテキストの一行の終りに出現可能な最終文
字を定める型である。これはディスプレイアルゴリズム
に必要となる。SuffixCharは、列挙された型中の各エレ
メントに付与される値が連続し且つ０から始まるの確実
にするために機械依存性として宣言される。

Reasonは改行アルゴリズムが復帰できる可能な理由を列
挙する列挙された型である。Reasonは改行アルゴリズム
がコンパイラが列挙型中の各エレメントに付与する特定
値に依存するため機械依存性をもつ。以下のテーブルは
Reasonの値をそれぞれ実行する。

margin:現在トークンが行幅を費消し改行決定が行われ
る。このことはアルゴリズムに対して課される制約の全
てを充たす改行が識別されたことを意味する。

normal:現在のテキストブロックが改行決定を行わずに
費消された。

changeBase:現在トークンはChangeBaseエスケープであ
る。

invalidProps:現在トークンの属性は時代遅れで現在フ
オントで計算しなおす必要がある。

contiguousWords:現在トークンの前にはスペースや句読
点はない。このことは通常２個のトークンが１ワードの
断片であることを意味する。この結果、一連のトークン
断片をハイフン分割する必要がある場合、クライアント
コードが、カーニング（字間を詰めること）及び字間を
あけることのための距離情報を調節し、断片トークンの
開始の追跡を維持するのを可能にする。

unableBreak:現在行幅に達しても改行決定はできない。
この結果を生じさせる最も一般的な事象はマージンを超
えるトークンが句読点である場合である。

specialGermanCase:改行アルゴリズムが、所望のハイフ
ン分割点でスペル直しを必要とするトークンを区切る
時、この理由は復帰する。

TwelveBitsは12ビットの無符号整数を定義する型であ
る。以下に述べるStateRecレコードに使用される。

ArgRecは改行アルゴリズムに対する引き数である機械依
存レコードである。これが機械依存であるのは、レコー
ド内の数フィールドが、可能な場合、メモリの１ワード
中に実装されるからである。

レコード中の最初のフィールドはテキストと呼ばれ、処
理されるトークンのアレイを表わす記述子である。記述
子はメモリの３ワードを占め、そのうち最初の２ワード
は第１のトークンに対するポインタより成り、最後のワ
ードはアレイの長さを定義する。

フィールドpropsBaseは、コーディングされたテキスト
アレイのトークンエントリー中に埋込まれたポインタの
相互関係を明らかにするために使用されるベースアドレ
スである。コーディングされたテキストの一節の一例と
しては第２図を参照されたい。propsBaseの後にはハイ
フネートと称されるブールが来る。もしハイフネートが
TRUEであれば改行アルゴリズムは行幅を横切るトークン
をハイフン分割しようと試みる。ハイフネートがTRUEで
なければ、アルゴリズムは行幅におさまる最後の完全な
トークンまで戻る。次のフィールドは、処理中のフオン
トの型、サイズ、ストレス及びウエート（強勢）を表わ
す。もしArgRec中のフオントのフィールドがトークンPr
ops中のフオントフィールドの一つにマッチしない場合
には、アルゴリズムは無効Propsの理由で復帰する。フ
オント後のフィールドはマージンであって、これは、マ
イカ単位での行の距離である。

ArgRec中の次の２フィールドはhyphenPixelLengthとmin
SpacePixelLengthである。これらはそれぞれハイフンの
幅とスクリーン装置（ピクセル）中に入ることのできる
スペースの最小幅を定める。次の２つのフィールドはハ
イフンの幅とマイカ（mica）単位でのスペースの最小幅
である。

whiteSpaceフィールドはスペースの最大のサイズ（mic
a）を定める。改行判断を行うにはmica尺度しか使用さ
れないため、スペースの最大サイズをピクセルで定める
必要はない。

ArgRecにおける最後の２つのフィールドはfinalとprior
と呼ばれる。これらは両方ともLineBreakの例である。
これらのフィールドはメサ記述法ではそれぞれarg・fin
alとarg.priorと称される。これらレコード中の値は、
一時的に記憶し改行判断を行う際の結果を記録するため
に改行アルゴリズムによって使用される。arg.prior中
の値は現在のテキストブロック中に通される最後の区切
り点を表わす。同様にして、arg.finalは現在の改行ア
ルゴリズム出口前に処理された最終トークンについての
データを含む。もし改行判断が下されると、arg.prior
中の値は現在行末の値を含み、arg・final中の値は次の
行を開始するための値となる。

上記LineBreck.Stateレコード中の最初のフィールドはi
ndexすなわち指標である。これが、encodedTextの開始
に対する現在トークンの指標となる。また、micaLength
とpixelLengthは、現在行に割当てられたトークンのそ
れぞれマイカとピクセルとにおける累積幅である。これ
らは特に現在テキストブロックにおけるトークンの累積
幅ではないことに注意されたい。次のフィールドは現在
行上で出会うブランクのカウントである。ブランクの後
はカウントはnotPunctuationと呼ばれるブールである。
このフィールドは最後のトークンが句読点であるか否か
を示す。このフィールドは一行内の適法な区切り点の位
置を判断するために使用される。suffixCharは改行決定
が行われた後に行上にある最後の文字を表わすコードで
ある。suffixCharの可能な値は先に列挙された型Suffix
Char中に定義されている。byteCountフィールドは現在
行に割当てられたトークン中のバイトの総数である。最
終フィールドWhiteSpaceは改行判断を行なう時に改行ア
ルゴリズムがその行に割当てることのできる白地スペー
スの最大量である。

ArgHandle,ArgSpace,およびargAlignmentは、ページの
境界での交差を回避するようにArgRecをメモリ内にせ整
合させるのに必要とされるデータ構造を規定する３つの
型である。この不変数が、ゼロックス6085ワークステー
ションにおけるマイクロコード実行によって使用される
最適化である。ArgRecは23ワード長であるから、レコー
ドはページ境界での交差をしないようにするため、32ワ
ードの境界からスタートする必要がある。ArgSpaceは55
ワード長のメモリブロックを定義する。そのためその範
囲に32ワードの境界が存在し、境界の後に十分なスペー
スが残りレコード全体を含むことができる。LineBreak,
AllgnArgRecは引き数として55ワードのメモリブロック
のうちの−に対するポインタをとり、ブロック内に含ま
れる32ワード境界に対するポインタを復帰させる。

LineBreak.SoftwareLineBreakとLineBreak.LineBreak
は、次のセクションで明らかにするMesa改行アルゴリズ
ムのマイクロコードバージョンを定義する。２つの手順
は同一の結果に復帰し、違っているのは、後者すなわち
LineBreak.LineBreakがゼロックス6085ワークステーシ
ョンに対するカスタム機械命令として実行される点であ
る。これら手続の両方に対する引き数はArgRecに対する
ポインタで双方ともLineBreak.Reasonに復帰する。

第６図はファイルLineBreakimpl.mesaの内容である。こ
のファイルはインターフェースLineBreakの実行を与え
る。ファイルのDIRECTORY部中の名称のリストはLineBre
akimpl中に参照されるインターフェースファイルの名前
を宣言する。次のソースとなるステートメントにおい
て、LineBreakimplはインターフェースFrameからのサブ
プログラムを使用し（IMPORTS）、インターフェースLin
eBreakを介してプログラムを共有（EXPORTS）するプロ
グラム（以前のような定義ファイルでない）として宣言
する。一定のnullDataがPROGRAMステートメントの直後
に宣言される。

改行アルゴリズム 第６図（ａ）において、SoftwareLineBreakはargumenta
rg.中に格納されたマージンに基づく行末を計算する。
プログラムは同一行中に一つ以上のテキストブロックを
必要とする場合を取扱うように設計されている。設計は
そのプログラムを使用するアプリケーションがテキスト
を格納するために使用する方法からも独立している。主
要手順は、４個のネスト構造のサブプログラムを含むよ
うに組織される。

WholeWordBreskはワード全体の終りもしくはスペースで
終行判断が行われるときに使用される論理である。Whol
eWordBreakはarg.final中のデータを初期化して現在行
を終了するものの後にトークンの開始を照会する。この
手順はINLINE手順と宣言され、短い手順についてより良
好な動作を意味するマクロとして処理されることを示
す。

SaveThisBreakはarg.finalの内容をarg.priorへ転送す
る手段である。もしトークンを現在行に追加することが
できない場合にも論理はarg.prior中の値に復帰する必
要がある。この手続はまた動作上INLINEと宣言される。

第６図（ｂ）において、ProcessSpaceは現在スペースが
行上にフィットするかどうかを見るためにチエックす
る。もし否であれば、処理は終了し、ルーチンはTRUE値
に復帰する。もし、現在スペースがフィットすれば、ar
g.final中のデータは現在点における値を反映するよう
に修正され、この場合、ルーチンはFALSE値に復帰す
る。また、ProcessSpaceは動作を最適化するためのマク
ロとしても取扱われる。

HyphenateWordはマージンがトークンにより横断される
時に実行される副手続である。もし処理された最後のト
ークンが句読点文字でない場合にはアルゴリズムはunab
leToBreak出口節へ分岐する。この出口のための理由はu
nableToBreakにセットされる。この前後関係によりスペ
ースは句読点文字として考えられる。同様にして、も
し、選択すべき区切り点がなかったり、現在のテキスト
ブロックに対してハイフン分割が選択されない場合に
は、アルゴリズムは、分岐を経て、noneFitsExit節へ退
去する。もし、この通路が実行されると、処理される最
後のトークンは区切り点として選ばれ、finalの値は手
続WholeWordBreakにより初期化される。

この時点でアルゴリズムはハイフン分割点が退去し、区
切り点の一つを選ぶのが適当であることを判断した。メ
インループ内に入る前に２個の変数が初期化される。第
１の変数は区切り点アレイのエレメントのポインタであ
る。この変数は区切られるトークン中の区切り点アレイ
の第１のエレメントを指示するように初期化される。第
２の変数は最後のトークン部分を含むテキストが白地ス
ペースの制約を満足するためにとらねばならない最小の
幅である。

HyphenateWord中のメインループはリスト内の区切り点
から最良の区切り点を選択する。アルゴリズムは、区切
り点を２つのキーからソートすることを要求する。即
ち、先ず、優先順位の下降順（いいかえれば最も望まし
い区切りが最初に来る）であって、次に、各優先順位階
級内では、トークン内の下降順である。この順序によっ
てアルゴリズムは区切り点上を一回パスしただけで最適
の区切り点を発見することができる。最適な区切り点は
最高優先度を有するものであり、その結果、行に対して
最もきっちり納まることになる。

３つの例外のためアルゴリズムは最高優先順位と最もき
っちり納まるという基準に基づいた区切り点を選択しな
くなる。第１の例外は区切り点が選択された場合にリス
ペリング（スペルの再構成）を必要とするドイツ語の如
き特殊事例の区切り点についてのものである。第２の例
外は手で挿入される、即ち「ハードな」ハイフンが存在
する場合である。その場合には手で挿入されるハイフン
はそれが最もぴったりと納まるかどうかで選ばれる。第
３の例外は区切り点が全て大きすぎる場合、即ち、何れ
も少なくとも最小の白地スペースをもたない場合であ
り、その場合にはアルゴリズムは区切り点を選択せずに
終了し、先のトークンの境界は行の終結用に使用され
る。

第６図（ｃ）に図示のように、適当な区切り点が選択さ
れると、HyphenateWordはsuccessExit節を経て退去す
る。節の４つの文はarg.finalとarg.priorfieldをそれ
ぞれ更新し、選択された区切り点を反映するようにな
る。次にarg.finalは新行を開始するトークン部分を表
わすように更新される。arg.finalが更新される方法は
選択されたハイフン分割点のタイプに依存する。もし区
切り点が区切り点論理によって発生させられる合成ハイ
フンである場合には、ハイフンは実際にはトークンの一
部ではないから調節する必要がある。合成ハイフンでは
ない最も一般的なハイフンはハードハイフンである。

行を終らせるために任意の形のハイフンを選んだ場合、
micaLength、pixelLength、byteCountは全て先の行を終
らせるトークン部分を表わす負数を付与される。索引の
値は、同一のトークンが次の行を開始するように変化し
ないまま留まる。arg.final中の負値がトークン全体に
対する値に追加される場合、結果は新しい行を開始する
トークン部分にとって適当な値となる。

第６図（ｄ）に図示のように、SoftwareLineBreakの主
要部分はarg.finalとarg.priorに対するポインタの初期
化とともに開始される。メインループはarg.final索引
が現在テキストブロック、arg.textの長さより短いか等
しい限り実行される。arg.text中の各トークンエントリ
ーに対して行われる処理はトークンエントリーの型に依
存する。

もし型がトークンエントリーであれば、バリアント選択
文のトークン分岐内の最初の文は処理を加速化するため
に回り道レベルの幾つかを照会する。次に、このテキス
トブロックに対して希望されるフオントはアトム作成法
を計算するために最後に使用されたフオントと比較され
る。もしフオントが不正確であれば、メインループはin
validProps節を通って退去し、そのため今度はinvalidP
ropsの理由で手順からの復帰が引き起こされる。これ
は、発呼者に対して、トークン属性を計算しなおし且つ
手続を再開する機会を与える。もし、属性が依然有効で
あれば、トークン全体が現在の行上に納まるかどうかの
計算が行われる。もし、そうでなければ、ループはmarg
inExit節を経て退去し、ハイフン分割が試みられる。も
しトークンが納まれば、スペースか句読点なくアルゴリ
ズムが２の連続トークンに出会ったかどうかについての
チエックが行われる。もしそうであれば、ループはcont
iguousExit節を通って退去する。

この時点では現在のトークンが行上に納まり同行に追加
できるということが判断されたところである。次のメイ
ンループの４行はarg.finalを更新してこれを反映させ
る。節中の最終行はこのトークンについてspaceFollows
のブールがTRUEであるかどうかをチエックする。もしそ
うであれば、ProcessSpaceの副手段が実行される。もし
スペースが行上に納めらなければハイフネーションが不
要であることは明らかであるからメインループはsimple
MarginExitを経て退去する。もしスペースが納まれば、
選択文のトークン分岐は退去して、final.indexは増分
され、テキストブロック内の次のエントリーが処理され
る。

テキストエントリーがToken.Entryレコードのエスケー
プバリアントであれば、メインループ内のパリアント選
択分の他の分岐が実行される。第１図に記述されている
通り、エスケープバリアント自体はバリアントレコード
である（Mesa中の匿名レコードと称される）。それ故、
選択ステートメントのエスケープアームは、選択ステー
トメントでもある。先に述べたごとく、このレコードの
３つのバリアント（変数）は、スペースと、ZeroWidthS
paseと、changeBaseである。

スペースバリアントの処理はProcessSpaceサブルーチン
を実行することから成る。スペースが行上に納まらない
場合は、メインループはsimpleMarginExit節を経て退去
する。ZeroWidthSpaseに出会うと、final.suffixCharが
これを反映するために更新される。行上の現在位置は次
のトークンが納まらない場合は実行可能な区切り点にさ
れる。changeBaseエスケープは、changeBase退去節を経
てメインループからの退去をひきおこす。発呼者はarg.
propsBaseを含む必要なデータ構造の全てを更新するか
ら他の処理は不要である。エスケープエントリーに対す
る処理が退去が実行されることなく完了すると、節は退
去させられ、final.indexは増分され、次のテキストエ
ントリーの処理が開始される。

もし、テキストブロック全体が終行判断を行わずに処理
されると、手続は主ループのFINISHED退去節を経て退去
する。

第８図は第４図中のテキストの処理の開始に先立つargR
ec中の値と、その後計算された最初の３行の各々の後の
argRec中の値を示す。第１の事例では、テキストの値は
第２図内のコーディングを表わす記述子である。値は簡
単にするために削除されたところである。フォント、マ
ージン、hyphenPixelLength,minSpacePixelLength、hyp
henMicaLength、minSpaceMicaLength及びwhiteSpaceの
値は10ポイントのセリフ・フォントについて全てセット
される。finalとpriorの値はトークンが処理されていな
いため全て最初の零値にセットされる。

第８図中のargの第２の値は第１行が計算された後のarg
値に相当している。finalとpriorの値だけが変化したと
ころである。final索引とprior索引は第１行上の最後の
トークンがハイフン分割されているため同一である。第
２図中では、10番目のエントリー（最初のエレメントを
０番とした場合）は、トークン“document"に相当する
ことに注意されたい。arg.prior中の値は最初の10個の
トークンと“docu"を通る第11番目のトークン部分とを
プラスしたものに等しい。arg.final中の負数はarg.pri
orの値中に含まれる最終トークン部分にのみ相当する。
これらの値を次行の最初のトークンに加えたばあい（そ
れは、ワード“document"全体の値に等しくなろう）、
ワードの適当な部分、“ment"が行値に加えられる結果
となる。このことは第14図に図示されている。改行判断
が１トークンを２行にわたって分割することを必要とす
るばあい、同一のトークンを２回処理することによっ
て、SoftwareLineBreakを呼ぶコードはハイフン分割が
起こったかどうかとは、独立な論理で書込むことができ
る。この不変性のため大変に効率的なページ付けコード
が得られる。

第２行が計算された後、arg中の値は第８図中の第３のa
rg値における値となる。このブロックではマージンの値
は変化して第２行が字下げされていないことを反映して
いる。第２行はハイフン分割されないため、arg.final
索引の値と、arg.prior索引中の値とは異なる。このこ
とがふさわしいのは第２行がトークン“each"であるエ
ントリー21で終了するが、第３行はエントリー22“uniq
ue"で開始されるためである。第２行の最終トークンは
ハイフン分割されていないから、第１行の場合に存在す
るような行間の繰越し値は存在しない。それ故、この時
点でのarg.finalの他の値は全て零である。

第８図中のargの最終値は第４図の第３行に相当する。
この行は完全なトークンにより開始され完全なトークン
と共に終了した。

第７図（ａ）〜（ｈ）は、Ｃプログラミング言語で書か
れた第１図、第３図、第５図第６図におけるプログラム
リストである。このプログラムはモデル3/50の如きサン
マイクロシステムミニコンピュータ３、４ファミリーの
何れのメンバーも含めて、Ｃコンパイラを提供する任意
のコンピュータで実行することができる。このコードも
またDECVax7xxファミリーとmicroVaxコンピュータで実
行された。

表示アルゴリズム 改行アルゴリズムと表示アルゴリズム間には２つの主な
相異がある。先ず、どこに行末があるかを判断するため
にトークン作成法を蓄積するよりも、この情報は先に計
算して表示アルゴリズム内へ通さなければならない。ト
ークン数（もしくはトークン部分の数）と累積計測情報
に関する情報は表示プロセスの初めに必要になる。この
情報はジャスティフィケーション（行端揃え）が望まれ
る場合にトークンの配置について適当な調節を行うこと
ができるために必要である。同様に、一定のテキストフ
ォーマットモードが望まれる場合に、表示アルゴリズム
は最初のトークンが表示される以前に彩色されるトーク
ンの幅をそれに対して利用可能にしなければならない。
例としては、不調和な左モードと、テキストが欄、ペー
ジもしくは任意の尺度上に集中したモードである。第２
の相異は、表示アルゴリズムがTokenProps.TrailerObje
ct（第３図）中のRasterDataにアクセスしてテキストの
１行の表示ビットマップを蓄積する点である。このこと
は大抵の機械のラス処理サポートに類似したゼロックス
6085ワークステーションのBitBlt機械命令（パイロット
プログラマー用便覧、ゼロックス社、1985年）を用いて
行う。この命令がソースビットマップについて使用する
ビットマップの記述は幅とビットマップ内へのビットオ
フセットの両方を含む。これらパラメータは、トークン
が通常ハイフン分割によって２行間に分割される時、ト
ークンビットマップの一部のみを彩色することを可能に
する。トークンビットマップの幅が30ビットで、トーク
ンが区切り点17ビットでハイフン化された映像になる例
を考えてみよう。区切り点に先立つ映像部分を彩色する
ためには、幅は17にセットされ、オフセットは０となろ
う。区切り点後の部分を彩色するためには、幅は32マイ
ナス17もしくは15ビットとなり、オフセットは17ビット
となろう。このことが何時重要となるかの例については
第４図の第２行と第14図を参照されたい。

さてテキストを１回に１トークン彩色することは１回に
１文字彩色する同じプロセスと比較することができよ
う。両方の場合とも、フォント（あるいはテキスト映
像）情報の同じビット数がディスプレイに渡されるが、
１回に１トークンの場合の方が動作は相当高速である。
動作の差異は、（システム）ディスプレイビットマップ
を格納するメモリの各ワードがアクセスされる必要され
ねばならない回数が少ない結果である。メモリ照会数は
テキストが１回に１文字表示される場合にはずっと多
い。典型的な文字ビットマップの幅は文書本文テキスト
（即ち、見出しや脚注の如き特殊機能には使用されない
テキスト）に通常使用されるフォントサイズについては
４〜６ビットオーダである。このことは16ビットのワー
ド長を有する機器の場合には、ディスプレイメモリの各
語は３〜４回アクセスされるが、隣接文字（テキストの
１ワードの場合のように）のビットマップはディスプレ
イビットマップ中に書込まれることを意味する。もし機
器が32ビットのメモリワード長を有する場合にはメモリ
の各ワードは映像が組立てられる間６〜８回アクセスさ
れることになろう。

テキストを１回に１文字彩色する場合と１回に１トーク
ン彩色することとの性能の相異はテキストが幾つかの文
字もしくは文字部分を余分に打つ必要のある文字を含む
場合には更に重要になる。このことが生ずる場合の例
は、普通フォント中には含まれないアクセントをつけた
文字や数学記号である。いったん、これら特殊文字や記
号の映像が発生してトークン属性中に挿入されると、そ
れらはフォントが変化しない限り再使用できる。

ドキュメントの修正 さて出版業務に使用されるWYSIWYG文書エデイタに本発
明を適用した場合について説明する。本発明は他のテキ
スト処理業務にも使用することができよう。本システム
により処理される文書すなわちドキュメントはテキスト
断片を点在させたフォーマット命令（組み指定）より成
る一連のエレメントから成る。テキストの断片自体は一
連のトークンである。ドキュメント中の各エレメントは
ピースと呼ばれ、データ構造全体はピーステーブルと呼
ばれる。Token.Entryベクトルを表わすピース（従って
テキストである内容を備える）は、テキストピースと称
する。ドキュメントすの修正を容易にするために個々の
ピースはポインタと両方向にリンクされる。

セレクション ユーザはテキストの一部分を識別しWYSIWYGエデイタも
しくはテキスト処理システム中で通常実行される編集操
作の一つを呼び出すことによってドキュメントを修正す
る。処理されるテキスト部分はセレクションと呼ばれ
る。セレクションは１文字ぐらいの小ささの文字と、一
連の隣接文字もしくはワード、あるいはドキュメント全
体の規模から構成することができる。セレクションは通
常、テキストの外形を変化させることによって示され
る。高解像度スクリーンを有するシステムで望ましい方
法はセレクションを反転ビデオで表示することである。

開始と終了を有する外に、セレクションは挿入点も有す
る。それは通常セレクションの終りにあるがその初めに
もってくることもできる。挿入点は明滅する挿入記号
（Λ）で識別される。挿入点を含むピーステーブルエン
トリーは入力焦点と定義される。視覚的に入力焦点がテ
キストのみにつけられているように見える場合でも、挿
入点を実際には命令を含むピーステーブルエントリーに
つけることは可能である。

ユーザがセレクションに対して実行できる操作はそれを
削除したり、挿入点で開始される１つもしくはそれ以上
の文字もしくはワードだけバックスペースさせたり、挿
入点後に文字を追加することである。ワード単位でバッ
クアップすることをバックワード操作と称する。何れの
場合も、本発明により表示されるテキストを処理するア
ルゴリズムは一連の文字としてコーディングされたドキ
ュメントを処理するための等価アルゴリズムよりも幾分
異なっている。

いったん上記操作のうちの一つがセレクションについて
実行されると、そのセレクションは非活性化する。この
ことは操作後にセレクション中のテキストの強調を解除
することによってユーザに示される。

マウスクリックの分解能 テキストの一部は、座標情報をポインティング装置から
ドキュメント内の位置へ変換することによって選択され
る。このプロセスはドキュメント内の位置を分解すると
呼ばれる。殆んど全ての会話形式WYSIWYGシステムがあ
る形式のポインティング装置を備えている。最も普通に
はポインティング装置はマウスである。それよりずっと
少ないが、一組のカーソルキーがそれに次ぐ。

ポインティング装置は装置の活動中に規則的な間隔で座
標情報を提供する。座標情報をドキュメント内の一位置
へ変換するプロセスは本発明によって容易にすることが
できる。

分解アルゴリズムは３つのフェーズで進行する。まづ、
座標を含むテキストの行が位置指定される。次に特定の
トークンが識別される。そして最後に文字が位置指定さ
れる。エデイタはどのテキスト行が新たな座標を含むか
を判断するためにソフトウエアを分解する何らかの方法
を提供する必要がある。典型的にはこのことは行ボック
スのテーブルによって行われる。行ボックスを記述する
情報は行の位置（もしくは向き）、行の寸法、および行
上の最初のトークンの開始オフセットである。

いったん行が位置指定されると、分解アルゴリズムは行
内のトークンを列挙してどのトークンに座標が配置され
ているかを判断することができる。この時点で個々の文
字を点検してどの文字中に座標があるかを判定すること
ができる。

行ボックスのテーブルはエデイターの設計が多数行設定
モードをサポートする場合には不可欠である。もしテキ
ストが幅の変化するスペースで組まれているかテキスト
が欄の左側に沿って整列していないならば、スペースの
数と幅に関する情報もテーブル内に含める必要がある。
高速プロセッサの場合、行テーブルを適当なページをｎ
番目の行につけることによってｎ番目の行ボックス内の
情報を復帰させるページ付け論理に対する手続インター
フェースを取替えることが可能である。

従来そうであったような１度に１文字ではなく、１度に
１トークンだけ行全体を進むことによって、分解プロセ
スはずっと高速に進行する。特に、１文字毎に１バイト
で表現できない国際テキストもしくは数学テキストの如
き複合テキストの場合には、ここで述べる方法は相当高
速であろう。

削除アルゴリズム 一連のトークンとしてコーディングされたドキュメント
の一部を削除するアルゴリズムはピーステーブル中に格
納された文字列として格納されたテキストを削除するア
ルゴリズムに非常に似ている。一般的な場合、削除は、
セレクション内の最初と最後の文字が同一のピーステー
ブルエントリー中にないような１文字以上より成るセレ
クションに対して行われる。最も簡単なケースはセレク
ションの開始がスペース直後（トークンの開始）であっ
たり、同様に、セレクションの終りがスペースの直前に
ある場合である。この場合、削除の結果として新たなト
ークンはつくりだされないが、セレクションの開始と終
了がテキストの同じピース内にあるかどうかに応じて２
つほどのピースが作りだされる。セレクション直後のス
ペースのコーディングはもしセレクションの最終トーク
ン内のspaceFollowsブールを使用してコーディングされ
る場合には、Token.Entryのスペースエスケープバリア
ントに対して変化される必要があろう。もしセレクショ
ンの一端が最初もしくは最後のトークンの内部文字の一
つに該当するならば、新たなトークンが削除より生ずる
ことになろう。もしこの場合が起きると、ChangeBasees
paceToken.Entryをその結果生ずるピースに追加して新
たなトークンの各々のベースアドレスを反映させる必要
があるかもしれない。

第15図中のテキストは先に第４図に示したものと同じテ
キストを含む。テキストのハイライト部分（白黒の反転
部分）はセレクションが削除された時に幾つかの新たな
トークンがつくりだされることになるセレクションを表
わす。最も一般的なケースを明らかにするために、新た
なトークンは現存するトークン（ベースアドレス番号
１）用に使用される領域よりも異なるメモリ領域内に配
置されるものと規定する。削除の結果、１つはセレクシ
ョンに先立つテキスト部分に対するもの、他はセレクシ
ョン後の部分の別個のピースの２つのピースが生ずるこ
とになろう。第２図は削除前のパラグラフの残存部分に
対するピーステーブルエントリーを含む。第９図はテキ
ストの元の断片の初めと終りを示す（なくなったピース
部分は第２図のピース部分に相当する）。ChangeBasees
paceToken.Entryが必要とされるのは、新たなトークン
が他のトークンが存在する同じトークン属性領域内にな
いためであることに注意されたい。第10図は第２のピー
ステーブルエントリー内のトークンを示す。

新たなトークンの前には、ChangeBaseespaceToken.Entr
yが来る。ベースアドレスを残りのトークンのために使
用される第１のアドレス空間へ戻すためにこのピース内
には第２のベースアドレス変更が必要である。

修正可能なToken.Entryアレイとトークン属性 ピーステーブルエントリー（およびエントリーの内容）
は格納必要条件を最小にするために普通は固定長であ
る。バックスペースとバックワードは全て挿入点を含む
ピーステーブルエントリーの内容を変化させる、修正さ
れた内容に対して新たなスペースを割当てたり、入力焦
点の内容を新しいスペースにコピーしたり、新たなピー
スの内容を更新して変化を反映させたり、旧内容の配分
を解除したりすることは各操作の後には実際的ではな
い。これらの操作を反復して行うとダイナミックメモリ
が断片化して性能が不十分になる。この断片化を回避す
る道は変更容易な過渡電源を識別することである。殊に
任意の長さの予め配分したToken.Entryアレイであれば
これらの操作の一つが選択された時に実際のピースの内
容と取替えることができよう。

さて、アレイの長さはその変化を反映するために各操作
の終りに簡単に調節する必要がある。修正可能なエント
リーアレイを必要とする第１の操作が呼び出されると、
入力焦点の内容は修正可能なエントリーアレイ中にコピ
ーされ修正可能な内容に対する基準は入力焦点内に配置
される。その後、編集アルゴリズムが呼び出される。入
力焦点の内容はある事象が修正可能ピースに対するそれ
以上の操作が起こり得ないということを告知するまで、
修正可能スペース領域内にとどまる。この性質の事象は
ユーザがドキュメントに対する編集セッションを終了し
たり、セレクションを別のドキュメント部分へ移動させ
たりすることを含む。最後の編集が行われた後、入力焦
点内に残存する内容は何れも新たなスペースを配分し、
修正可能スペースの内容を新たなスペース内へコピー
し、新スペースに対する基準を入力焦点内に配置するこ
とによって永久的なものになる。

また、挿入とバックスペースも高速動作中にトークン属
性を繰返し配分し配分解除することにより生ずる同様な
性能上の問題を回避するために修正可能なトークン属性
を必要とする。修正可能トークン属性スペースに対する
基準は最初の挿入もしくはバックスペースが呼び出され
た時に修正可能Token.Entryアレイ中の最後のトークン
バリアントと取替えられる。その後、修正可能トークン
属性の内容は操作の順序に応じて永久属性スペースへ廃
棄されるか転送されるかする。このことは以下に詳説す
る。

修正可能Token.Entryアレイの長さは、限定することが
できる。一般的には、1000個のトークンの長さは滅多に
使い尽くされることはなく、この長さは実施上殆んど制
約を課すことはない。修正可能トークン属性スペースは
製作が可能な区切り点の最大数を維持するに十分な長さ
であればよい。

規約により、修正可能なトークン属性スペースはベース
アドレス零において１だけずれているものと定義され
る。この規約は以下の編集アルゴリズムにおいて使用さ
れることになろう。

バックスペース バックスペース操作が呼び出されると、アルゴリズムは
入力焦点のどちら側の端に挿入点が位置するかをチエッ
クする。もし、挿入点が入力焦点の右側にあれば、アル
ゴリズムは次のステップへ進む。挿入点が入力焦点の左
側にあれば、入力焦点はテキストを含む次の前のピース
テーブルエントリーへ移動する。挿入点は入力焦点の右
側に移動する。もし以前のテキストピースが存在しなけ
ればアルゴリズムは終了する。

次に、入力焦点の内容が修正可能エントリーアレイ中に
コピーされたかどうかについてチェックを行う。もし入
力焦点の内容がコピーされると、最後の文字を削除する
アルゴリズム部分が呼び出される。さもなければ、入力
焦点の内容は修正可能Token.Entryアレイ内へコピーさ
れる。このプロセスにおける最初のステップは入力焦点
内のテキストのアドレスを修正可能エントリーアレイの
アドレスを取替えることである。さて、アルゴリズムは
進行して文字を削除する。

いったん入力焦点の内容が修正可能Token.Entryアレイ
にコピーされると、アレイ内の最後の内容を担うエント
リーを位置指定することによってバックスペースアルゴ
リズムが開始される。内容を担うエントリーは、Change
BaseバリアントではないToken.Entryである。アルゴリ
ズムは、最後のアレイエレメントと共に開始され、それ
ぞれのエレメントを点検しながら後方へ進む。このプロ
セスは最初の内容を担うエントリーが位置指定されたと
き終了する。そのエントリーが、spaceescapeToken.Ent
ryであれば、トークンアレイは一つだけ短くなりスペー
スを削除する。その後、アルゴリズムは一文字が削除さ
れたために終了する。同様にして、内容を担うエントリ
ーを求めて走査によりつきとめられたエントリーがspac
eFollowsブールがTRUEにセットされたToken.Entryであ
れば、文字を削除する作業はブールをFALSEにセットす
ることより成る。最後の内容を担うエントリーが除去さ
れずに変更されただけであるから、入力焦点の内容は同
一のままである。

最後のケースは、最後の内容を担うエントリーがTRUEに
セットされたspaceFollowsブールを有しないToken.Entr
yである場合である。最後のトークンに対する属性が既
に修正可能なトークン属性エリア内になければ、内容は
コピーされ、エントリーアレイは更新されてこれを反映
する。内容を担うエントリーは２つのエントリーと取替
えられる。第１のエントリーは、changeBaseescapeToke
n.Entryでベースアドレスをゼロ（修正可能トークン属
性エリア）にセットし、第２のエントリーは、１のオフ
セットを有するToken.Entryである。最後に、入力焦点
の内容の長さは（通常長さを１だけ増分することによっ
て）更新される。

バックスペースアルゴリズムの最終部分は、修正可能エ
ントリーアレイの最終のエレメント修正可能トークン属
性エリアへ（先の操作から）既にコピーされたToken.En
tryであってspaceFollowsブールが既にFALSEである場合
に文字を削除するための手続きである。第１のステップ
は最後の論理文字を除去するためにどれ位多くのバイト
を削除する必要があるかを判断することである。アクセ
ント付きの文字の如き国際文字は１バイトより長いバイ
ト順列で表現できる。もしその結果起こる削除がトーク
ン属性中のバイトを使い尽くさなければ、属性は更新さ
れ、アルゴリズムは終了する。もし削除が区別されたト
ークン属性エリア内でバイトを使い尽さなければ、その
区別されたトークンアレイの長さは１だけ減り、第１の
先行する内容担持エントリーアレイエレメントを求める
手続きが実行される。

バックワード バックワードアルゴリズムの最初の２つのステップはバ
ックスペースアルゴリズムと同一である。即ち、もし挿
入点が入力焦点の左側にあると、次の先行するピース含
有テキストの内容が入力焦点としてセットされ、挿入点
は新たな入力焦点の右側へ移動する。次に、もし入力焦
点の内容が修正可能エントリーアレイ中になければ、内
容は修正可能アレイ中にコピーされ、修正可能エントリ
ーアレイに対する基準点は入力焦点中に配置される。

一たび入力焦点の内容が修正可能エントリーアレイにコ
ピーされると、バックワードアルゴリズムはアレイ内の
最後の内容担持エントリーを配置する。このエントリー
はスペースであってはならない。次に、第２番目の走査
が開始され次の先行スペースもしくは句読点を位置指定
する。走査論理は一ワードが２もしくはそれ以上の連続
するトークンに断片化されるか削除中のトークンがドキ
ュメント内の最初のトークンである可能性を伴うべきで
ある。

いったん逆方向の右境界が識別されると、続くトークン
の全ては修正可能トークンアレイの長さを調節すること
によって削除される。バックワードアルゴリズムは常に
整数のトークンを除去するため新たなトークンはつくり
だされない点に注意されたい。

挿入 挿入アルゴリズムも修正可能エントリーアレイを必要と
するため、挿入アルゴリズムもまた入力焦点からどんな
内容が特別なエントリーアレイ中に移動されなければな
らないかを判断することから開始される。もし挿入点が
入力焦点の左側にあれば、新たなピーステーブルエント
リーがつくりだされなければならず、入力焦点に先立っ
てテーブル内へリンクされる必要がある。新たなピース
は今度は入力焦点とされ、挿入点はこのピースの右側へ
移動する。

もし挿入点が入力焦点の右側にあり、入力焦点の内容が
修正可能エントリーアレイ内になければ、入力焦点の内
容はそこでコピーされ、修正可能エントリーアレイに対
する基準点は入力焦点内に配置される。

さて、一文字をドキュメントに追加することできる。実
行される論理は文字の種別による。基本的な類別はスペ
ース、文字、および句読点である。句読点は１トークン
中には決して含まれない文字である。これらはまた改行
アルゴリズムに識別されてそれがどこに許される区切り
点があるかを判断する上で助力する。金融テキスト処理
業務のように相当量の数値データが予期されるような用
途では、数値データを特殊な形で処理する必要がある。
数字は一義的、もしくは殆んど一義的なものとなりがち
であるから、このテキストをテキストにとって高度に効
率的なものとする統計上の属性は実現されないであろ
う。その結果、メモリが桁外れの実行時間をもたなけれ
ばならないすこぶる大きなドキュメントとなる可能性が
非常に高い。一つの選択肢は、表データを正規のテキス
トストリングとして取扱うか、数値データを含む特殊な
エスケープバリアントを作りだすことである。最初の文
字に出会った時、入力焦点中の最初のトークンが検査さ
れる。もしそれが修正可能トークン属性に対する基準点
でなければ、それはピース末に追加される。これは通
常、入力焦点の内容を２だけ長くすることを伴う。修正
可能トークン属性を含むスペースを照会するchangeBase
エスケープバリアントが追加されてその後に修正可能属
性を参照するToken.Entryが続く。メトリックス（metri
cs）、区切り点データ、ディスプレイビットマップ、お
よび文字アレイは全て零値に初期化される。もし、アレ
イ中の最終エントリーがspaceFollowsブールがFALSEに
セットされたトークンバリアントであれば、エントリー
は修正可能トークン属性に対する参照に必要とされる２
つのエントリーと取替えられる。この場合、修正可能属
性の内容は初期化されて取替えられたトークンの内容と
なる。

さて、文字が文字アレイに追加されて、フォントメトリ
ックスとビットマップの再計算を強制する値にセットさ
れる。全体として、新しいテキストのハイフン分割はハ
ードウエアが非常に高速でない限り区切り文字（即ち、
スペースもしくは句読点）に出会うまで遅らせることが
望ましい。

第２の文字とそれに続く（隣接）文字の処理は第１の文
字の処理に必要とされるものの最終ステップだけから成
る。即ち、文字は文字アレイに追加され、トークン属性
中のフォントフィールドはinvalidPropsを改行アルゴリ
ズムから復帰させる特定値にセットされる。

英文字（letter）ではない漢字等の英文字以外の文字
（character）が１つもしくはそれ以上の英文字（lette
rs）の後に入力されるか、入力操作が終了すると、修正
可能なトークン属性の内容は永久トークンに変換され
る。新たなトークンは修正可能トークン属性前には最後
のトークンと同じベースアドレスを有しないかもしれな
いから、changeBaseエスケープは必要かもしれない。

もし、修正可能トークン属性に対する入力を終了させる
事象がスペースであれば、そのスペースは新トークン中
のspaceFollowsブールと共にコーディングする必要があ
る。もし、スペースが入力されても修正可能トークン内
に文字が存在しない場合には、スペースエスケープバリ
アントを使用する必要がある。同様にして、もし１つも
しくはそれ以上の文字が入力された後に句読点が入力さ
れると、修正可能トークン属性は句読点を処理する前に
永久属性へ変換する必要がある。

サーチアルゴリズム 全体として、ユーザは２つのストリングが同等であるか
どうかをアルゴリズムが判断するだろうという期待をも
ってテキストストリングをサーチする。同等であるとは
１ストリングに対するコーディングが情報を喪失せずに
他のストリングのコーディングへ変換できるということ
を意味するものと定義される。同様にして、テキストと
命令の組合せをサーチする場合、命令の順序とは無関係
に命令の意味を理解できるものと予期される。例えば、
もしボールド体のテキストを開始する命令が、〈BD〉で
あって、イタリック体テキストの命令が、〈IT〉である
とき、命令の順序が、 〈BD〉〈IT〉 である時のテキストに対する影響は、 〈IT〉〈BD〉 と同じである。

それ故、２つはサーチによって同等であると解釈さるべ
きである。概念上はこのことは命令をバッファ内に集積
してそれらを各テキストピースの開始前に点検すること
と等しい。

トークンの同等性は直観的なものである。即ち多数の連
続トークン間で分割されたワードは、１トークンとして
表示された同じ内容とマッチしなければならない。次の
アルゴリズムは等価トークンの形で提示されよう。同様
に、一連の命令の等価なコーディングも当然である。か
くして、フォーマット命令が有意義（即ちサーチ系列が
サーチ基準内に含まれている）である場合のサーチ用ア
ルゴリズムは命令順序からは独立している。

サーチは３つの特殊類別を処理することから成る。即
ち、最初のデリミッタに先行する等価トークン、最後の
デリミタ（区切り符号）後の等価トークン、および残り
のトークンの３つである。この前後関係において、デリ
ミタはスペースもしくは句読点と定義される。走査は第
１のトークンに正確に等しいトークンもしくはテキスト
内の終りが識別されるまで続行される。アルゴリズムは
今度はそれぞれのデリミタと内部トークンを処理する。
もし突合せが正確ならば、走査は続行される。最後に、
最後のトークンが比較される。もしサーチ系列内の最後
の等価トークンがサーチ中のテキストの一節内の対応す
るトークンと完全に一致していれば、整合が確認され
る。同様にして、もし最後の等価トークンがテキスト内
の対応するトークンの開始とマッチすれば、そのサーチ
は正確である。

ターゲット系列中のフォーマット命令が有意義であれば
サーチアルゴリズムを定義する必要がある。走査前に、
ソースのストリングはトークンに変換され、有効命令が
判断される。各テキストピースの初めに、有効命令の状
態はソースストリング中の対応する命令と比較される。
もし有効命令がマッチしなければ比較は失敗である。

サーチ（検索）と置換 サーチと置換機能は先に定義した編集操作によって定義
される。まづ、ソースストリングと置換ストリングはト
ークン系列に変換される。その後、ドキュメントの走査
が実行される。突合せが行われる時、ドキュメントの突
合された部分は含意セレクションに変換される。セレク
ションはその後、先に定義した操作を用いて削除され
る。コーディングされた置換ストリングはその後、挿入
点で挿入される。その後走査が進められ次の突合せをつ
きとめる。

スペルチェック この方法によってコーディングされたドキュメントにお
けるテキストのスペルをチェックするためのアルゴリズ
ムはすこぶる効率的である。ドキュメント全体がチェッ
クされるのか、それともドキュメントの選択部分のみが
チェックされるのかに応じて考慮すべき２つの場合があ
る。ドキュメントを処理する前に、２つの一時的データ
構造がつくりだされる。第１のものはそれぞれの一意的
トークンに対してエレメントを有するリストである。各
エレメントは基準カウントとブールフィールドを含む。
エレメントはそれぞれの基準カウントとFALSE値と共に
初期化される。第２のものは１つ以上のトークンより成
るミススペル語をそれぞれ保持するためのリストであ
る。このリストは最初は空白である。

ドキュメントの処理はドキュメントトークン辞書中の各
エントリーをスペリング辞書に照してチェックすること
から始まる。次に処理は一時リスト内の適当なブールフ
ィールドをスペリング辞書によってミススペルと識別さ
れたトークンについてTRUEにセットする操作へ進む。ド
キュメントは今度は幾つかの連続トークンより成るワー
ドについて走査される。複合トークンの各例については
複合中の各トークンに対する一時的基準カウントが減分
された後、ワードはスペリング辞書に照らしてチェック
される。もしワードの綴りが不正確であれば、そのワー
ドはミススペルリストへ追加される。（リスト中に既に
存在しない場合）ドキュメント末にはミススペルの複合
語のリスト中のワードがユーザに報告される。同様にし
て、ミススペルとしてマーキングされ非常の一時的基準
カウントを有するトークン辞典エントリーもユーザに報
告される。

テキストの一部をチェックする第２の場合にはミススペ
ルされたワードを含むリストだけしか必要でない。同処
理は各ワードをそれが幾つかの断片より構成されている
か否かを選択されたテキスト中より列挙して、その語を
スペリング辞書に照してチェックすることより成る、ミ
ススペルされたワードはミススペルリストに加えられ
る。最後のトークンが確認された後そのミススペルリス
トはユーザに報告される。

外部ドキュメント表示 ここに述べるテキスト表示はピーステーブルと相俟って
すこぶるコンパクトな機械読取可能な外部形式として使
用することができる。外部記憶の必要条件を最小限にす
ることはピーステーブルと、ピーステーブルが参照する
Token.Entryアレイを含むメモリと、トークン属性の副
集合を節約することより成る。迅速に再計算できないト
ークン属性部分のみをファイル中に書込む必要がある。
かくして文字、各区切り点の型と位置を記すアレイ、お
よび属性のベースアドレスとオフセットだけで十分であ
る。区切り点アレイ、計測情報およびトークンビットマ
ップ映像を格納しないことによって属性スペースは少な
くとも3/4だけ減らすことができる。

典型的な場合、大きなドキュメントの場合、ドキュメン
ト中の平均ワード長の逆数の２倍に収斂する程にコンパ
クトになる。標準的な英語の場合、その比は３分の１よ
りも若干小さい。多数の長いワードを含む技術ドキュメ
ントの場合その比は大きくなろう。

〔発明の効果〕

本発明によるテキストコーディング方法によれば、従来
のテキストコーディング方法において見られた膨大なワ
ード数を収容した辞書を、大きく減少（すなわち辞書を
相当に圧縮）させている。そして、テキストを再構成し
てページ毎に適正な行幅で成るようにする（すなわちペ
ージ付け処理）場合においても、従来の方法では、各ワ
ード毎にビットマップと他の特性について記憶せねばな
らず、これが大きな容量のメモリを要求していたが、本
発明では、上記のように、辞書が常時極めて小さくメモ
リの容量も小さくて済む。更に、このことは、LAN等に
よって、あるユーザから他のユーザにテキストが転送さ
れる場合、辞書とともにデータを転送したとしても、辞
書の容量が小さいので、従来のものよりはるかに高速で
転送できる。

以上、本発明を特定の実施例について説明してきたが、
当業者には各種の変更を施こし、本発明の真の精神と範
囲より逸脱せずにその諸要素と代替できることが理解で
きよう。更に、本発明の本質的思想から逸脱せずに多く
の変形を施こすことも可能である。

【図面の簡単な説明】 第１図は、メサプログラミング言語で書かれたトークン
データ構造を定義するソースファイルを示す図、 第２図（ａ）〜（ｃ）は、第１図で定義されたデータ構
造を用いて第４図中のテキストのコーディングの過程を
示す図、 第３図は、メサプログラミング言語で書かれたトークン
属性を表わすためのデータ構造を規定するソースファイ
ルを示す図、 第４図は、第１図〜第３図の例に使用したサンプルテキ
ストの一節を示す図、 第５図（ａ）及び（ｂ）は、メサプログラミング言語で
書かれ、トークンとしてコーディングされたテキストを
処理する改行アルゴリズムを定義するソースファイルを
示す図、 第６図（ａ）〜（ｄ）は、メサプログラミング言語で書
かれ、トークンとしてコーディングされたテキストの改
行について改行アルゴリズムを実行するためのソースフ
ァイルを示す図、 第７図（ａ）〜（ｈ）は、Ｃプログラミング言語で書か
れた、テーブル６のメサソースコードの等価なものを示
す図、 第８図は、第４図のテキストの最初の３行について第６
図で定義されたアルゴリズムの結果を示す図、 第９図は、第15図で選択されたテキストが削除された後
に残る第８図中のコーディングテキストの最初の断片を
示す図、 第10図は、第15図中で選択されたテキストが削除された
後に残る第２図のコーディングテキストの最終の断片部
分を示す図、 第11図は、区切り点を有しないトークンについて第３図
に規定されたトークン属性のメモリレイアウトを示す
図、 第12図は、２つの区切り点を有するトークンについて第
３図に規定されたトークン属性のメモリレイアウトを示
す図、 第13図は、第３図のデータ構造のディスプレイビットマ
ップ部分を規定するパラメータを示す図、 第14図は、テキストが第４図のものである場合の、ハイ
フン分割が許可された時にトークンが処理される手順を
示す図、 第15図は、セレクションを表示するためにテキストの一
部をハイライトさせた第４図中のテキストを示す図であ
る。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｇ０６Ｆ 17/27 9288−5Ｌ Ｇ０６Ｆ 15/20 ５５４ Ｈ 9288−5Ｌ ５９２ Ｅ 9288−5Ｌ ５９２ Ｆ (56)参考文献 特開 昭61−242122（ＪＰ，Ａ) 特開 昭62−256070（ＪＰ，Ａ)

Claims (4)

【特許請求の範囲】
1. 【請求項１】各々が１つ若しくはそれ以上の文字コード
   で構成されるアトムのストリングから構成されるテキス
   トをメモリに受取り該テキストをコーディングし、行に
   区切る方法であって、前記アトムのストリングが、ある
   時間において、複数の前アトムと１つの現在アトムと１
   つの次アトムを含んでおり、該アトムのストリングは、
   文字、数字、句読点記号及びスペースのストリングから
   なる複数のワードから構成されて、トークンのリスト及
   び対応するデータブロックのアレイとして前記メモリに
   記憶されており、前記アトムのストリングを、プリンタ
   での印刷に適する所定の長さで成る一連の行に区切るこ
   とを含み、それらの行は、複数の前の行と区切られつつ
   ある現在の行と１つの次の行とを含んでいるテキストコ
   ーディング方法において、 前記メモリを、ゼロのデータブロックとゼロのトークン
   のリストを用いて開始することによってイニシャライズ
   し、その後、以下のステップの反復によって前記リスト
   及びアレイの全体を作っており、該ステップは、 前記アトムのストリング内の現在アトムが該ストリング
   内の１つの前アトムと同じかどうかを判定し、 もしそうならば、前記の前アトムのトークンと同じトー
   クンを、前記メモリのトークンのリストの最後に加え
   て、前記次アトムに進み、 前記現在アトムが前記前アトムと同じでないならば、１
   つの新トークンを前記メモリのトークンのリストの最後
   に加え、該新トークンに対応して、前記メモリ内に、前
   記現在アトムの文字ストリングと前記アトムの幅を含む
   データブロックを追加し、次のアトムに進むことによっ
   てテキストをコーディングを終了し、 上記コーディングの終了後において、前記行に区切るス
   テップが、 各アトムの幅を当該アトムに対応するデータブロックに
   追加することによってトークンのリストとデータブロッ
   クのアレイとを発生し、 現在アトムのトークンを用いて、対応するデータブロッ
   クにアクセスし、 そのデータブロック内の現在アトムの幅を、現在の行に
   おけるアトム幅の合計に加算して、現在の行の全アトム
   の総計の幅を決定し、 もし、前記総計幅が前記所定の行長さより大きければ、 前記前アトムがスペースである場合、該前アトムの後の
   行部分を区切り、 前記前アトムがスペースでなければ、現在行の、スペー
   スの直前のアトムの後の行部分を区切り、 もし、上記総計幅が前記所定の行長さ以下であれば、次
   の行に進み、 このようにして作られた一連の行をプリンタに送る から成ることを特徴とするテキストコーディング方法。
2. 【請求項２】前記文字が、型、サイズ、ウエート及びス
   トレス（強勢）、大文字化を有し、２つのアトムが、同
   じ型、サイズ、ウエート及びストレス（強勢）、大文字
   化を有するとき、その２つのアトムを同一として定める
   ことを特徴とする請求項１に記載の方法。
3. 【請求項３】２以上の音節から成る各ワードが、１つ若
   しくはそれ以上の開始部分ワードと１つ若しくはそれ以
   上の終了部分ワードとをハイフン分割点で分割して成る
   部分ワードに分割されており、１ワードに対応する各デ
   ータブロック毎に、前記ワードの前記ハイフン分割点と
   各部分ワードの幅とを前記データブロックに加えること
   を特徴とする請求項１に記載の方法。
4. 【請求項４】前記アトムのストリングを、プリンタでの
   印刷に適する所定の長さで成る一連の行に区切ることを
   含み、それらの行は、複数の前の行と区切られつつある
   現在の行と１つの次の行とを含んでいる請求項３に記載
   の方法において、 （ａ）現在アトムのトークンを用いて、対応するデータ
   ブロックにアクセスし、 （ｂ）そのデータブロック内の現在アトムの幅を、現在
   の行におけるアトム幅の合計に加算して、現在の行の全
   アトムの総計の幅を決定し、 （ｃ）もし、前記アトム幅合計が前記所定の値以下であ
   れば、次アトムのトークンに進み、 （ｄ）もし、前記幅合計が、所定量より小さい量だけ前
   記所定値よりも大きければ、現在アトムの終わり部分で
   行を区切って、次アトムのトークンに進み、 （ｅ）もし、前記幅合計が前記所定量だけ前記所定値よ
   りも大きく且つ現在アトムがハイフン分割されたワード
   であるならば、前記ハイフン分割されたワードをそのハ
   イフン分割点において分割し、該ハイフン分割ワードの
   開始部分ワードを現在行の終了部分に加え、次の行を前
   記現在ワードの終了部分ワードより開始することから成
   ることを特徴とする方法。