JP2534324B2 - 処理システム - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明はデータ処理システムにおける表示装置や印刷
装置などの出力装置上での図形記号（graphic symbol）
の表示に関し、さらに具体的には、表示される図形記号
を表わすデータ・ストリームを解析するための技術に関
するものである。

B.従来技術及び問題点 単色表示装置を有するIBM RT PC等の処理システムで
は、表示管理プログラムが単色表示装置への出力を制御
する。処理システム内の表示管理プログラムは、固定さ
れた構文ないしは構文法（syntax）を使って、表示装置
に送られるデータ・ストリームを解釈する。処理システ
ム内の文字発生機構がこの固定構文に従って英数字を表
示装置で表示する。この種のシステムでは、データ・ス
トリームの解釈に使用される構文を変更する方法も、文
字発生機構によって作成される表示英数字の表現を変更
する方法もなく、表示装置上の表現は、表示管理プログ
ラムに別のデータ・ストリームを送ることによってしか
変更できない。

同様に、全点アドレス可能（APA）表示装置では、デ
ータ・ストリームは表示管理プログラムに入り、そこで
表示管理プログラムの固定構文によって復号される。し
かし、表示管理プログラムで処理された後、データ・ス
トリームは種々の交換可能フォントを使って、種々の方
法で表示することが可能である。ユーザは、データ・ス
トリームを表示するためにどのフォントを使用するかを
指定することができる。これらの種々のフォントを使っ
て、ユーザはイタリックやボールドフェース等の様々な
書体または様々な寸法あるいはその両方を表示すること
ができる。その他の種々の表示可能なアスペクトも変換
することができる。この時点で、フォントは変更される
ので、特定のデータ・ストリーム内のコード点の解釈を
変更することができる。

たとえば、コード点16進数41が“A"である場合（米国
規格協会（ANSI）から公表されたASCII（情報交換用米
国標準コード）標準ではそう定義されている）、単色表
示装置では、それは“A"として表示されるだけでなく、
“A"の特定の具体的表現である。これは、特定の寸法、
傾斜及びデザインを有する“A"である。“A"を表わす特
定の画素が活動化され、それを変更することはできな
い。

APA表示装置で交換可能フォントを使用することによ
り、コード点16進数41を、イタリック、ボールド、また
は異なる寸法等の異なるデザインの“A"に変更すること
ができる。さらに、まったく異なるフォントを選択する
ことにより、コード点16進数41が“A"ではなく、別の図
形記号であるとユーザが決めることもできる。

データ・ストリームは、すべてが一定のビット幅であ
るようなコード点で構成される。標準のASCIIで使用で
き、かつ本発明の説明で使用されるビット幅は８ビット
であるが、16ビット、32ビット等その他のビット幅を使
用することもできる。データ・ストリームを構成する各
バイトはコード点と呼ばれる。１バイトは８ビットから
成るので、０−255の256個のコード点がある。これらの
256個のコード点により、256種の異なる表示可能記号を
表現することができる。

「図形記号」という用語は、通常の英数字及びその他
の記号を含む。表示可能な図形記号は「グリフ（glyp
h）」と呼ばれる。一組の図形記号のためのこれら256個
のコード点の実例を第1A図に示す。しあし、256個のコ
ードがすべて表示可能図形記号に使用されるわけではな
い。

第1A図に示すように、コード・ページ“P0"100の最初
の32個のコード点101−132は制御コード15用に使われ
る。制御コード15は図形コード17とは異なる。データ・
ストリーム内に埋め込まれた制御コードの中には、表示
装置または印刷装置の出力における表示可能コードの形
式に影響を及ぼすものがある。バックスペース、水平タ
ブ、改行、垂直タブ、用紙送り、キャリッジ・リター
ン、シフトアウト、シフトイン、エスケープ等の制御コ
ードが、ANSI標準制御形式パラメータとして挙げられて
いる。エスケープは、エスケープ、すなわち、複数バイ
ト・シーケンスである制御シーケンスを開始するので、
重要な制御コードである。エスケープは、やはりANSI標
準で通常の方法で定義される、より長い制御シーケンス
の開始を指定する。

肯定応答、否定応答、同期、取消し、ヘッダ開始、ヘ
ッダ終了等の通信制御コードもある。すべての制御コー
ドが処理システムの様々な製造業者によってサポートさ
れているわけではない。どのコード点が制御コードであ
るかが分からないと、データ・ストリームを適切に解釈
し、形式化することはできない。

その他の制御コードはコード・ページ・シフト制御コ
ート115、116、129−132（第1A図）と呼ばれる。処理シ
ステムが、256種を超える記号のうち制御コード用に必
要とされるコード点以外のものを表示する能力をもつ場
合、ある処理システムに対してある表示記号の範囲があ
る。一般に、フルレンジの表示すべき記号はコード・ペ
ージ、すなわち、256種の記号からなる範囲に分割され
る。その場合、それらの様々なコード・ページにアクセ
スするために、コード・ページ・シフタが必要となる。

コード・ページとはコード点の集まりである。１つの
コード・ページは通常、256個から成る１組のコード点
を表わす。たとえば、最初のコード・ページでは、16進
数41は“A"となっている。別のコード・ページでは、16
進数41は“％”となっている。本発明の説明では、第1A
図、第1B図及び第1C図に示すような多少変更した標準AS
CIIコード・ページを参照する。

第1A図、第1B図及び第1C図は３つのコード・ページを
示す。コード点16進数00ないし16進数1Fは、この３つの
コード・ページのどのページでも制御コードである。す
なわち、これらのコード点はコード・ページの理解とは
関係ない。これらのコード点は、どのコード・ページが
使用されているかにかかわらず、制御点である。

RTASCIIと呼ばれる、RT PCで使用されるASCII標準の
１バージョンでは、コード・ページをシフトすることが
可能である。コード・ページをシフトすると256種を超
える表示可能コードが使用できるようになるので、別の
コード・ページにシフトするための方法が定義された。
標準のRTASCIIでは、コード・ページ“P0"100（第1A
図）及びコード・ページ“P1"150（第1B図）をセットア
ップする複数バイトの制御コードをデータ・ストリーム
で送る方法が採用された。これらのエスケープ列で、異
なる２つの論理スロットがロードされる。たとえば、
“G0"論理スロットの場合は、“P0"コード・ページが使
用されることになる。“G1"論理スロットの場合は、“P
1"コード・ページが使用されることになる。これらのコ
ード・ページがこの複数バイト制御コードによってロー
ドされると、ユーザは、第1A図の16進位置“0E"及び“0
F"にある単一バイトの制御コードである、シフトイン・
コード116（第1A図）またはシフトアウト・コード115
（第1A図）を使用することができる。そのとき、シフト
アウト・コード115がデータ・ストリームで使用された
場合は、第２のコード・ページが使用されることにな
る。その場合、後続のコード点は、シフトイン・コード
116で最初のコード・ページに戻るまで、この第２のコ
ード・ページを参照する。後続のシフト・コードが送ら
れるまで、後続のコード点は次のコード・ページにロッ
クされるので、これをロッキング・シフトと呼ぶ。

