JPH02284196A - キヤラクタ・データとデジタル・イメージのマージのための方法、装置、及びシステム並びにフオーム作成方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は広くデータ処理装置に関し、特にデータ処理シ
ステム＆二二おけるデジタル・イメージと英数字等のキ
ャラクタ列のマージ（併合）に関する。

Ｂ、従来の技術 デジタル・イメージを格納・操作するシステムの例は、
特願平１−９９０４８号と同１−１６１０２３号に見ら
れる。これらの出願特許は、ここに述べる本発明を応用
できるデジタル・イメージ保管システムの一例について
説明している。従来の技術では、デジタル・イメージ保
管システムのユーザが、記入済みのフオームを（たとえ
ば自動車保険の申請書など、申請者の名前、住所などが
記入されるフオームをシステムに人力したい場合、ユー
ザは申請者の所定のデータ（カスタム・データ）をあら
かじめ印刷されたフオームにプリントし、光学式スキャ
ナを使用して記入済みフオームを走査する必要がある。

こうして得られたデジタル・イメージはイメージ保管シ
ステムに入力される。この方法は、オペレータの能率か
ら言っても、印刷済みフオームなどの媒体の利用面でも
効率的ではない、従来の技術にはこのような問題の解決
法がない。

Ｃ９発明が解決しようとする課題 本発明の目的は、英数字等のキャラクタデータをデジタ
ル・イメージとマージ（併合）する改良された手段を提
供することにある。

本発明の目的は、デジタル・イメージ保管システムに入
力するために、カスタム・データを所定のフオームに入
力する改良された手段を提供することにある。

本発明の目的は、デジタル・イメージ保管システムにお
いてコード化データをデジタル・イメージとともに処理
する手段を゛提供することにある。

本発明の目的は、コード化データをデジタル・イメージ
とともに処理することで、後に格納、表示あるいはプリ
ントするためにそれらを自動的に併合する手段を提供す
ることにある。

０１課題を解決するための手段 これらの目的、特徴、利点は、ここに述べる本発明によ
って達成される。英数字等のキャラクタ・データ・スト
リームをデジタル・イメージ・ファイルとマージする方
法は、デジタル・イメージ・ファイルを第１の入力端末
に入力して第１の記憶媒体に格納するステップと、キャ
ラクタ列を第２の入力装置に入力して第２の記憶媒体に
格納するステップと、第２の記憶媒体に格納されたキャ
ラクタ列をピクセル・ビットのイメージに変換するため
に、キャラクタ列の個々の文字をピクセルの２次元ピッ
Ｉ・・パターンに置き換えるステップと、デジタル・イ
メージ領域の所定の文字位置で各キャラクタのビット・
パターンをデジタル・イメージと論理的に組み合わせる
ステップと、キャラクタが重ね合わされ論理的に組み合
わされたデジタル・イメージを出力するステップとを有
する。

データ処理システムでフオームを作成するプロセスは、
複数の空白領域を含むフオームを媒体内に作成するステ
ップと、フオームのデジタル・イメージをフオームイメ
ージ・ファイルとしてデータ処理システムに取り込む（
ｃａｐｔｕｒｅ　）ステップと、フオームイメージ・フ
ァイルを第１のファイル名でデータ処理システムに格納
するステップと、フオーム内の空白領域のそれぞれに対
応する名前データと位置データを入力して、第１のファ
イル名をフォーマット・データ・セットに関連づけるス
テップと、フォーマット・データ・セットを第２のファ
イル名でデータ処理システムに格納するステップとを有
する。フオームに項目を記入するときは、フォーマット
・データ・セットがアクセスされ、いずれかの空白に追
加されるキャラクタ列が入力される０次に、第１のファ
イル名と、キャラクタ列で表されるカスタム・データと
を含むカスタム・データ・石ットがまとめられる（　ａ
ｓｓｅｍｂｌｅｄ　）　、ここでカスタム・データ・セ
ットが格納される１本発明の特徴は、複数のカスタム・
データ・セットを格納でき、各データ・セットの記憶領
域が小さく、各データ・セットが、比較的大きな記憶領
域を占める１つのフオームイメージ・ファイルに対応す
ることにある。記入済みのフオームを表示するときは、
カスタム・データ・セットがアクセスされ、このデータ
・セットから第１のファイル名が抽出される。ここで、
第１のファイル名によってフオームイメージ・ファイル
をアクセスできる０次に、カスタム・データ・セット内
のキャラクタ列が、この列を表すキャラクタのピクセル
・ビットの形に変換される、その後、キャラクタのピク
セル・ビット形状が、カスタム・データ・セットに指定
された空白の位置でフオームイメージファイルと併合さ
れる。最後に、こうして得られた記入済みフオームが表
示あるいは印刷される。

Ｅ６実施例 以下の説明では、キャラクタの例として英数字を採土げ
る。

本発明は、先に引用した出願特許に述べられている［イ
メージ・システム」で、コード化データをイメージとと
もに処理する手段および、コード化データとイメージが
レコード・ヘッダ情報によって論理的に関連づけられて
いる場合に、表示装置上でコード化データとイメージを
自動的に併合する機能を備えたワークステーションまた
はプリンタのビット・ブレーンでの処理機能を明らかに
するものである。

コード化データ・ストレージ・プロセッサは、コード化
データ（イメージ以外のレコード）を、先に引用した出
願特許に説明されているＩＢＭイメージ・システムＭＶ
Ｓ／ＥＳＡのフォルダに格納するためのソフトウェア・
コンポーネントである。これにより、これまではイメー
ジだけを処理してきた同システムの機能によってコード
化データ並びにイメージの格納、管理、処理が確実に行
える。

イメージ・システムＭＶ９／ＥＳＡの内部処理機能を利
用すれば、イメージまたはコード化データをシステム全
体で処理できる。これとは別に、オブジェクト・ワーク
ステーションは、コード化データを、あらかじめ識別さ
れたオーバレイ・イメージと併合して、ワークステーシ
ョンの表示装置やプリンタに表示する機能を備える。こ
のような機能により、イメージ以外の形式（ＥＢＣＤＩ
Ｃ−一拡張２進化ｌＯ進コード）で格納できるため、物
理的な記憶域を大幅に縮小でき、コード化データをイメ
ージと同じようなフォーマットで自動的に表示できる。

個人、勘定、保険などのエンティティに関して利用でき
るシステム情報をすべて表現するデータの関係集合（論
理的な集合）がある、この関係集合は、このようなエン
ティティのフォルダを成す、従来の技術で実現されたも
のは、イメージ・ドキュメント（イメージ・フォーマッ
トで格納されるイメージやコード化データ）のフオルダ
のための分離されたイメージを安定に処理する（ライト
・ワンス・リードーマルティプル（ＷＯＲＭ］技術）機
能か、またはエンティティに関する各種のコード化デー
タを個別にあるいは関係づけて処理する機能のいずれか
であり、それぞれをそれぞれのフォーマットで、単一の
安定な（ＷＯＲＭ技術）フォルダ格納・検索システムに
格納して統一的に処理するものではない、従来技術はま
た、２つのフォーマットをワークステーションで自動的
に併合する機能を提供するものではない、従来技術では
、ワークステーションのユーザがメニューを選択するか
、または対話式の手段を通して指示を与える必要がある
。イメージとコード化データをイメージ・システムＭＶ
Ｓ／ＥＳＡのフオルダにおいて統合する操作が、本発明
の要点である。

そのほか、従来技術の多くは１図形、イメージ、テキス
ト（コード化データ）をカットとペーストまたはオーバ
レイによってページあるいは書籍並のフォーマットに仕
上げるパブリッシング・システムを扱っている。このよ
うなシステムでは、合成や複合などのタスクを実現する
ために各データの構造に精通していなければならない、
各データを安定に（ＷＯＲＭ技術）統一的に格納する機
能はなく、エンティティの全データ（イメージ、コード
化データ）から構成され、ユーザが内部のデータ構造を
意識することなく格納、検索。

表示ができる統合されたシステム・フォルダという概念
もない。

フオルダにまとめられるシステム・データは、一般には
、走査されたイメージ・データに限らず、キー人力、他
のイメージ以外の入力システム処理手段、あるいはシス
テム生成（演算）によって人力されるコード化データも
含まれる。コード化データは１通常は、これが取り込ま
れるかコンピユータ・システムによって生成されるとき
作成される磁気ＤＡＳＤやテープに格納される。従来技
術では、このようなデータのプリントアウトを、走査に
よってイメージとして取り込んだり、イメージ・データ
としてフォルダに追加したりすることはできる。

第１図は、イメージ・システムＭＶＳ／ＥＳＡのコンポ
ーネント（ｌないし６．８，１４．１５）に本発明の（
７）を加えたものである。

フォルダ・アプリケーション機構（ＦＡＦ）（１）は、
イメージ（１５）とコード化データ（８）のフォルダと
の論理関係を維持する。オブジェクト配布マネージャ（
ＯＤＭ）（２）は、イメージとコード化データの処理要
求をイメージ・システムＭＶＳ／ＥＳＡ全体に配布する
。オブジェクト・アクセス・メソッド（ＯＡＭ）（３）
は、ＷＯＲＭ技術を用いたＤＡＳＤ　（５）と光学式デ
ィスク（６）に格納されるイメージとコード化データを
管理する。オブジェクト・ワークステーション（４）は
イメージやコード化データの表示またはプリントに用い
られる。

２　。

コード化データ・ストレージ・プロセッサ（７）は、Ｃ
０ＢＯＬＩＩで書かれるソフトウェア・コンポーネント
であり、ＭＶＳ／ＥＳＡ上でＣＩＣ５（顧客情報管理シ
ステム）のアプリケーション・プログラムとして実行さ
れる。このコンポーネントの入出力の流れを第１図と第
２図に示す。

１゜ 処理パラメータ入力ファイル（９）を読み込んで、コー
ド化データ・ストレージの実行環境を起動するか再起動
するかを決定する。

ＩＢＭイメージ・システムＭＶＳ／ＥＳＡ内に格納され
るコード化データ・インテリジェント・プリンタ・イメ
ージ・ユーティリティ（１４）によって作成される格納
許可コマンドとコード化データ・レコードの外部ファイ
ル（８）を読み込む。

ＯＡＭ　（３）を呼び出して、コード化データ・レコー
ド（１３）をＤＡＳＤ　（５）と光学式ディスク（６）
に物理的に格納する。

４、　登録コマンドを、ＦＡＦ　（１）が用いる外部フ
ァイル（１０）に書き込み、格納登録プロセスを完了す
る。

５、　　ＦＡＦ　（１）が用いる外部ファイル（１１）
にエラー・レポートを送り、格納登録プロセスでエラー
の調停を行う。

６、　コード化データ・ストレージ・プロセスを管理す
る際に可視性を与＾るために用いられる外部ファイル（
１２）に関するレポート情報を提供する。

本発明の特徴は次のとおりである。

１、　　レコード長が最大１５００万バイトのコード化
データ・レコードを、内部データ・アーキテクチャのフ
ォーマットを意識せずに格納できる。

２、　イメージ・システムＭＶＳ／ＥＳＡから分離した
ＣｌＣ５処理領域で実行され、同システムの処理領域の
資源に干渉することがない。

３、　プレゼンテーション・テキスト・データのアーキ
テクチャ・フォーマット（イメージ以外）で表されるコ
ード化データ・レコードを処理するが、対象となるアー
キテクチャはこれに限定されない。

４、　誤り回復プロセスの最中に用いられる簡単な再起
動論理を提供子る。

まとめると、コード化データ・ストレージ・プロセッサ
（ＣＤＳＰ）（７）は、イメージを格納するためイメー
ジ・システムＭＶＳ／ＥＳＡで用いられるものと同じ記
憶装置（５，６）に、イメージ以外のレコード（コード
化データ）　　（１３）を格納するためのソフトウェア
・コンポーネントである。さらに、サポートされるコー
ド化データのフォーマットは、レコードが、イメージ・
ドキュメントと同じように、検索、表示、プリントの対
象となるドキュメント（レコード）を表現するものとし
てイメージ・システムＭＶＳ／ＥＳＡ内で充分に活用さ
れるような構造を持つ。

さらに、ＩＢＭイメージ・システムＭＶＳ／ＥＳＡのＦ
ＡＦコンポーネント（１）がサポートされるため、シス
テムのコード化データ・レコードとイメージ・レコード
を各フオルダ・エンティティの中で論理的に関連づける
ことができ、イメージ・システムＭＶＳ／ＥＳＡは、１
つの統一されたフォルダ処理要求を受けて、いずれかの
レコードまたは両方のレコードのアクセスを提供すると
ともに、ＦＡＦコンポーネントにより、コード化データ
とイメージ・データをオペレータの介入なくワークステ
ーションで併合することができる。

第３図は、本発明によるフオームの作成、フオームへの
記入、記入済みフオームの表示の３つの主なステップを
示す流れ図である。

第３図の流れ図では１紙またはＣＡＤ　（コンピュータ
支援による設計）プログラムを用いるビデオ画面などの
媒体に、複数の空白領域のあるフオームが作成される。