たとえば、コード点16進数61、62、63がデータ・スト
リームで送られた場合、それらは省略時コード・ページ
“P0"100（第1A図）に入るように定義され、それぞれ図
形記号“a"141、“b"142及び“c"143で表わされること
になる。シフトアウト・コード115を受け取った場合
は、次の256種（ただし32種の制御コードを差し引く）
の記号を含むP1 150（第1B図）コード・ページに進むも
のと考えられることになる。この場合にデータ・ストリ
ーム中のシフトアウト・コード115の後にコード点16進
数61、62、63がくると、記号151、152、153（第1B図）
が表わされることになる。

コード・ページをシフトするためのもう１つの方法
は、非ロッキング・シフトまたはシングル・シフトと呼
ばれる。シングル・シフトは“SS1"132、“SS2"131、
“SS3"130、及び“SS4"129である。これらのコードを受
け取ったときは、次の８ビットだけが指定されたコード
・ページで解釈される。別のコード・ページがアクセス
されるのは次の８ビットについてだけであり、その後、
元のコード・ページが再度使用される。

非ロッキング・シフトでは、一般に、大部分の時間、
１つのコード・ページだけが使用される。第２のコード
・ページが使用されるのは１つの記号についてだけであ
る。たとえば、方程式を含むテキストでは、その式中に
第２のコード・ページに現われる記号が含まれることが
ある。そのときだけしか、そのテキスト文書中でその記
号が使用されない場合もある。最初のコード・ページか
らシフトアウトして第２のコード・ページにシフトイン
し、次に最初のコード・ページに再びシフトインするよ
りも、データ・ストリームを続行し、“SS1"制御コード
点16進数1Fを使って別の表示記号の範囲にアクセスする
方が効率的である。非ロッキング・シフトは、次の８ビ
ットを調べるよう表示管理プログラムに命じる。それら
次の８ビットは、“SS1"によって定義されるコード・ペ
ージによって表示できる。その後で、表示管理プログラ
ムは次の８ビットを求めて元のコード・ページに戻る。

シングル・シフト“SS1"ないし“SS4"は、16進数1Cな
いし1Fである。16進数1Cないし1Fは16進数20よりも小さ
いので、処理システムは、それらが制御コードであり、
表示可能コードではないことがわかる。これらの４種類
のシングル・シフト・コードを使うとき、表示管理プロ
グラムは、それらがシングル・シフト・コードであるこ
とがわかっている。表示管理プログラムは、それらがシ
フタ・コードであることだけでなく、それらのコードが
どこにシフトするかが正確にわかっている。表示管理プ
ログラムは、特定のコードが基本点256または128、また
は必要となるどの点をも別のコード・ページにシフトす
ることがわかっている。構文知識が表示管理プログラム
に含まれているというのは、こういう意味である。

ロッキング・シフト及びシングル・シフトは、256種
よりも多い表示可能記号にアクセスするための、RTASCI
Iで定義された２つの方法である。どちらの方法でも、
表示管理プログラムは、コード・ページ・シフタ115、1
16、129、130、131、132用に使用される所定のコードを
認識しなければならない。表示管理プログラムは、入り
データ・ストリーム中の各バイトを検査し、それが表示
可能な図形記号である場合は、フォント・ファイル内の
そのコードに対するフォント・パターンに応じた図形記
号を表示する。表示管理プログラムは、複数バイトの制
御コード・シーケンスをも、それを別のコード・ページ
にシフトさせる様々な種類の単一バイトの制御コードを
も知っている。

たとえば、データ・ストリーム中で16進コード1Fを受
け取った場合、16進数1Fは単１バイトのコード・ページ
・シフタ“SS1"132（第1A図）なので、表示可能でない
ことが表示管理プログラムにはわかっている。したがっ
て、そのフォントはアクセスされない。表示管理プログ
ラムは、コード・ページ・シフトがあったという事実を
記憶している。表示管理プログラムは、次のコード点に
よってアクセスされる表示記号の範囲の始めを指す基本
ポインタを調節する。次のコード点は正しい処理を行な
うためには、図形コードでなければならない。次の図形
コードはこの基本ポインタからのオフセット（ずれ）と
なる。

当技術で周知の第２図の処理システム25は、IBM RT P
Cである。RT PCについての詳しい情報は、“IBM RTパー
ソナル・コンピューター概説書（IBM RT Personal Comp
uter:General Information）”、資料番号GC23−0783−
１に記載されている。アプリケーション21を実行する処
理システム25は、AIX（IBM社の商標）等のオペレーティ
ング・システム22を格納している。

AIXオペレーティング・システムについての詳しい情
報は、“IBM RTパーソナル・コンピュータ:AIXオペレー
ティング・システム技術解説書（IBM RT Personal Comp
uter:AIX Operating System Technical Referenc
e）”、資料番号SC23−0808−０に記載されている。表
示画面23の表示は、表示管理プログラム28によって制御
される。表示管理プログラム28は、画面23に表示するた
め、オペレーティング・システム22、キーボード26、ま
たはアプリケーション21から入力を受け取ることができ
る。

データ・ストリームに対する処理モデルを表わすた
め、従来、処理システム25は、処理システムの製造業者
によってあらかじめハード・コード化、すなわち、実行
可能コードでプログラミングされていた。処理モデルと
いう用語は、当技術分野では、データ・ストリーム中の
どのバイトが図形記号を表わし、どのバイトがコード・
ページ・シフタ等の制御コードを表わすかを定義する一
組の規則を意味するものとして使用されている。処理モ
デル18を使うと、実質的に、処理システムが特定のコー
ド・セットについて図形コードを制御コードから区別す
ることができる。そのために、通常、表示管理プログラ
ム中で、表示管理プログラム28に送られたデータ・スト
リームに関してハード・コードの形で仮定を行なってい
た。

たとえば、RTASCII等、ASCIIから導かれた特定の標準
データ・ストリームについて、16進コード1C、1D、1E、
1Fをコード・ページ・シフタとして指定することができ
る。表示管理プログラム内の処理モデルは、データ・ス
トリーム内の各バイトを検査して、それがこれら４つの
ページ・シフト用の制御コードの１つであるかどうか調
べる。

データ・ストリームに対して別の標準が使用された場
合は、これら４つの16進コードはもはやページ・シフト
用の制御コードを表わさず、別のコードがコード・ペー
ジ・シフタと見なされることもあるはずである。したが
って、表示管理プログラムは、どのコードが制御コード
であり、どのコードが図形記号であるかを判定するの
に、前の処理モデルを使用することができなかった。

たとえば、日本語は6000を超える図形記号を含み、ま
ったく複雑である。したがって、５つ以上のページ・シ
フタが必要となる。シフタが４つある場合は、４つの異
なるコード・ページを指す基本ポインタにぶつかること
があり得る。6000を超える表示可能コードが256個ずつ
の単位に分かれている場合、多数の異なる256個の単位
にアクセスするにはさらに多数のシフタが必要となる。
したがって、シフトJISと呼ばれる日本工業規格（JIS）
の１バージョンでは、その複雑な言語をサポートするた
めに、RTASCII標準とは異なる別の制御コードが設けら
れている。