このようなフオームの一例を第４図に示す、第４図から
分かるように、媒体（この例では紙）は複数の列と複数
の行に分けられる。第４図では３３列２４行である。英
数字はそれぞれ１行１列の交点に相当する四角形を占め
る。第４図の例では、申請書はＡＢＺ保険会社用に作成
されている。このフオームには“顧客名−１−顧客住所
、“保険番号”の３つの名前フィールドがある。これら
３つの名前フィールドのそれぞれに対して、先頭の行と
列の座標および長さで決まる空白領域があ゛す、先頭行
列と長さは、後で空白領域に追加される英数字列の最初
の文字の先頭位置とその英数字列の最大長さに対応する
。フオームイメージ・ファイル名、空白領域の名前、フ
ィールド位置およびフィールド長を指定し、フォーマッ
ト・データ・セットと呼ばれるデータ・セットの一例を
、フォーマ・ソト・データ・セットとして第５図に示す
。

第３図の流れ図により、第４図のフオームが作成された
後、そのデジタル・イメージが、先に引用した出願特許
に述べられているようなイメージ・システムにフオーム
イメージ・ファイルとして取り込まれる。フオームイメ
ージ・ファイルはそこで、“申請”など第１のファイル
名でイメージ・システムの大型記憶装置に格納される。

フオームを作成するプロセスの一部として。

フオームイメージ・ファイル名“申請“を指定し、フオ
ームの各空白領域の名前を指定することで、第５図のフ
ォーマット・データ・セットが作成される。フオームに
指定された空白領域のそれぞれについて、フィールドの
名前、フィールドの位置およびフィールドの長さも第５
図に示すようにフォーマット・データ・セットに追加さ
れる。

次に、フォーマット・データ・セットは、第３図の流れ
図により、第２のファイル名でイメージ−システムに格
納される。これに代えて、フォーマット・データ・セッ
トを別の記憶装置に格納することもできる。第５図のフ
ォーマット・データ・セットとこれに対応する第４図の
フオームイメージ・ファイルの関係が、フオームイメー
ジ・ファイル名“申請゛をフォーマット・データ・セッ
トに追加することで確立されるからである。

たとえば、フォーマット・データ・セットは、イメージ
・システムの外部に保管されるディスク上に維持するこ
ともできる。そのとき、フオームは作成されていて後で
利用できるよう格納されている。

また、第３図の流れ図により、フオームのコピーにカス
タム・データを記入する必要が生じる（たとえばＡＢＺ
保険会社の顧客が電話で申し込みを行い、保険会社の従
業員が、イメージ・システムに接続されたワークステー
ションで申請書の空白部に項目を記入するため必要な処
置を行う場合など）、第３図の流れ図により、ワークス
テーションのオペレータは最初に第５図のフォーマット
・データ・セットにアクセスする。このデータ・セット
には第５図に示したデータが含まれる０次にワークステ
ーション側の端末で第５図のフォーマット・データ・セ
ットに格納されたデータが操作され、第６図に示すよう
なカスタム・データの入力に必要な情報が表示される。

第６図は、この例では保険会社の従業員が、顧客名、顧
客の住所および新しい保険番号を入力するワークステー
ション側の端末を示す、フォーマット・データ・セット
はから文字列“顧客名”が与えられ、これが、顧客名は
２０文字以内に収めるべきことを示すフォーマット・デ
ータ・セットの長さフィールドからの情報とともにワー
クステーションの端末に表示される。これと同様の表示
は、第６図のカスタム・データ入力画面に示すとおり、
−顧客住所−と一保険番号”についても行われる。

オペレータが、最終的には第４図に示すフオームの空白
部に追加される英数字列を入力した後。

第７図に示すように、顧客からの申請内容に対応するカ
スタム・データ・セットがまとめられる。

第７図は、フォーマット・データ・セットからフオーム
イメージ・ファイル名゛申請−を引き出し、そのフオー
ムイメージ・ファイルに、第５図のフォーマット・デー
タ・セットに指定される一顧客名°、“顧客住所−およ
び−保険番号−に対応する文字列を関連づけてまとめら
れる第１のフォーマット・データ・セットを示す、この
ようなカスタム文字列のそれぞれには、最終的に第４図
に示したフオームに配置されるとき、各フィールドの先
頭位置に関連づけられる。たとえば顧客名”Ｊｏｈｎ　
Ｄｏｅ”のカスタム文字列には、第７図の第１のカスタ
ム・データ・セットの位置フィールド（１１，６）が関
連づけられる０項目“（ｌｌ、６）″は、“顧客名−に
対して、第４図のフオームの空白フィールドに追加され
るカスタム文字列“Ｊｏｈｎ　Ｄｏｅ”の最初の文字の
行列位置を表す０次に、申請者“Ｊｏｈｎ　　Ｄｏｅ”
のカスタム・データ・セットはイメージ・システムに格
納される。

第７図に示すとおり、カスタム・データ・セットは上記
のほか２つある。“Ｍａｒｙ　Ｄｏｅ−の第２のカスタ
ム・データ・セットと“Ｔｏｍ　Ａｌｐｈａ−の第３の
カスタム・データ・セットもオペレータによって第６図
のカスタム・データ入力端末で作成されるものである。

これら３つのカスタム・ブタ・セットは、”申請”とい
う名前のフオームイメージ・ファイルとともにイメージ
・ファイルに格納される１本発明の利点は、特に第８図
によって明らかになる。ここで代表的なフオームイメー
ジ・ファイルのサイズは、圧縮後には５０にバイトにな
る。保険申請者“Ｊｏｈｎ　Ｄｏｅ”　、　　−Ｍａｒ
ｙＤｏｅ”、“Ｔｏｍ　Ａｌｐｈａ−の記入済みフオー
ムを格納する場合、イメージ・システムに必要な記憶域
は合計１５０にバイトになる０本発明により、ファイル
名“申請”に関連づけてイメージ・システムに格納され
る５０にバイトのフオームイメージ・ファイルは、１フ
アイルだけである１次に、３つの異なるカスタム・デー
タ・セットがイメージ・システムに格納されるとき、そ
れぞれに必要な記憶域は、第８図に示すとおり約２にバ
イトである。こうして、３人の申請者に必要な記憶域は
約５６にバイトになる。これが、本発明によって得られ
る大きなメリットである。

後に、第７図の３つのカスタム・データ・セットによっ
て表される申請者の記入済みフオームを表示したりプリ
ントしたりすることがある。これは第３図の流れ図によ
り、申請者に対応するカスタム・データ・セットをアク
セスすることで行える。たとえば、申請者ジョン・ドウ
氏が保険会社に電話して、同氏の勘定について話をする
場合を考える。保険会社の従業員は、ジョン・ドウ氏の
カスタム・データ・セットをアクセスする０次に第１の
ファイル名“申請−が第１のカスタム・データ・セット
から引き出される０次に“申請”という名前のフオーム
イメージ・ファイルがアクセスされる。先に引用した出
願特許に述べられているとおり、第４図に示した空白の
フオームのイメージは、復元されてワークステーション
側の表示バッファにロードされる。

ここで本発明により、“Ｊｏｈｎ　Ｄｏｅ”、住所“１
２３　　Ｂａｋｅｒ　５ｔｒｅｅｔ”および保険番号−
２３１９８“用の第１のカスタム・データ・セットの英
数字列が、カスタム・データ・セットの文字列で表され
る対応する文字のピクセル・ビット形状に変換される０
本発明を説明するには第９図が必要になる。第４図に示
したフオームイメージで、各行と各列の交点は短形のピ
クセル・ビット配列によって構成される０文字位置はそ
れぞれピクセルを短形に配置したものとして表される。

１２ビ・ソチのフォントの場合、第９図に示すように、
水平方向に８ビツト、垂直方向に１６ビ・シトである。

ＩＯピッチ・フォントでは、水平方向に１０ピクセル、
垂直方向に１６ピクセルである。“Ａ”などの文字のＡ
ＳＣＩＩコードをピクセル・ビ・シト形状に変換するプ
ロセスは、従来からよく知られている文字発生プロセス
によって実行される。ここで文字のピクセル・ビット形
状は読み出し専用メモリ（ＲＯＭ）に格納され、このピ
クセルの２次元配列は、対応するＡＳＣＩＩ文字によっ
てＲＯＭのアドレスが指定されるときに走査される。

１２ピツチの８ｘ１６の四角形など、２次元の四角形と
して構成することで、”Ａ”の形状力５描力）れる、こ
のような文字発生の例は、米国特許第４４０８２００号
に見られる。

“申請−という名前のフオームイメージ・ファイルは、
全点をアドレス指定できる表示装置の表示バッファにロ
ードされ、これによって、第４図に示した空白の申請書
のイメージが、全点をアドレス指定できるモードで、た
とえば８５０ｘｌ１００ピクセルの表示が可能なイメー
ジ・バッファによって表示される。−例として、第４図
の空白の申請書の中で変更されない文字、たとえば保険
会社”Ａ　Ｂ　Ｚ”という名前では、各文字が全点のア
ドレスを指定できるモードで表される。たとえば列８、
行２の“八−は、１２ピツチ・フォントでは、水平方向
に８ピクセル、垂直方向に１６ピクセルの全点をアドレ
ス指定できる文字の四角形で表される。第４図のフオー
ムイメージの空白領域では、文字位置は一般には空白で
あり、各文字位置内のピクセルは、黒ではなく白のスペ
ースを表す、“Ｊｏｈｎ　Ｄｏｅ“なと、第１のカスタ
ム・データ・セットから引き出された英数字列では、そ
れぞれの文字が、上述のように対応するピクセル・ビッ
ト形状に変換される。たとえば’Ｊｏｈｎ　Ｄｏｅの”
Ｊ”はピクセル・ビット形状に変換され、そのピクセル
・ビット形状は次に、列１１．行６に相当する文字位置
のピクセルと論理ＯＲがとられた後、“Ｊｏｈｎ　Ｄｏ
ｅ“の残りの英数字列の論理ＯＲ演算が行われて、第４
図の空白の申請書内の“顧客名“に対応する空白部が処
理される。同様に、住所フィールド″’　１２３　　Ｂ
ａｋｅｒ　５ｔｒｅｅｔ”は、第４図の空白の申請書の
空白部に対応する（１１．１１）に追加され、保険番号
“２３１９Ｂ″′は（１５，１６）に追加される。こう
して第１０図に示すような記入済みの申請書が得られる
。このイメージは、ワークステーションの表示装置に表
示され、また任意に所定のプリンタに印刷できる。

旦ＤＳ旦ぶり［作 顧客は、ユーティリティ・プログラムを開発し、プレゼ
ンテーション・テキスト・オブジェクト内容アーキテク
チャ（ＰＴＯＣＡ）と呼ばれるデータ・フォーマットで
コード化データを作成する。このデータ・フォーマット
は制御シーケンスから構成され、このシーケンスによっ
てフォントを選択でき、テキストを表示装置やプリンタ
に正確に位置づけることができる。ＰＴＯＣＡにはプレ
ゼンテーション・テキスト・データ記述子を追加するこ
とができる。これは各レコードのデータの前に置かれる
個別フィールドである。その目的は、基準単位、最大サ
イズ、各種オプションの選択などを指定できるようにす
ることにある０本発明により、テキスト・データの表示
には記述子が必要になる。コード化データの各項目は、
テープ管理レコードとこれに続く１つ以上の格納許可コ
マンドの組および対応するコード化データとのフォーマ
ットで外部の媒体（テープなど）に置かれる。オーバレ
イ・イメージを用いるコード化データの場合、フオーム
の名前を含むコード化データ・ヘッダ・レコードのそれ
ぞれに標識が付けられる。

顧客は、これとは別のプロセスで、オーバレイ・イメー
ジを走査し、コード化データ・ヘッダに用いられるもの
と同じ名前を使用して、オーバレイのそれぞれにオブジ
ェクト・レコードを作成する。こうしてコード化データ
とオーバレイ・イメージのフオームが“接続”される。

テープの内容は、バッチ処理でイメージに入力される、
ここでＣＤ５Ａがテープ上のレコードを読み出して、オ
ブジェクトを格納するために作成されたＡＰＩを通じて
、オブジェクト格納マネージャに格納要求を出す、ＣＤ
５Ａは、オブジェクト格納マネージャによって格納され
たコード化データオブジェクトのそれぞれに対して、レ
ジスタ・コマンド（正しく格納されたことを示す標識）
を含む戻りレコードを作成する。コード化データ・オブ
ジェクトがすべて格納されると、テープは顧客のフォル
ダ・アプリケーション機構（Ｆ　Ａ、　Ｆ　）に返され
、ここで各コード化データ・オブジェクトのドキュメン
ト索引が更新され、格納が正しく完了したことが示され
る。ＦＡＦとオブジェクト配布マネージャ（ＯＤＭ）は
、先に９用した出願特許に説明されている。フード化デ
ータ・オブジェクトはこうして顧客のアプリケーション
・システムで処理できるようになる。

ＦＡＦから、オーバレイ・イメージを用いるコード化デ
ータ・オブジェクトの表示要求が出されると、イメージ
・システム（ＯＤＭ）は、コード化データ・オブジェク
トとこれに関連するオーバレイ・イメージ（これを認識
するためにコード化データ・ヘッダを調べる）の両方の
検索をオブジェクト格納マネージャに要求する。コード
化データ・オブジェクトとオーバレイ・イメージはいず
れもイメージ・ワークステーションに送られる。