日本語は、ローマ字、表音字母である片仮名と平仮
名、また表意文字である漢字で表わすことができる。シ
フトJIS規格は、日本語を表わすのに使用される6000を
超える図形記号用の日本語の図形文字セット及びコード
・ページについて記述している。シフトJIS規格は、「I
BM登録図形文字セット及びコード・ページ（IBM Regist
ry Graphics Characters Sets and Code Pages）」、資
料番号Ｃ−H3−3220−050、及び「IBM日本語図形文字セ
ット、漢字（IBM Japanese Graphic Character Set、Ka
nji）」、資料番号Ｃ−H3−3220−024と題する刊行物に
さらに詳しく記載されている。

これら２つのコード・ページ・システムであるRTASCI
IとシフトJISは互換性がない。それぞれのコード・ペー
ジでページ・シフタが同じでないので、これらのコード
・ページ・システムは互換性がない。シフトJISのコー
ド・ページ170（第７図）では、他の標準コード・ペー
ジで図形記号17がある所に、制御コード15がある。たと
えば、シフトJIS（第７図）の16進コード81ないし19Fは
コード・ページ・シフタであり、表示可能な文字ではな
い。NLS（National Language Support）データ・ストリ
ーム用に使用されるRTASCII（第1A図、第1B図、第1C
図）では、同じそれらのコードが表示可能な記号であ
る。したがって、RTASCIIの構文を理解する表示管理プ
ログラムは、シフトJISのデータ・ストリームを与えら
れた場合、それらの文字を表示しようと試みることにな
る。これらの２つの言語はそれぞれ異なるデータ・スト
リーム構文を有するので、その結果、エラーを生じるこ
とになる。したがって、シフトJISのコード・ページ
は、第1A図、第1B図及び第1C図のコード・ページと互換
性がない。

１つの方法は、RTASCII NLSの処理システムとは別の
シフトJIS用の処理システムを組み立てることである。
別々の処理システムが必要となるのは、それぞれのコー
ド・ページを理解し、各マシンで様々なコード点のどれ
が制御コード・シフタであるか、また各コード・シフタ
が基本ポインタをどれだけシフトするのかを理解するた
めである。

JISやNLS等、異なるコードまたは追加のコードを有す
る種々のデータ・ストリーム構文を処理するには、新た
に指定された制御コードがあるかどうかをこのとき検査
できるように、表示管理プログラムをコード化し直さな
ければならない。言い換えれば、新しい処理モデルを作
成しなければならない。したがって、異なるコード・セ
ット表現を有する異なるデータ・ストリームに対して、
同じハード・コード化（プログラム式）表示管理プログ
ラムを使用することはできない。

ユーザが最初のデータ・ストリーム標準または第２の
データ・ストリーム標準を選択することが可能な処理シ
ステムを、処理システム製造業者がその客先に提供する
ことは当技術では周知である。この場合、製造業者は２
つの異なる処理モデルに対して２つの方式で表示管理プ
ログラムをプログラミングしている。ユーザが最初の標
準を選択した場合は、表示管理プログラムは、最初の処
理モデルを表わす最初のプログラム式ルーチンを呼び出
す。ユーザが第２の標準を選択した場合は、表示管理プ
ログラムは、第２の処理モデルを表わす第２のプログラ
ム式ルーチンを呼び出す。

この方法はその有用性に限界がある。第１に、ユー
ザ、すなわち客先は、製造業者があらかじめ選択したデ
ータ・ストリーム標準だけに制限され、表示管理プログ
ラムは、その標準に対して、選択されたデータ・ストリ
ーム標準に対する特定の処理モデルの要件を満たすよう
にコード化されている。第２に、ユーザは、一度に１つ
の標準またはコード・セットを使用するデータ・ストリ
ームしか表示のために送ることができない。たとえば、
第１のコード・セットがシフト・コード・ページとして
16進コード1Cないし1Fを有し、第２のコード・セットが
シフト・コード・ページとして16進コード81ないし9Fを
有する場合、表示管理プログラムはこれらのコード・セ
ットからの表示可能記号を同時に混用することができな
いことになる。

したがって、本発明の目的は、１つの処理モデルを、
異なる構文を有する異なるデータ・ストリームに適合さ
せることである。

本発明のその他の目的は、処理システム製造業者が特
定の構文の処理モデルを用いて表示管理プログラムをハ
ード・コード化する必要をなくすことである。

本発明のその他の目的は、処理システム製造業者によ
ってあらかじめ提供されていないコード・セット及び構
文に対してユーザがアクセスできるようにすることであ
る。

本発明のその他の目的は、異なるコード・セットから
の図形記号を同時に表示することである。

C.問題点を解決するための手段 この目的を達成するために、本発明によれば、特定の
構文を有するデータ・ストリームから図形記号を表示す
るための処理システムは、フォント・ファイルと、前記
データ・ストリーム中のどのバイトが表示すべき図形記
号コードを表し、どのバイトが前記データ・ストリーム
内の次の順次的バイトに対する修飾子を示す制御コード
を表すかを定義する１組の規則を含む処理モデルを前記
フォント・ファイル中に組み込むように前記フォント・
ファイルを構造化する手段を含む。そして前記構造化さ
れたフォント・ファイルは前記データ・ストリームから
制御コードを峻別し且つ前記データ・ストリームから図
形記号コードを峻別する機能を有する。

以下、本発明の作用を実施例とともに説明する。

D.実施例 本発明のシステム及び方法は、処理システムのユーザ
またはアプリケーションが変更できるフォント・ファイ
ル構造に基づいてデータ・ストリームを処理する。フォ
ント・ファイルは、ある範囲の図形記号に対する画素パ
ターンを含むだけでなく、特定の構文を有するデータ・
ストリームを解釈するための規則も含む。あるデータ・
ストリームを解釈するための規則を、そのデータ・スト
リーム用の処理モデルと呼ぶ。

フォント・ファイル構造は、図形記号の範囲を示すイ
ンデックス・アレイを含む。データ・ストリーム内の各
バイトが、インデックス・アレイ内にイッデックスを発
生するために使用される。インデックス・アレイの各要
素は、値及び制御ビットをもつ。制御ビットは、その値
が図形記号に対するオフセットであるか、それとも修飾
子であるかを示す。値が修飾子である場合は、その図形
記号の範囲においてデータ・ストリーム内の次の順次デ
ータ・バイトを増分するためにそれが使用される。修飾
子繰り返し使用して、無制限の数の図形記号にアクセス
することができる。

本発明の処理システムは、JIS、ASCII、及びNLSデー
タ・ストリーム等の種々のデータ・ストリームを同時に
処理する。従来のように、上述のような実行可能コード
を使って特定のデータ・ストリーム処理モデルをもたら
す表示管理プログラムを設けるのではない。データ・ス
トリームの処理モデルは、各言語または構文モデルごと
に当該のフォント・ファイルによって指示される包括的
な処理モデルである。任意のデータ・ストリームに対す
る各フォントは、各フォント内に処理モデルを組み込む
ように個別に構成される。このようにして、処理モデル
はフォントの定義中で暗示されている。

データ・ストリーム内の各バイトが、インデックス・
アレイ内にインデックスを発生するために使用される。
インデックス・アレイの各要素は、１つの値と１組の制
御ビットをもつ。これらの制御ビットは、その値が図形
記号に対するオフセットであるかどうか、またはその値
が修飾子であるかどうかを示す。