イメージ・ワークステーションのソフトウェアは、コー
ド化データとオーバレイ・イメージを合わせて（これも
コード化データーヘッダを調べることで認識される）、
２つをワークステーションの表示画面で併合するかどう
かを判定する。

ＣＤ５Ａの設計 コード化データ・ストレージ・コンポーネントの設計−
一機能概要 コード化データ・ストレージ・コンポーネント（ＣＤＳ
）は次の機能を実行する。

１、　　　ＣＤＳ処理パラメータを外部入力ファイルか
ら読み込む。

２、　格納コマンドをコード化データ・オブジェクトと
ともに外部入力ファイルから読み込む。

３、　要求されたオブジェクトをオブジェクト・アクセ
ス・メソッド（ＯＡＭ）に格納する。

４、　処理されたオブジェクトのすべてについて、レジ
スタ・コマンドを外部出力ファイルに書き込む。

５　　無効な格納コマンドをコード化データ・オブジェ
クトとともに例外出力ファイルに書き込む。

６、　　ＣＤＳ自体の処理操作についてレポートする（
管理、タイミング、処理の統計）。

ＣＤＳは上記の機能を、順次処理パラメータ・ファイル
と入力コマンド・ファイル、格納要求それぞれの結果を
記録する出力レジスタ・ファイル、および無効な格納コ
マンドをコード化データとともに格納した出力例外ファ
イルを用いて実行する。ＣＤＳの入出力の流れを第２図
に示す。

二社　の制・と仮 以下は、このコンポーネントを設計する上での制約と仮
定を示す。

コード化データは、外部ファイル（ＣＩＣ５の区画外−
時ファイル）を介して受信される。このファイルの属性
は可変順次レコードである。各コード化データ・レコー
ドは、所要の格納コマンドとこれに続くコード化データ
・オブジェクトを保つ、このプログラムでは、特別の順
序は想定されていない、設計上、入出力媒体（テープや
ディスク）は想定されていない、ただし、このコンポー
ネントにはテープを使用するのが望ましい。

コード化データは、オンライン・トランザクションでは
ＦＡＦから受信されることはない、ＣＤＳのトランザク
ションでは、区画外入力処理パラメータの待ち行列名が
与えられる。ＣＤＳ処理パラメータのフォーマットにつ
いては［特殊コンポーネント・データ領域」の節で説明
している。

コード化データの入力ファイルは、ユーザ管理レコード
および格納コマンドとコード化データ・オブジェクトを
格納したＣＤＳレコードの２種類のレコードを保つ、各
レコードのフォーマットについては「特殊コンポーネン
ト・データ領域」の節で説明している。

レジスタ出力ファイルは、入力ファイルからのユーザ管
理レコードとコード化データ・レジスタ・コマンドの２
種類のレコードを保つ、そのフォーマットについては［
特殊コンボーシト・データ領域］の節で説明している。

出力例外ファイルには、入力されたエラーのあるコード
化データ格納コマンド（戻りコードと理由コードが更新
されたもの）と、これを識別するため変更されたコマン
ド名が含まれる。この例外ファイルは、分析でき、次に
ＣＤＳが実行されるときの入力として再登録することも
できる。注：入力管理レコードがこの例外ファイルに書
き込まれることはない、ＣＤＳはオブジェクト・タイプ
−〇−（コード化データ）と”Ｄ“　（オーバレイ・デ
ータ）をサポートする。コード化データは、外部入力フ
ァイルを介して受信され、ＥＢＣＤ　Ｔ　Ｃフォーマッ
トである。コード化データのオーバレイフオームはワー
クステーションを通じて走査される。コード化データは
、ＯＡＭに格納される他のオブジェクトと互換性があり
、ＩＢＭによって定義されたアーキテクチャ・フォーマ
ットで転送される。エンベロープやドキュメントの操作
は行われない。

コード化データ・ファイルの処理はバッチ環境に適して
いる。ただしＯＡＭインターフェイスは。

ＣｌＣ５を通じてしか利用できない、したがって、この
設計では、区画外−時ファイルとの開で読み書きを行う
ＣｌＣ５アプリケーションの使用を想定している０区画
外ファイルは、復元できないｃｒｃｓ資源であり、よっ
てＰＤＬには簡単な再起動論理が追加される。コード化
、データのバックアップは必要ない、これはＯＡＭが自
動的に行う０分散環境では、各ＯＤＭかそれ自体のコー
ド化データしか受信しないと仮定されている。そのため
には、入力ファイルを作成するユーティリティが、その
ファイルの正しい宛先として、データを所有するＯＤＭ
を指定する必要がある。このアプリケーション・プログ
ラムは、コード化データ・レコードを順次に処理するよ
う設計される。

並列処理も可能である。

Ｗｉ上匹皇ＩＡ ＣＤＳコンポーネントは、ＣｌＣ５アプリケーション・
プログラムとして実行するよう設計される。以下の理由
から、コード化データを処理するためにｃｒｃｓ領域を
別に設けるのが望ましい。

１、　入力ファイルまたは出力ファイルがテープの場合
、ＯＤＭの主領域でウェイトが生じる可能性がなくなる
。

２、　分離したＣｌＣ５領域は、システムの他の部分に
干渉することな（、バッチ・ジョブまたは起動したタス
クとして所定の時間に起動できる。これは外部ファイル
が利用できるとき可能である。

３、　区画外ファイルを定義するＤＣＴの項目は、ファ
イル・オーブン初期モードでコード化でき、アプリケー
ション・プログラムから直ちに利用できる。

分離したｃｒｃｓ領域は、オペレータの介入を最少にし
て起動できる。これはバッチ端末を定義することで実行
できる。端末の入力はＪＣＬ　　ＤＤカードから読み取
られる。入力が指定されることで、トランザクションが
起動し、パラメータがプログラムに渡される。この領域
は処理の終了時に自動的に終了させることもできる。

コンポーネント・インターラエイス ＣＤＳは、ＯＡＭインターフェイスと連係する一−ＣＤ
ＳとＯＡＭインターフェイスによって、ＯＡＭに管理さ
れる記憶装置のオブジェクトが格納される。

１並互４ ＣＤＳプロセスは、単一レコードのオブジェクトを最大
速度で処理するよう高度化される。複数のレコードを持
つオブジェクトではオーバヘッドが加わる。

メモリ六Ｕの割り　で ＯＡＭコンポーネントでは、格納すべき各オブジェクト
にバッファが必要である。バッファのサイズはオブジェ
クトおよび追加される管理情報を合わせたサイズと等し
くなければならない、このバッファの記述はＣＤＳ入力
レコードの一部になる。３２にでプログラムを初期化す
る際、入力レコードを配置するためＧＥＴＭＡＩＮが一
度実行される。複数のレコード・オブジェクトを格納す
るときは、各レコードに３２にのバッファが割り当てら
れる。オブジェクトの作成に必要なレコードはすべて、
オブジェクトの格納前にこれらのバッファに読み込まれ
る。コード化データのオブジェクト・サイズは非常に小
さい（イメージによる）ため、このコンポーネントのメ
モリ空間は大きな問題にならない。

モジュールの定 ＣＤＳコンポーネントは、ＣｌＣ５領域においてアプリ
ケーション・プロセッサとして実行され、コード化デー
タ・プロセス（ＯＭＤＤＳＴＯＲ）と呼ばれる１つのモ
ジ１−ルで構成される。

コード　データ・プロセスＯＭＤＤＳＴＯＲ本本本＊＊
＊＊＊＊＊仕様＊＊＊＊＊本＊＊＊＊モジュール名：　
ＯＭＤＤＳＴＯＲ 記述名：コード記述−タ・プロセス 苔作権：ＩＢＭコーポレーション ステータス、バージョンｌリリース１ 機能：外部入力ファイルから受信されたコード化データ
を格納する。

動作： ■、　入力パラメータの待ち行列名を受信する。

２６　制御パラメータを読み込む。

３、　外部入力ファイルからコード化データの項目を読
み込む。

４、　　０ＡＭインターフェイスにオブジェクトの格納
を要求する。

５、　　レジスタの確認を外部出力ファイルに書き込も
。

６、　処理統計を含めて管理レポートを作成する。

復元動作： このプログラムは、復元不可能なＣｌＣ５資源である区
画外ファイルを用いる。このプログラムにより、ＣｌＣ
５５ＹＮＣＰＯＩＮＴがいつ出力されたかがレジスタ・
コマンド内に示される。

プログラムが起動すると、入力管理レコードからの再起
動パラメータと、後で再起動されるオブジェクト名がヂ
エツクされる。そのオブジェクト名より前のレコードは
読み込まれるが、処理はされない、オブジェクト名の突
き合わせが行われると、次のレコードから通常の処理が
再開される。

従属性：コード化データの可用性 モジュール・タイプ：プログラム プロセッサ：Ｃ０ＢＯＬ　　ＩＩ 属性：　ＡＭＯＤＥ　（３１）、ＲＭＯＤＥ　（ＡＮＹ
）ＤＡＴＡ　（３１） 戻りコード：なし 正常終了：ＣｌＣ５へ戻る。

異常終了： 資源の集結処理が行われ（バッファ、前の同期点へのロ
ールパック）、処理が終了する。

ｌ、　入力処理パラメータ・ファイル（区画外）−一人
力 ２、　入カドランザクジョン・ファイル（区画外）−一
人力 ３、　レジスタ出力ファイル（区画外）−一出力 ４、　　ＣＤＳ例外ファイル（区画外）−一出力５、　
　ＣＤＳ管理レポート（区画外）−一出力メッセージ：
ＴＢＤ ＡＢＥＮＤ　（タスク異常終了）コード：なし変更履歴
：初版 本本本本本本＊＊仕様終わり＊＊＊本本本本本本特殊コ
ンポーネント・データ領域、ニーコード化データ入カフ
アイル・フォーマット コード化データ入カフアイルの内容は次の２種類のレコ
ードである。

レコード・タイプ　　管理レコード・タイ使用ファイル
／待ち行列ニ ブの標識（ＣＮＴ Ｌ） 管理データ　　　　　ユーザが定義する管理レコード・
データ 注：管理レコード・データはユーザが定義する。管理レ
コードはレジスタ・レコード・ファイルに書き込まれる
。管理レコードの先頭８０バイトは管理レポートに書き
込まれる。

コマンド・コード ５ｙｓｉｄ ｔｓｙｓ　　ｉ　　ｄ ５ｙｓｉｄ セグメント番号 格納レコード・タイ プの標３１（ＳＴＲ Ｃ） 例外ファイルからの レコードを格納（Ｓ ＴＲＥ） 未使用 未使用 未使用 オブジェクトのセグ 戻りコード　　　　　戻りコードー−５ＴＨＥコマンド
のみ 理由コード　　　　　理由コード５ＴＲＥコマンドのみ ０５Ｍバッファ・セ グメシトの説明 セグメント長　　　　セグメント長（オブジェクト・デ
ータ＋ ８Ｅバイト］） 使用長　　　　　　　オブジェクト・データ・サイズ（
オブ ジェクト・データの 長さＥバイト］） オブジェクト・デー　コード化データ・才タ　　　　　
　　　　　ブジエクト・データレジスタ出力ファイル・
フォーマット レジスタ出カフアイルの内容は次の２種類のレコードで
ある。

１、宣ＥＩＬ／コニニ上 ２」ニ二り二り各　　　　　披贋 セグメント数 オブジェクト・サイ ズ ページ数 コピー・コード 一時ＩＤ オブジェクト名 オブジェクト・タイ プ 記憶クラス 管理クラス 維持期間 オブジェクトのセグ メシト合計 オブジェクト全体の サイズ（バイト・） オブジェクト全体の ページ数 コピー・コード＝Ｙ （コピーを格納） 一時ＩＩ）（ＴＥＭＰ ｒＤ） ＣＤＳオブジェクト 名 オブジェクト・タイ プのコード ０３Ｍ記憶クラス （オプション） ０３Ｍ管理クラス （オプション） Ｏ５Ｍ維持期間（才 レコード・タイプ レコード・データ 管理レコード・タイ プの標識（ＣＮＴ Ｌ） コード化データ入カ ファイルから読み込 まれるものと同じレ コード レコード・タイプ ５ｙｓｉｄ ｔｓｙｓ　　ｉ　　ｄ ５ｙｓｉｄ ページ数 オブジェクト名 オブジェクト・タイ 管理レコード・タイ プの標識（ＲＥＧ Ｃ） 未使用 未使用 未使用 オブジェクト全体の ページ数 ＣＤＳオブジェクト 名 オブジェクト・タイ ブ　　　　　　　　　　ブのコード −時Ｉ　Ｄ　　　　　　　ＴＥＭＰ　Ｉ　Ｄ戻りコード
　　　　　戻りコード 理由コード　　　　　理由コード コピー・コード　　　コピー・コード＝Ｙ（コピーを格
納） 同期点フラグ　　　　Ｙ＝このレコードの後の同期点 ＣＤＳトランザクション・パラメータ・ファイル・フォ
ーマット ＣＤ５）−ランザクジョン・パラメータは、８０バイト
の順次（レコードごとのキーワードによる）ファイルに
保、たれる。

１、コメント・レコード（不要） ２コニニＪＬ、　ｌ’各　　　値　　　　烈　　　豐　
　　話ＫＥＹＷＯＲ’＊’　　　　Ｉ　　　Ｙ　　コメ
ント。