さらに詳細には、インデックス・アレイは、データ・
ストリームの処理モデルを指定するために、フォント・
ファイル内で使用される。インデックス・アレイは、そ
の各要素中に制御ビット及び値を含んでいる。制御ビッ
トは、情報が制御情報であるのか、それとも表示すべき
な図形記号に対するオフセットであるのかを示す。制御
ビットの１つはインデックス修飾子ビットと呼ばれる。
インデックス修飾子ビットがオンの場合、その値はイン
デックス修飾子であり、データ・ストリーム内の次のデ
ータ・バイトに適用される。インデックス修飾子は、指
定されたデータ・ストリームに対する所期の処理モデル
に基づいて、選択された量だけ次の順次データ・バイト
を増分する。もう１つの制御ビットは、基本修飾子ビッ
トと呼ばれる。基本修飾子ビットがオンの場合、その値
は基本修飾値であり、アレイ全体に適用される。省略時
には、データ・ストリームによって変更されるまで、基
本修飾値は０である。すべての制御ビットがオフの場
合、その値は、表示すべき図形記号（グリフと呼ばれ
る）に対するオフセットである。したがって、インデッ
クス・アレイは、その各要素中の制御ビットを使って、
データ・ストリーム内の制御バイトをデータ・バイトか
ら動的に区別する。

図形記号に対するオフセットを含むインデックス・ア
レイ内の要素がアクセスされるまで、インデックス修飾
子は累積される。インデックス修飾子を累積することに
より、図形記号に対するオフセットである次のデータ・
バイトを、インデックス・アレイ内の任意の要素から参
照することができる。インデックス修飾子は繰り返し使
用することができるので、こうすると無限の数の図形記
号の使用が可能になる。したがって、ASCII、NLS、及び
6000を超えるコードを必要とするシフトJIS用の256種の
異なったコード・セットの組合せが可能になる。

フォント・テーブルは、表示すべき図形記号に対する
画素パターンを含む他に、データ・ストリームを解釈す
るための構文を備えた処理モデルを含んでいる。したが
って、処理システムのユーザがフォントを選択し変更す
るためにフォントにアクセスできる上に、フォント内の
処理モデルもユーザが選択し変更することができる。フ
ォント・インデックス・アレイ内の任意の要素中の制御
ビットを変更することにより、ユーザは、データ・スト
リーム内のバイトがインデックス内の別の位置に対する
修飾子であるのか、それとも図形記号に対するオフセッ
トであるのかを決定する。したがって、ユーザは自分の
図形記号及びデータ・ストリーム標準を作成し、他のデ
ータ・ストリーム標準を互いに組み合わせ、これらのデ
ータ・ストリームを解釈するための自分の処理モデルを
作成することができる。

第４図を参照すると、本発明のシステムは、データ・
ストリーム30と、表示管理プログラム28と、インデック
ス・アレイ45を含むフォント・ファイル40とを含んでい
る。データ・ストリーム30は、表示管理プログラム28に
送られる16進コードを表わすビット35から構成される。
データ・ストリーム・ビット35が何を意味するか理解す
るための知識は、あらかじめ表示管理プログラム28に入
っている。表示管理プログラム28は、オペレーティング
・システム22の拡張部分である。通常、処理システム20
の製造業者は、表示管理プログラム28をオペレーティン
グ・システム22のソフトウェアと一緒に出荷する。表示
管理プログラム・コードは、ソフトウェア製造業者が一
度に書く。したがって、上述の従来のシステムでは、構
文、すなわち、データ・ストリームを理解するために使
用される編成原理は固定しており、処理システムのユー
ザが変更することはできない。構文は、システム・アー
キテクチャの開発中に処理システム製造業者が決定す
る。

第４図に示す本発明のシステム及び方法では、特定の
データ・ストリームに対する構文は、表示管理プログラ
ム28内の処理モデルとしてはコード化されない。表示管
理プログラム28は、あるコード範囲内のどのコードがコ
ード・ページ・シフタとして使われるかを知る必要がな
い。これらのコード・ページ・シフタはコード範囲内の
どこにあってもよい。こうすると、ASCII標準のコード
・ページを使ってNLSデータ・ストリームを表示するこ
とが可能になると共に、シフトJISコード・ページ・シ
ステムを使って、片仮名、平仮名または漢字を表示する
必要がある日本語ベースのアプリケーションをサポート
することが可能になる。

その代わり、処理モデルはフォント・ファイル40内の
インデックス・アレイ45に組み込まれる。フォント40
は、データ・ストリーム30を翻訳するとき、包括的処理
モデルを指示するために使用される。フォント40は、編
成または処理されたデータ・ストリームが何を意味する
かを定義するために使用される。入力30が出力39にどの
ような形で移される（transpose）かは、表示管理プロ
グラム28に格納されているのではなく、フォント・ファ
イル40内に組み込まれた構文または処理指示によって決
定される。

データ・ストリーム30が表示管理プログラム28に送ら
れるとき、もはや表示管理プログラム28は、データ・ス
トリーム内の各要素35が何を意味するかについて十分な
情報を持っていない。表示管理プログラム28は次に、ユ
ーザから提供されたフォント・ファイル40にアクセスす
る。表示管理プログラム28は、データ・ストリーム30内
の各バイト35をフォント・ファイル40にマップする。フ
ォント・ファイル40は、処理システム20、オペレーティ
ング・システム20、もしくはアプリケーション・プログ
ラム21と一緒に供給される省略時フォント・ファイルで
あることもあり、またはユーザが供給することもある。
あるコード点が図形記号であるか、またはコード・ペー
ジ・シフタであるかを定義するのは、フォント・ファイ
ル40であって表示管理プログラム28ではない。コード点
がコード・ページ・シフタ、すなわち、インデックス修
飾子または基本修飾子である場合は、その表示記号の範
囲内での基本オフセットがそれに応じてシフトされる。
フォント・ファイルは、そのデータ・ストリーム要素、
すなわち、バイト36が表示可能な図形であるかどうか、
またはそれが修飾子であるかどうかを表示管理プログラ
ム28に知らせる。

本発明の処理システム20では、表示管理プログラム28
から構文の知識が取り除かれ、フォント・ファイル40に
移されている。表示管理プログラム28は、データ・スト
リーム30が何を意味するかについて何も仮定を行なわな
い。したがって、構文はハード・コード化されていず、
１度も決定されず、固定されていない。そうではなく
て、表示管理プログラムはフォント・ファイル40を参照
する。フォント・ファイル40は、ユーザまたはアプリケ
ーション・プログラム21によって供給されることもあ
り、またオペレーティング・システム22と一緒に供給さ
れることもある。

本発明では、表示管理プログラム28はデータ・ストリ
ーム30のハード・コード化された処理モデルをもたらさ
ないが、本発明では依然として表示管理プログラム28を
使用する。表示管理プログラム28は依然としてデータ・
ストリーム30の入力を受け取るが、表示管理プログラム
28は、今やフォント・ファイル40の指示に基づいて入力
を処理する。さらに、表示管理プログラム28は、コード
・ページのシフティングを除いて、他のタスクを引き続
き実行する。表示記号の範囲の様々な部分にアクセスす
るためのすべてのコード・ページ・シフティングが今や
フォント・ファイル内で定義される。

本発明の説明ではコード・ページ・シフティング及び
コード・ページという言葉を使っているものの、実際に
は本発明を用いると図形記号の範囲をそれぞれ256種の
コードからなるページに分割する必要、及びこれらのペ
ージ間でシフトする必要がなくなる。反復的修飾子を使
うと、まずある記号の範囲をグループに分割し、グルー
プの１つにアクセスし、次にこの１つのグループ内の記
号にアクセスせずとも、連続した表示記号の範囲内のど
の点にもアクセスすることができる。

表示管理プログラム28は依然としてデータ・ストリー
ム30を管理しているが、データ・ストリームを解釈する
ための知識はもはや表示管理プログラム28内に存在しな
いので、フォント・ファイル40を参照する。表示管理プ
ログラム28は依然としてデータ・ストリーム30を解釈し
なければならないが、そのための構文をフォント・ファ
イル40から受け取る。

したがって、フォント・ファイル40は２つの目的に使
用される。フォント・ファイル40は、画面に表示すべき
図形記号の形を表わすために使用されるだけでなく、デ
ータ・ストリーム30を解析するための規則をも供給す
る。データ・ストリーム30が解析されると、表示すべき
図形記号17にアクセスすることができる。

本発明に基づくシステム及び方法は、ユーザまたはア
プリケーションがフォントを変更できる従来技術よりも
はるかにすぐれている。本発明のシステムでは、ユーザ
またはアプリケーション21がデータ・ストリーム30の構
文を変更することができる。構文はもはやシステム・ソ
フトウェア内に存在しないので、ユーザまたはアプリケ
ーション21が構文を変更することができる。構文は、ユ
ーザまたはアプリケーション21がフォント40中で供給す
る。

したがって、ユーザまたはアプリケーション21は、ユ
ーザまたはアプリケーション21だけが理解できるデータ
・ストリーム30を使用することができる。ユーザまたは
アプリケーション21は、従来、データ・ストリーム30を
解釈するために処理システム製造業者がどんな方法でシ
ステムをあらかじめハード・コード化していたかに依存
しない。その代わり、ユーザまたはアプリケーション21
は、インデックス45を個々にかつ独立してフォント・テ
ーブル40に構造化することにより、それ自体のデータ・
ストリーム30を理解するための手段を提供する。同時
に、フォント40は、データ・ストリーム30によって表わ
されるグリフを表示するための手段を提供する。

第３図を参照すると、データ・ストリーム30は要素
“N1"31、“I"32、“N2"33、及び“N2"34から構成され
る。各要素は16進数のバイトまたは２進数のビットを表
わす。どのような形でも、各要素は０から255までの任
意の数を表わすことができる。フォント・ファイル40
は、フォント・ヘッダ41、アレイ45、及び実際の図形記
号（グリフ）42を含んでいる。アレイ45は、フォント論
理コード・ページ内の各コード点に対するエントリ80を
有する。

たとえば、それぞれ256種のコードを含む３つの論理
コード・ページを有するフォントでは、アレイ45内に76
8個のエントリ80があることになる。たとえば、最初の2
56個のエントリ80は、ゼロ・レベルのコード・ページを
表わす。アレイ内の第２の256個のエントリ80は、第１
レベルのコード・ページを表わす。第３の256個のエン
トリ80は、第２レベルのコード・ページを表わし、以
下、表示可能なすべての図形記号を表わすのに必要なだ
けの256種のコードからなるコード・ページまたはグル
ープすべてについて同様である。256種のコードからな
る各コード・セット180は、同じコード・セットのいく
つかのページのうちの１つ、または異なるコード・セッ
ト標準を表わすことができる。たとえば、256種のコー
ドからなるコード・セットのあるものはASCIIを表わ
し、256種のコードからなる別のコード・セットがNLSを
表わし、256種のコードからなるもう一つ他のコード・
セットが、6000を超える個別のコード点を有するJISを
表わすことができる。これらの標準のすべて及びその他
の標準をアレイ45内で一緒に表わすことができる。

アレイ45内の各エントリ80毎に、制御ビット50があ
り、オン（１）またはオフ（０）にセットされる。制御
ビット50は、アレイ45内のそのエントリ80にある情報
が、制御情報かそれともデータかを示す。２種類の制御
ビットがある。すなわち、インデックス修飾子ビットと
基本修飾子ビットである。インデックス修飾子ビットは
基本修飾子ビットとは互いに排他的である。制御ビット
50がオフにセットされている場合は、値60は、表示すべ
きグリフ42中の図形記号に対するオフセット90である。
インデックス修飾子ビット50がオンである場合は、値60
は、データ・ストリーム内の次のデータ・バイト33に適
用されるインデックス修飾子70である。インデックス修
飾子70は、次のデータ・バイトに対するページ・シフタ
としてのみ使用される。基本修飾子ビット55がオンの場
合は、値75は、次のデータ・ストリームの全データ・バ
イトに適用される基本修飾子である。基本修飾子は後続
のすべてのデータ・バイトに対するページ・シフタとし
て使用される。

表示管理プログラム28（第４図）は、データ・ストリ
ームの最初のバイト“N1"31を受け取ると、アレイ45内
の“N1"要素の所で、すなわちエントリ81でフォント・
ファイル40のインデックス45にアクセスする。たとえ
ば、データ・ストリーム30の“N1"バイト31が数“73"を
表わす場合、最初の位置が０であるとすると、エントリ
81はアレイ・インデックス45の74番目の位置にあること
になる。アレイ45の“N1"エントリ81で、制御ビット50
はオフであり、値60がグリフ42に入るためのオフセット
90であることを示す。グリフ42は、種々のフォントに対
する図形記号の実際のビット・パターンが記憶される場
所である。グリフ内のこれらのビット・パターンは次に
表示装置23に送られる。上記の例を使うと、データ・ス
トリーム30の“N1"要素31が数72を表わし、コード・ペ
ージ100（第1A図）の図形記号17がグリフ42中に記憶さ
れている場合、表示装置に送られる図形記号は“H"とな
る。

表示管理プログラム28は、データ・ストリーム30の第
２の要素“I"32を受け取ると、“I"位置82でフォント・
アレイ45にアクセスする。この例では、インデックス修
飾子ビット50がオンにセットされていて、値60がインデ
ックス修飾子70であり、表示可能記号ではないことを示
す。インデックス修飾子70は、データ・ストリーム30の
次のバイト33を修正する。インデックス位置“I"82にあ
る値60は表示されず、その代わりに、インデックス位置
“I"82にあるインデックス修飾子70が、データ・ストリ
ーム30の次のバイト33に対する基準開始点として使用さ
れる。

データ・ストリーム30の次のバイト“N2"33は、“I"
位置82にあるインデックス修飾値70から“N2"要素33が
表わす数の位置だけ離れた、アレイ45内のエントリ80で
アクセスされる。たとえば、“N2"33が、10進数の255を
表わす16進数“FF"を含む場合、表示管理プログラム28
は、“I"アレイ要素82内のインデックス修飾子によって
指定されるアレイ・エントリから255個のアレイ・エン
トリ80でフォント・アレイ45にアクセスする。これは、
第３図で、後続のコード・ページ“1"180内のアレイ・
エントリ“MM"83として示されている。修飾子70がなけ
れば、データ・ストリームの要素“N2"33により、表示
管理プログラム28は最初のコード・ページの位置“N2"8
4でフォント・アレイ45にアクセスすることになる。