Ｄ　　　　　　　　　　　　　　　　列ｌのアスタリス
クは コメント行 を示すため 充填文字　　　　　　　２−８ ２、同期点間隔レコード（必要） １Ｌ二互上洛　　値　　　烈 ＫＥＹＷＯＲ’ＳＹ　　ｌ二９ Ｄ　　　　　　　ＮＣＩ ＴＲ ＝　　　１ ＳＹＮＣＩＮ　　−９９１Ｏ− ＴＲ９９１４ に用いられ る。

コメント 誓　　　匪」 Ｙ　同期点間隔 キーワード 充填文字　　　　　　　１４−ｎ ３、エラーしきい値レコード（必要） ７＜二基上Ｌ　　値　　　烈　　要 ＫＥＹＷＯＲＥＲｌ−９Ｙ Ｄ　　　　　　　ＲＴＨ 同期点が取 られる前に 処理される レコード数 コメント ロ エラーしき い値キー ＥＳ ワード ＲＲＴＨＲ Ｓ 充填文字 １０−Ｙ　処理が終了 １４　　　　する前のシ ステム・レ コード以外 のエラー数 １４−　　　コメント ４、ＣＤＳ入力待ち行列レコード（必要）ニエニ左上渚
　　値　　　烈　　！　　披見ＫＥＹＷＯＲＩＮ　　１
−９　　Ｙ　　ＣＤＳ入力Ｄ　　　　　　ＣＤＡ　　　
　　　待ち行列ＴＡＱ　　　　　　　　　キーワード ＩＮＣＤＡＴ　　（待ち　ｉｏ−ｙ　　区画外待ちＡＱ
　　　　　　行　列　１７　　　　行列名を人名）　　
　　　　　　力 充填文字　　　　　　　１８−ｎ　　コメント５、ＣＤ
Ｓレジスタ待ち行列レコード フィールド名　　値　　　烈　　誓　　話ＫＥＹＷＯＲ
００１−９Ｙ　　ＣＤＳレジＤ　　　　　　　ＴＲＥ　
　　　　　　　スタ待ち行ＧＩＱ　　　　　　　　列キ
ーワー ＝ド ０ＵＴＲＥＧ　　（待ち　［０−Ｙ　　レジスタのＩＱ
　　　　　　行　列　１７　　　　区画外待ち名）　　
　　　　　　行列名を出 力 充填文字　　　　　　　１８−ｎ　　コメント６、ＣＤ
Ｓ例外待ち行列レコード（必要）２コニニに二り名　　
　値　　　　　烈　　　要　　　説」五ＫＥＹＷＯＲＯ
Ｕ　　１−９　　Ｙ　　ＣＤＳ例外例外　　　　ＴＥＸ
　　　　　　待ち行列ＣＰＱ　　　　　　　　キーワー
ド ＯＵＴＥＸＣ（待ち　１０−　　Ｙ　　例外の区画ＰＱ
　　　　　　行　列　１７　　　　外待ち行列名）　　
　　　　　　名を出力 充填文字　　　　　　　１８−　ｎ　コメント７、ＣＤ
Ｓレポート待ち行列レコード（必要）フィールド名　　
値　　　烈　　！　　話ＫＥＹＷＯＲ’００　１−９　
　Ｙ　　ＣＤＳしＤ　　　　　　　ＴＲＰ　　　　　　
　　ポート待ちＲＴＱ　　　　　　行列キー ＝　　　　　　　　　　ワード ０ＵＴＲＰＲ（待ち　１０−　　Ｙ　　レポート区ＴＱ
　　　　　　行　列　１７　　　　画外待ち行名）　　
　　　　　　列名を出力 充填文字　　　　　　　１８−ｎ　　コメント８、再起
動フラグ・レコード（不要） ム土二互上Ｌ　　値　　　烈　　要　　晟」ＫＥＹＷＯ
Ｒ’Ｒ５１−９Ｙ　　再起動フラＤ　　　　　　ＴＲＴ
　　　　　　グ・キーＦＬＧ　　　　　　　　　ワード ＲＳ　　Ｔ　　Ｒ１’　　Ｆ Ｇ 充填文字　　　　　　　１１− ９、再起動オブジェクト名しコ ＊参照） 二二二互上渚　　値　　　烈 ＫＥＹＷＯＲＲＯ１−９ Ｄ　　　　　　　ＢＪＮ ＭＥ ＲＯＢＪＮＡ　　（才ブ　１０− Ｅ ジエク　４９ ト名） 充填文字 Ｙ＝ＣＤＳ の処理が再 起動されて いる 注：デフォ ルトはＮ コメント ド（不要−一注 ！　　　託コ 再起動オブ ジェクト名 キーワード ネ 後で再起動 するオブ ジェツトの 名前 コメント 注水：再起動フラグ・レコードがＲＳＴＲＴＦＬＧ＝Ｙ
でコード化されている場合は、ＲＯＢＪＮＡＭＥでコー
ド化した再起動オブジェクト名レコードが必要である。

管理レポート出力レポート・フォーマットＣＤＳ処理管
理レポート 実行日−−９９−９９−９９ 実行時間−−９９：　９９　：　９９ セクションｌ：処理パラメータ 同期点間隔　　　　　　＝９９９９ エラーしきい値　　　　＝９９９９ ＣＤＳ入力待ち行列　　＝ｘｘｘｘｘｘｘｘＣＤＳ例外
待ち行列　　＝ｘｘ例外ｘｘｘｘＣＤＳレポート待ち行
列＝ｘｘｘｘｘｘｘｘ再起動フラグ　　　　　＝Ｘ 再起動オブジェクト名　＝ｘｘｘｘｘｘｘｘｘｘｘｘｘ
ｘｘｘｘｘｘｘ ｘｘｘｘｘｘｘｘｘｘ ｘｘｘ セクション２：エラー・レポート 管理レコード、 ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ
ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ
ｘｘｘｘｘｘｘｘｘｘ エラー：　　ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ
ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ ｘｘｘ エラー：　　ｘｘｘｘｘｘｘｘｘｘｘ、、ｘｘｘｘｘｘ
ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ ｘ セクション３　：　ＣＤＳ処理統計 ＣＤＳ処理終了−一戻りコード９９９９　理　由コード
９９９９ 人力　　読み込みレコード数−９，９９９，９９格納さ
れたバイト数合計−９９９，９９９，９９読み込み管理
レコード数−９，９９９゜読み込みコード化データ格納
５ＴＲＣレコード数−９，９９９，９９９ 読み込みコード化データ格納５ＴＲＥレコード数−９，
９９９，９９９ 正常に格納されたオブジェクトｌ−９，９９９゜例外フ
ァイルに書き込まれたオブジェクト数−９，９９９，９
９９ 複製オブジェクト−エラー数−９，９９９，９９９ コマンド検証エラー数−９，９９９，９書き込まれた出
力レコード数 書き込まれた管理レコード数−９，９９９，９９９ 書き込まれたレジスタ・レコード数− ９，９９９，９９９ Ｋ ページ数合計−９９９，９９９，９９９，９９９経過時
間合計（ＯＳＭ）−ｈｈ：ｍｍ：ｓｓ経過時間合計（Ｃ
ＤＳ）−ｈｈ　：ｍｍ：　ｓｓこのような機構によって
デジタル・イメージと英数字列を併合することにより、
多様な情報を従来技術よりも効率的に自動的に併合する
ことかできる。