データ・ストリーム30の要素“N2"33がインデックス
・エントリ“MM"83にシフトされたとき、制御ビット50
はオフであり、値60がフリフ42に入るためのオフセット
90であることを示す。このことは、データ・ストリーム
30の“N2"要素33の１つに先行インデックス修飾子70が
あるために、データ・ストリーム30の“N2"33と“N2"34
のバイト値が同じでも、２つの異なるグリフ93、94が生
成されることを示している。上記のことから、データ・
ストリームのある要素がインデックス修飾子70の後に続
くときと、続かないときで違いが出ることがわかる。

インデックス・アレイ位置“I"82にあるインデックス
修飾子70は、グリフ42中の表示可能記号に達するまで、
データ・ストリーム内の後続の要素に対して有効であ
り、かつ累積される。アレイ・エントリ80の制御ビット
50がオフになったとき、表示可能記号に達したことが示
される。グリフ42中の表示可能記号がアクセスされる
と、データ・ストリーム30の次の要素に対する開始点
は、最後に処理された基本修飾子の値に戻る。基本修飾
子が処理されていない場合は、０の値を取る。

インデックス・アレイ45はフォント・ヘッダ41とグリ
フ42の間の構造である。インデックス・アレイ45は、構
文が具体化された構造であり、コード・ページ・シフテ
ィングを可能にする。グリフ42は構文の知識を持たず、
どの画素がオンになるかに関する情報を含むだけであ
る。インデックス・アレイ構造45は、その中に含まれる
構文モデルを使って、コード点をグリフ42に変換する。

したがって、ユーザが自分の構文を作りたい場合は、
インデックス構造45を変更して、データ・ストリーム30
を異なる処理モデルに適合させることになる。このこと
を行なうための機構は、制御ビット50をオンまたはオフ
のいずれかに変更することである。制御ビット50は、デ
ータ・ストリーム30内のバイトが修飾子として処理され
るのか、それとも図形記号として処理されるのかを示
す。ユーザが、インデックス・アレイ45の構造を変更す
る代わりに、文字の現われ方だけを変更したい場合は、
ユーザは、インデックス・アレイ構造に含まれる処理モ
デルの物理的表現であるグリフ42を修正することにな
る。

インデックス・アレイ構造45は、表現したい図形記号
のモデル及び数に応じて長さが変わる。インデックス・
アレイ構造45はグリフ・インデックス42に入るためのオ
フセットを含むので、グリフ・インデックス42がどこで
始まるかは重要でない。

本発明では、別々の処理システムを組み立てず、シフ
タ・コードが何であるかを表示管理プログラムが知る必
要がない。シフタ・コードはどこにあってもよい。さら
に、表示管理プログラムは、シフタ・コードがあるとき
でも、シフトの量を知らない。

構文を判定するため、表示管理プログラムはフォント
・ファイルを参照する。各指示中には、それが表示可能
記号であるのか、それともシフタ・コードであるのかを
示す制御情報がある。それが図形表示可能な記号である
場合は、記号の画素パターンを表示するために使用すべ
きビット・パターンを指す。図形表示可能な記号でない
場合は、アレイ内の別のエントリを指すシフト・コード
である。アレイ内の新しいエントリにアクセスするため
に、次のコードがシフト・コードに付加されている。ア
レイ内のこのエントリは、依然として図形表示可能な記
号ではないことがある。また、次のコードが付加される
シフタであることもあり、以下同様である。多分、表示
可能なコードに達するまで、何回かの飛越しを繰り返す
ものと思われる。

従来の技術では、幾つかのコード・ポインタだけがあ
り、それらは基本シフタであった。それらは、通常、単
一の非ロッキング・シフトの16進数1Cないし1Fであっ
た。16進数0E及びOFは、ロッキング・シフトのシフトア
ウト及びシフトイン制御コードである。これらはあらか
じめ知られており、コード・ページ自体によって定義さ
れる。本発明では、シフタと図形のオフセットの間にあ
らかじめ定められた区別はない。表示管理プログラム
は、データ・ストリーム内のどのコード点についても、
あらかじめそれが表示可能な図形記号の制御コード・シ
フタであるとは想定しない。また、従来のシステム及び
方法では、表示記号範囲に対するオフセットも既知であ
る。また、従来のシステム及び方法では、間接指示（in
direction）レベルが１つしかない。表示記号範囲を指
す基本ポインタを変更するコード・ページ・シフタに出
あうとする。次のコード点は、表示可能な図形記号であ
ると予想される。２つのシフタが一緒に送られた場合
は、最初のシフタは誤りとして無視されることになる。
従来は、シフタは累積することができなかった。図形表
示コード点が付加される最後の既知のシフタが選ばれる
ことになる。本発明では、間接指示レベルは無制限であ
る。フォント・ファイルがコード点によって参照される
度に、コード点がシフタであるのか、それとも表示可能
な図形記号であるのかが判定される。それがシフタであ
る場合は、シフタは、インデックス・アレイ内の別の場
所を指すが、それ自身が別のシフタであることもある。
このため、累積効果が可能となり、希望する数の間接指
示レベルが実現できる。

さらに、従来のシステム及び方法では、処理モデルが
固定されていた。データ・ストリームを解釈するための
モデルは、いつでも１つだけ可能であった。特定のデー
タ・ストリームを処理するためにどのモデルを使用する
かをアプリケーション・プログラムで選択する場合、複
数の処理モデルが存在し得た。しかし、これらの複数の
モデルは時間的に固定されており、表示管理プログラム
内のコードを書き直さないと、新しい異なるモデルを実
施することができなかった。さらに、存在するどのモデ
ルも、ソフトウェアの作成者が判断し、場合によっては
規格委員会に問い合わせていた。

本発明では、処理モデルが変更可能であるため、複数
の処理モデルが同時に可能になる。ユーザ（またはアプ
リケーション）が、どのフォント・ファイルを使用する
かを表示管理プログラムに指示する。ユーザは、表示管
理プログラムを指すフォント・ファイル・ポインタを定
義する。その結果、フォント・ファイルをユーザが動的
に定義し直すことが可能である。アプリケーションは種
々のフォント・ファイルを指すことができる。各フォン
ト・ファイルは、異なる標準または構文を具体化するよ
うに組み立てることができる。ユーザは標準外の構文を
定義することができる。業界における所定の基準に固執
する必要はない。

ユーザがシフトJISを使用したい場合は、シフトJISの
フォント・ファイルを指すことができるように、フォン
ト・ファイルを設けることができる。しかし、ユーザ
が、製造業者の処理システムで通常サポートされていな
い自分の構文を作りたい場合は、ユーザは自分のフォン
ト・ファイルを作成することができる。

第５図に示すような、RTASCIIと呼ばれるRT PCで使用
するASCIIの１バージョンと、シフトJISという、異なる
２つの言語で同じ文を表わす２組の図形記号210、220
が、非互換性データ・ストリーム・モデルによって生成
される。英文210は、第5B図に示す16進数211のストリー
ムによって生成された。日本文220は意味的に英文210と
同等であるが、第5B図に示す16進数データ・ストリーム
221によって生成された。従来技術では、RTASCII処理規
則を採用した表示管理プログラムは、日本文220のデー
タ・ストリーム221内の16進コード81、82、83、89及び9
5を図形コードと見なすが、シフトJISモデルを採用した
プロセッサはそれらを、256個のコード点からなる別の
コード・セット、すなあち、別のコード・ページにシフ
トするための制御コードと見なすので、２つのストリー
ムは互換性がないと見なされることになる。逆に、シフ
トJIS規則は、英文210のデータ・ストリーム211内の16
進数8Dというコードが制御コード、すなわち、制御ペー
ジ・シフタであると見なすが、RTASCII規則はそれを図
形コードと見なすことになる。

本発明では、同一の表示管理プログラム28がデータ・
ストリーム211、221を共に正しく解釈する。何故なら
ば、表示管理プログラムが、フォント・ファイル40に、
どのコード点が図形記号17であり、どれが制御コード15
であるかを示させるからである。

たとえば、表示管理プログラム28は、RTASCIIフォン
ト・ファイル40（第5C図）を使って最初の文210（第5A
図）を表示する。表示管理プログラム28は、インデック
ス・アレイ45の要素281にある要素16進数22に進む。そ
の要素281で、制御ビット250は０にセットされ、値260
がグリフ構造42に入るためのオフセット291と見なされ
ることを示す。表示管理プログラム28はそのオフセット
291の所でビット・パターン231を表示し、データ・スト
リーム211内の次の情報バイト202の処理を続行する。次
の参照は、インデックス・アレイ45の16進数1Cの要素28
2に対するものである。その要素282で、インデックス修
飾子ビット250は１にセットされ、要素282中の制御値26
0がインデックス修飾子270と呼ばれる制御コードである
ことを示す。この要素282中の制御値260はグリフ構造42
を指さず、インデックス・アレイ45内の別の要素283を
指す。この要素283は、本発明の好ましい実施例では、
“P2"と呼ばれる所期のコード・ページ280の論理的開始
点を表わす。表示管理プログラム28は、データ・ストリ
ーム211の次のバイトである16進数8Dを処理する。この1
6進値8Dが、要素282で前の制御コード270によって設定
された正しいコード・ページ280の論理的開始点283に付
加される。アレイ45のこの要素284中で、制御ビット250
は０になり、そこにある値260が修飾子270ではなく、グ
リフ・テーブル42に入るためのオフセット294であるこ
とを示す。こうして、グリフ・テーブル内に正しいビッ
ト・パターン234にアクセスすることができ、ギリシャ
文字“π”が表示される。データ・ストリーム211の次
の16進コード要素205により、表示管理プログラムは、
要素281でインデックス・アレイ45にアクセスする。何
故ならば、文字が表示される毎に、コード・ページ・ポ
インタがインデックス・アレイ45の開始点１に論理的に
戻るからである。英文の残りの部分は、データ・ストリ
ーム内に他の制御コード、すなわち、コード・ページ・
シフタがないので、１バイトの図形コード点と見なされ
る。

データ・ストリームを表示装置に送るアプリケーショ
ンは次に、作業フォントを１に変更させて、日本文の処
理のためにシフトJISモデルを実施させる。データ・ス
トリーム221内の最初のコード・バイト206は、16進数81
であり、表示管理プログラム28を、16進数バイト81を表
わす要素286で新しいフォント43（第5D図）のインデッ
クス・アレイ46にアクセスさせる。RTASCIIフォントと
は違って、シフトJISは、インデックス修飾子ビット250
を１にセットすることにより、この要素が制御コードで
あることを示す。したがって、この位置286の値260は修
飾子270と見なされ、修飾子270は、インデックス・アレ
イ46の、所期のコード・ページ280の論理的開始点とな
る部分を指す。次のバイト207は、データ・ストリーム2
21内で16進数75として示されており、表示管理プログラ
ムを、要素286中の修飾子270が指すコード・ページの論
理的開始点２から16進数で75位置離れた要素287の所で
インデックス・アレイ46にアクセスさせる。この要素28
7中では、制御コード250が０にセットされ、要素287が
フリフ・テーブル42に入るためのオフセット260を含む
ことを示す。このオフセットの所にあるビット・パター
ン237は表示され、表示管理プログラム28は、シーケン
スが終了したものと見なす。したがって、表示管理プロ
グラムはコード・ページ・ポインタを０、すなわち、イ
ンデックス・アレイ46の開始点１に論理的に戻す。日本
文のためのデータ・ストリームの残りの部分の処理が、
同様にして続行される。

第5B図に示した第２のデータ・ストリーム221は、完
全に「２バイト」である。すなわち、制御コードである
１データ・バイトとそれに続く図形コードである１デー
タ・バイトから全体が構成されていると見なされる。第
5B図のデータ・ストリーム211に関して上に示した例
は、元来「単一バイト」のデータ・ストリームである
が、１つの２バイト・シーケンス、すなわち、データ・
ストリーム211内の要素202、204として示される“1C、8
D"を含んでいる。本発明を用いると、様々な「バイト
長」のデータ・ストリームを混合することができる。デ
ータ・ストリームの検査だけでは、使用されるバイト長
モデルの性格を判定するのに十分ではない。制御コー
ド、すなわちコード・ページ・シフタは、表示管理プロ
グラムのプログラム式コード中ではなく、データ・スト
リームを表示するために管理プログラムに供給されるフ
ォント・ファイルのインデックス・アレイの制御ビット
中で定義される。

上記に示したように、表示のために使用可能な図形記
号の範囲が65535の超える場合は、図形記号を表示する
ために３バイト以上が必要となることがある。たとえ
ば、最初の256種の各コード点は、それぞれ256種の使用
可能なコード・ページの１つにシフトすることができ、
各コード・ページは256種の表示可能な記号を含む。最
初のバイトはコード・ページ・シフタを表わし、第２の
バイトはコード・ページ内の図形記号を表わす。

第６図に示すもう１つの好ましい実施例は、アニメー
ション・フレームを表示するために使用できるデータ・
ストリーム300を示したものである。この例を選んだの
は、アニメーションを表示するために必要なアニメーシ
ョン・フレームの数が65535種の表示可能記号を容易に
超え得るためである。フレームの数がそれを超えると、
特定のアニメーション・フレーム、すなわち、図形記号
を指定するために３バイト以上が必要になる。この例
は、データ・ストリーム内のバイト301−307が、前の例
のように16進数ではなく10進形式であることを示してい
る。

最初のフレーム331は、２バイトの非反復的指定によ
ってアクセスされる。すなわち、値83を含む最初のバイ
ト301は、アレイ345に入るためのインデックス381であ
り、値512を有するインデックス修飾子370を与える。ス
トリーム内の第２のバイト302は、値88と、値512を有す
る修飾子370とから成りデータ要素382でインデックス・
アレイ345に入るためのインデックス600を与える。これ
は、アニメーション・フレームまたは図形記号からなる
グリフ342に入るためのオフセット360である。