Ｆ４発明の効果 本発明によれば、キャラクタ・データ・ストリームとデ
ジタル・イメージ・ファイルを、効率よく自動的にマー
ジすることが可能になる。

【図面の簡単な説明】

第１図は１本発明によるコード化データ・ストレージ・
プロセッサを含むデジタル・イメージ保管システムの機
能ブロック図である。 第２図は１本発明によるコード化データ・ストレージ・
プロセッサの入出力の流れを示す詳細ブロック図である
。 第３図は、本発明による動作シーケンスの流れ図である
６ 第４図は、未記入申請書のイメージを示す図である。 第５図は、フォーマット・データ・セットを示す図であ
る。 第６図は、端末へのカスタム・データの入力を示す図で
ある。 第７図は、３つのデータ・セットのカスタム・データ・
セットを示す図である。 第８図は、フオームイメージ・ファイルとカスタム・デ
ータ・セットの相対サイズを示す図である。 第９図は１文字の配置を示し、特にフオームイメージ・
ファイルと併合される英数字のピクセル・ビット・イメ
ージのベースラインの位置づけを示す図である。 第１Ｏ図は、記入済み申請書のイメージを示す図である
。 ゝｒ ト コ− ）１ト ＦＩＧ、　６ 端末でのカスタム・データ入力 ＦＩＧ、　７ カスタム・データ・セット

Claims (4)

【特許請求の範囲】
1. （１）キャラクタ・データ・ストリームとデジタル・イ
   メージ・ファイルをマージする方法であって、 デジタル・イメージ・ファイルを第１の入力端末に入力
   して第１の記憶媒体に格納するステップと、 キャラクタ列を第２の入力機構に入力して第２の記憶媒
   体に格納するステップと、 第２の記憶媒体に格納されたキャラクタ列をピクセル・
   ビット・イメージに変換するために、前記キャラクタ列
   の各キャラクタをピクセルの２次元ビット・パターンに
   置き換えるステップと、各キャラクタの前記ビット・パ
   ターンと前記デジタル・イメージを、前記デジタル・イ
   メージの領域の所定のキャラクタ位置で論理的に組み合
   わせるステップと、 前記論理的組合せの結果前記キャラクタが重ね合わされ
   たデジタル・イメージを出力するステップとを有する、
   キャラクタ・データ・ストリームとデジタル・イメージ
   ・ファイルとのマージ方法。
2. （２）デジタル・イメージ・ファイルを格納するシステ
   ムにおいて、キャラクタ列を組み合わせて前記デジタル
   ・イメージ・ファイルに重ね合わせる装置であって、 前記デジタル・イメージを入力する第１の入力装置と、 前記デジタル・イメージをデータ・ファイルとして格納
   する第１の記憶装置と、 キャラクタ列を入力する第２の入力手段と、前記キャラ
   クタ列を格納する第２の記憶装置と、 前記キャラクタ列の各キャラクタを対応するピクセル・
   ビットのパターンに変換して、前記各キャラクタの２次
   元イメージを生成する変換手段と、 前記各キャラクタのピクセル・ビット・パターンを前記
   デジタル・イメージ・ファイルと論理的に組み合わせて
   前記イメージ・ファイルと前記キャラクタとを重ね合わ
   せたイメージを形成する論理的組合せ手段と、 前記重ね合わされたイメージを出力する出力手段とを有
   する、装置。
3. （３）キャラクタ・ワークステーションからのキャラク
   タ列を転送し、前記キャラクタ・ワークステーションに
   通信リンクを介して接続され、かつ全点アドレス指定可
   能表示装置を持つグラフィクス・ワークステーションで
   表示するシステムであって、 キャラクタ列を入力する前記キャラクタ・ワークステー
   ション側の入力手段と、 前記キャラクタ・ワークステーションを変換手段につな
   ぐ第一の通信リンクとを有し、 前記変換手段は、前記キャラクタ列の各キャラクタを、
   前記各キャラクタの２次元イメージを表す対応するピク
   セル・ビット・パターンに変換するものであり、 さらに、前記変換手段をグラフィクス端末に接続して、
   前記キャラクタを表わす前記ピクセル・ビット・パター
   ンを前記グラフィクス・ワークステーションに転送する
   第２の通信リンクと、前記第２の通信リンクを介して受
   信された各キャラクタのピクセル・ビット・パターンを
   表示する、前記グラフィックス・ワークステーション側
   の全点アドレス指定可能表示装置を含む表示手段とを具
   備する、システム。
4. （４）データ処理システムにおいてフォームを作成する
   方法であって、 複数の空白領域を含むフォームを媒体内に作成するステ
   ップと、 前記フォームのデジタル・イメージをフォーム・イメー
   ジ・ファイルとして前記データ処理システムに取り込む
   ステップと、 前記フォーム・イメージ・ファイルを第１のファイル名
   で前記データ処理システムに格納するステップと、 前記フォームの前記空白領域ごとに名前データと位置デ
   ータを入力して、前記第１のファイル名をフォーマット
   ・データ・セットに関連づけるステップと、 前記フォーマット・データ・セットを第２のファイル名
   で前記データ処理システムに格納するステップと、 前記フォーマット・データ・セットをアクセスするステ
   ップと、 前記複数の空白領域のいずれかに追加しようとするキャ
   ラクタ列を入力するステップと、 前記第１のファイル名、前記キャラクタ列および前記位
   置データを含むカスタム・データ・セットをまとめ、格
   納するステップと、 前記カスタム・データ・セットをアクセスするステップ
   と、 前記カスタム・データ・セットから前記第１のファイル
   名を抽出するステップと、 前記第１のファイル名によって前記フォーム・イメージ
   ・ファイルをアクセスするステップと、前記キャラクタ
   列を、前記キャラクタ列によって表されるキャラクタの
   ピクセル・ビット形状に変換するステップと、 前記ピクセル・ビット形状と前記フォーム・イメージ・
   ファイルとを、前記カスタム・データ・セットの前記位
   置データによって指定された位置にてマージするステッ
   プとを有する、方法。