第２のフレーム332は反復的修飾子を示す。データ・
ストリーム300の第２のフレーム332の最初のバイト303
は値83を有し、やはりインデックス・アレイ345に入る
ためのインデックス381である。これは値512を有する修
飾子370をもたらす。データ・ストリーム300の第２のフ
レーム332の第２のバイトは、値109と、値512を有する
修飾子370とを有し、エントリ384でインデックス621を
与える。インデックス修飾子ビット250がオンであるの
で、制御値360も、値68048を有する修飾子370である。
データ・ストリーム300の第２のフレーム332の第３のバ
イト305は、値161と要素381及び384にある２つの修飾子
の値とを有し、インデックス・アレイ345のエントリ385
でインデックス・エントリ68721を与える。このエント
リ位置385の制御コードは０であり、値はグリフ342に入
るためのオフセット360である。この実施例では、修飾
子の累積が可能となる。別の実施例では、修飾子の置換
が可能となる。

第３のフレーム333は、単純化したアクセス方法と思
われるものを示している。データ・ストリーム300の第
３のフレーム333の最初のバイト306は、値202を有し、
インデックス・アレイのエントリ386でインデックス202
を与える。最後のバイトはグリフに入るためのオフセッ
トであり、図形記号が表示されたので、バイト値はイン
デックス・アレイ345の開始点１からカウント・オフさ
れる。インデックス修飾子ビット250は要素386中でオン
であるので、値260はインデックス修飾子270である。イ
ンデックス修飾子370は値68720を有する。データ・スト
リーム300の第３のフレーム333の第２のバイト307は、
値０を有する。この値と前のインデックス修飾子の値と
が、インデックス・アレイ345内へのエントリ387でイン
デックス68720を与える。制御ビット250はオフであり、
したがって値260はグリフ342に入るためのオフセットで
ある。

新しい２バイト・シーケンス202、１は、第２のフレ
ーム332に対して使用された３バイト・シーケンス83、1
09、161が示すのと同じグリフ342に入るためのオフセッ
ト322を示すことに留意されたい。これは実際には非効
率的であるが、本発明の融通性を示すものである。

好ましい実施例に関連して本発明を具体的に図示し、
説明したが、当業者なら理解できるように、本発明の精
神及び範囲から逸脱することなく形態及び細部に種々の
変更を加えることができる。

本発明のシステム及び方法は表示装置による図形記号
の表示に限定されるものではない。第４図に示すよう
に、本発明は、印刷出力上での図形記号の表示にも適用
できる。表示管理プログラム28という言葉を印刷管理プ
ログラム14に置き換え、表示装置23という言葉をIBMプ
ロプリンタ（Proprinter）等の印刷装置24に置き換える
と、本発明の技術的思想を同様に具体化できることが理
解されよう。

E.発明の効果 以上説明したように本発明によれば、処理モデルをフ
ォント・ファイルに組み込むようにしたことによって、
より融通性の高い図形記号の出力が可能となる。

【図面の簡単な説明】

第1A図は、図形記号、制御コード、及びページ・シフタ
制御を表わす、16進数のゼロ・レベル・コード・ページ
を示す図である。 第1B図は、同じ制御コード及びページ・シフタ制御を有
するゼロ・レベル・コード・ページ以外の別の図形記号
を表わす、16進数の第１レベル・コード・ページを示す
図である。 第1C図は、同じ制御コード及びページ・シフタ制御を有
するゼロ・レベル及び第１レベル・コード・ページ以外
の別の図形表示を表わす、16進数の第２レベル・コード
・ページを示す図である。 第２図は、表示管理プログラムでコード化されるデータ
・ストリーム処理モデルを有する、当技術で周知のデー
タ処理システムを示す図である。 第３図は、フォント・ファイルのインデックス・アレイ
に組み込まれた処理モデルを示す図である。 第４図は本発明に基づくシステムの実施例を示す図であ
る。 第5A図は、同時に表示される２つの非互換性構文で表わ
される２つの異なる言語からの図形記号を有する表示装
置を示す図である。 第5B図は、第5A図に示す表示装置用の16進数データ・ス
トリームを示す図である。 第5C図は、最初のフォント・ファイル内の最初の処理モ
デルを示す図である。 第5D図は、第２のフォント・ファイル内の第２の処理モ
デルを示す図である。 第６図は、フォント・ファイル内の処理モデルの無限の
数の図形記号に繰り返しアクセスできる能力を示す図で
ある。 第７図は、シフトJISコード・ページを示す図である。 14……印刷管理プログラム、21……アプリケーション、
22……オペレーティング・システム、23……表示画面、
24……印刷装置、28……表示管理プログラム、30……デ
ータ・ストリーム、40……フォント・ファイル、45……
インデックス・アレイ。

フロントページの続き (56)参考文献 特開 昭61−106264（ＪＰ，Ａ) 特開 昭61−127361（ＪＰ，Ａ) 特開 昭62−14689（ＪＰ，Ａ) 特開 昭62−77960（ＪＰ，Ａ) 特開 昭62−182795（ＪＰ，Ａ) 特開 昭62−239195（ＪＰ，Ａ)

Claims (3)

(57)【特許請求の範囲】
1. 【請求項１】特定の構文を有するデータ・ストリームか
   ら図形記号を表示するための処理システムにおいて、 フォント・ファイルと、 前記データ・ストリーム中のどのバイトが表示すべき図
   形記号コードを表し、どのバイトが前記データ・ストリ
   ーム内の次の順次的バイトに対する修飾子を示す制御コ
   ードを表すかを定義する１組の規則を含む処理モデルを
   前記フォント・ファイル中に組み込むように前記フォン
   ト・ファイルを構造化する手段を含み、 前記構造化されたフォント・ファイルは前記データ・ス
   トリームから制御コードを峻別し且つ前記データ・スト
   リームから図形記号コードを峻別する機能を有すること
   を特徴とする処理システム。
2. 【請求項２】データ・ストリームから図形記号を表示す
   るための処理システムにおいて、 フォント・ファイルと、 前記データ・ストリーム中のどのバイトが表示すべき図
   形記号コードを表し、どのバイトが前記データ・ストリ
   ーム内の次の順次的バイトに対する修飾子を示す制御コ
   ードを表すかを定義する１組の規則を含む処理モデルを
   内部に組み込むための手段を有するフォント・ファイル
   と、 前記データ・ストリームを前記フォント・ファイルの指
   示に従って処理する手段とを含み、 前記を構造化する手段を含み、 前記組み込むための手段は前記フォント・ファイルを構
   造化する手段を含み、前記構造化されたフォント・ファ
   イルは前記データ・ストリームから制御コードを峻別し
   且つ前記データ・ストリームから図形記号コードを峻別
   する機能を有することを特徴とする処理システム。
3. 【請求項３】データ・ストリームから図形記号を印刷す
   るための処理システムにおいて、 フォント・ファイルと、 前記データ・ストリーム中のどのバイトが印刷すべき図
   形記号コードを表し、どのバイトが前記データ・ストリ
   ーム内の次の順次的バイトに対する修飾子を示す制御コ
   ードを表すかを定義する１組の規則を含む処理モデルを
   内部に組み込むための手段を有するフォント・ファイル
   と、 前記データ・ストリームを前記フォント・ファイルの指
   示に従って処理する手段とを含み、 前記を構造化する手段を含み、 前記組み込むための手段は前記フォント・ファイルを構
   造化する手段を含み、前記構造化されたフォント・ファ
   イルは前記データ・ストリームから制御コードを峻別し
   且つ前記データ・ストリームから図形記号コードを峻別
   する機能を有することを特徴とする処理システム。