(57)【特許請求の範囲】
【請求項１】
ネットワークを介して少なくとも１つのホスト装置を含む周辺機器と接続可能であり、前記ホスト装置との双方向通信を行う通信手段を有する画像形成装置であって、
前記周辺機器よりダウンロードしたフォントデータを、１つの書体に対して複数のフォントデータに分割して記憶する記憶手段と、
前記記憶装置に記憶されたフォントデータをバッファに登録する登録手段と、
前記記憶装置に記憶された複数のフォントデータの中から特定のフォントデータを判断する判断手段とを備え、
前記判断手段によって特定のフォントデータと判断されたフォントデータのみを、前記登録手段によりバッファに登録させ、該バッファに登録されたフォントデータを前記通信手段によって前記ホスト装置に送信させるフォントマネージャを有することを特徴とする画像形成装置。
【請求項２】
請求項１記載の画像形成装置において、
前記フォントマネージャは、前記ホスト装置におけるフォントデータ記憶領域の残り容量を取得する手段と、
取得した前記ホスト装置におけるフォントデータ記憶領域の残り容量が前記登録手段によってバッファに登録されたフォントデータ量より小さいか、否かをチェックする手段とをさらに備え、
前記チェック手段によって、フォントデータ記憶領域の残り容量がバッファに登録されたフォントデータ量より小さいことがチェックされたことを条件に、特定のフォントデータと判断されたフォントデータのみを前記ホスト装置に送信させる動作を行うことを特徴とする画像形成装置。
【請求項３】
請求項２記載の画像形成装置において、
前記フォントマネージャは、前記チェック手段によって、フォントデータ記憶領域の残り容量がバッファに登録されたフォントデータ量以上であることがチェックされたことを条件に、前記バッファに登録された全てのフォントデータを前記ホスト装置に送信させる動作を行うことを特徴とする画像形成装置。
【請求項４】
請求項２記載の画像形成装置において、
前記フォントマネージャは、前記周辺機器よりダウンロードしたフォントデータに対し書体単位で使用頻度をカウントする手段をさらに備え、
前記ホスト装置におけるフォントデータ記憶領域の残り容量が前記登録手段によってバッファに登録されたフォントデータ量以上になるまで、前記カウント手段によってカウントした使用頻度の高い順に、前記登録手段によりフォントデータをバッファに登録させ、バッファに登録された全てのフォントデータを前記ホスト装置に送信させる動作を行うことを特徴とする画像形成装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ファックス・スキャナ・複写機・複合機等の画像形成装置に関し、ネットワークを介して少なくとも１つのホスト装置を含む周辺機器と接続可能にして、周辺機器からダウンロードしたフォントデータを効率良く運用するために、保有するフォントデータ中の特定のデータをホスト装置に送信する機能を備えたフォントマネージャを有する画像形成装置に関する。
【０００２】
【従来の技術】
従来、フォントマネージャは、ＤＴＰ技術の普及により多くのプリンタ等において採用されている。このフォントマネージャの適用により、ホストの所持するフォントをダウンロードすることで、ホストのフォントデータを使用し、ホストのディスプレイ表示と同じ印字が可能になる。また、ネットワーク上で使用されるプリンタでは、他の周辺機器からフォントデータを相互にやりとりすることも一般的となってきている。
【０００３】
ところで、ホストや他の周辺機器よりダウンロードされたフォントは、システム内蔵のハードディスクやフロッピーディスク等の外部記憶装置に通常置かれ、使用時にＲＡＭ上にロードされてフォント展開される。外部記憶装置を置くメリットは、大容量のデータを格納出来ることにあるが、処理する際のアクセススピードが半導体メモリに比べ遅くなる欠点がある。
そこで、この問題点を解消するために、使用頻度の高いフォントをすぐ引き出せるように、ＲＡＭ上にフォント辞書を置くなどの処置が取られている。
【０００４】
このように、プリンタ側が多数のフォントを所持するようになったことに対し、ホスト側もそのフォントを使いこなす為、様々な方法でプリンタが所持するフォントを把握する機能を持っている。その１つの例として、ネットワーク上のプリンタと接続する度に、自動的にそのプリンタが持つ全フォントの名称を抽出し、フォントテーブルをファイルにして管理するアプリケーションが存在する。このようなアプリケーションは、その時々の環境において、ユーザへ使用可能なフォントの範囲を最大限広げる機能を提供出来る。
【０００５】
本願発明と技術分野が類似する従来技術例として、外部記憶装置を有する場合のフォントハンドリングの一例として、特開平３−１７４５８８号公報の「文書処理装置」がある。また、フォントデータをホストとプリンタ間で共有する方法の一例として、特開平２−１１３９６４号公報の「文字データ出力装置および方法」がある。
【０００６】
【発明が解決しようとする課題】
しかしながら、上記の従来例において、一見、プリンタフォントの自動抽出は、ユーザにとってもホスト側のシステムにとっても有効な機能といえる。ところが、現時点において、当機能には大きな問題点がある。
【０００７】
つまり、プリンタから抽出したデータはホスト側で用意した特定の領域に保管されるが、当然保管領域には容量の限界がある。しかも、現在本機能を持つアプリが用意しているフォントテーブルの領域は固定サイズであり、あまりにプリンタ側が多量のフォントを所持している場合、ホスト側がオーバーフローを起こしてしまう。この時、せっかくの機能が使い物にならないばかりか、システム全体に悪影響を及ぼすことさえある。
【０００８】
本発明は、効率的なフォント自動抽出機能を具備したフォントマネージャを有する画像形成装置を提供することを目的とする。
【０００９】
【課題を解決するための手段】
かかる目的を達成するため、ネットワークを介して少なくとも１つのホスト装置を含む周辺機器と接続可能であり、前記ホスト装置との双方向通信を行う通信手段を有する請求項１記載の発明に係わる画像形成装置は、前記周辺機器よりダウンロードしたフォントデータを、１つの書体に対して複数のフォントデータに分割して記憶する記憶手段と、前記記憶装置に記憶されたフォントデータをバッファに登録する登録手段と、前記記憶装置に記憶された複数のフォントデータの中から特定のフォントデータを判断する判断手段とを備え、前記判断手段によって特定のフォントデータと判断されたフォントデータのみを、前記登録手段によりバッファに登録させ、該バッファに登録されたフォントデータを前記通信手段によって前記ホスト装置に送信させることを可能とするフォントマネージャを有することを特徴としている。
【００１０】
また、請求項２記載の発明は、請求項１記載の画像形成装置において、前記フォントマネージャは、前記ホスト装置におけるフォントデータ記憶領域の残り容量を取得する手段と、取得した前記ホスト装置におけるフォントデータ記憶領域の残り容量が前記登録手段によってバッファに登録されたフォントデータ量より小さいか、否かをチェックする手段とをさらに備え、前記チェック手段によって、フォントデータ記憶領域の残り容量がバッファに登録されたフォントデータ量より小さいことがチェックされたことを条件に、特定のフォントデータと判断されたフォントデータのみを前記ホスト装置に送信させる動作を行うことを特徴とするものである。
【００１１】
また、請求項３記載の発明は、請求項２記載の画像形成装置において、前記フォントマネージャは、前記チェック手段によって、フォントデータ記憶領域の残り容量がバッファに登録されたフォントデータ量以上であることがチェックされたことを条件に、前記バッファに登録された全てのフォントデータを前記ホスト装置に送信させる動作を行うことを特徴とするものである。
【００１２】
また、請求項４記載の発明は、請求項２記載の画像形成装置において、前記フォントマネージャは、前記周辺機器よりダウンロードしたフォントデータに対し書体単位で使用頻度をカウントする手段をさらに備え、前記ホスト装置におけるフォントデータ記憶領域の残り容量が前記登録手段によってバッファに登録されたフォントデータ量以上になるまで、前記カウント手段によってカウントした使用頻度順に、前記登録手段によりフォントデータをバッファに登録させ、バッファに登録された全てのフォントデータを前記ホスト装置に送信させる動作を行うことを特徴とするものである。
【００１３】
【発明の実施の形態】
次に添付図面を参照して本発明によるフォントマネージャを有した画像形成装置の実施の形態を詳細に説明する。図１〜図８を参照すると本発明に係わるフォントマネージャの一実施形態が示されている。図１〜図３が実施形態のフォントマネージャが適用されるプリンタの構成例を示し、図４〜図７が動作例を示し、図８は書体の構成例を概念的に表した図である。
【００１４】
図２は、本実施形態のフォントマネージャが適用される所定の装置であるプリンタの、レーザプリンタ本体における内部機能の全体構成図である。
図中符号１０で示すものは、レーザプリンタ装置本体である。装置本体１０の内には、ほぼ中央にベルト上の感光体１１を設ける。その感光体１１のまわりには、図中矢印で示す駆動方向に順に、帯電チャージャ１２、現像ユニット１３、転写チャージャ１４、クリーニング器１５があり、さらに、現像ユニット１３の上側には光書き込み器１６を配置し、装置本体１０図中下側にはシートを収納した給紙カセット１７を着脱自在に取り付ける。
【００１５】
そして、給紙コロ１８を回転して給紙カセット１７内からシートを図中矢印方向に送り出し、タイミングをとってレジストローラ対１９で感光体１１の下側に搬送する。
【００１６】
感光体１１は、矢印で示す時計方向に駆動し、その際、帯電チャージャ１２によって表面を一様に帯電し、その後光書き込み器１６からのレーザ光を照射して感光体ユニット１１上に静電潜像を形成する。この潜像は、現像ユニット１３位置を通るときトナーによって可視像化する。そして、この可視像は、感光体１１の下側に搬送されてきたシートの上面に転写チャージャ１４により転写する。
【００１７】
そして、画像転写後のシートを定着器２０に搬送し、その定着器２０で転写画像を定着する。そして、定着器２０を出たシートは、ＦＤ／ＦＵ（フェイスダウン／フェイスアップ）切替えソレノイド爪２４により、フェイスダウン搬送路２１内を搬送し、フェイスダウン排紙ローラ対２２によってフェイスダウン排紙トレイ２３上へと記録画を下にしたフェイスダウンで排出したり、そのままフェイスアップ排紙トレイ２５上へと記録面を上にしたフェイスアップで排出される。
他方、画像転写後の感光体１１は、クリーニング器１５で残留トナーを除去する。
【００１８】
図３は、本実施形態が適用されるプリンタ装置の回路構成例を示すブロック図である。
図３において、１はデータを送受信するホストコンピュータ、２はレーザプリンタ本体、３は画像処理を行うコントローラ、４はエンジンを制御するエンジン制御ボード、５は画像形成を行うエンジンである。
【００１９】
エンジン５中の２６はＬＤ（レーザダイオード）やポリゴンモータ等を含むレーザ書き込みユニット、２７は定着系・現像系・駆動系のエンジンシーケンスを司る部分であるシーケンス機器群、２８はペーパーパス上や、シーケンス状態をチェックするセンサ類である。
【００２０】
レーザプリンタ２中の３１は、プログラムＲＯＭのプログラム、操作パネルからのモード指示、ホストからのコマンド等によりエンジン全体を制御するＭＰＵである。また、３２はエンジンの制御プログラムが格納されているメモリ（ＲＯＭ）、３３はＣＰＵのワークメモリとなる入力データのインプットバッファメモリ（ＲＡＭ）、３４はホストコンピュータとコントローラ間の入出力インターフェイス（Ｉ／Ｏ）、３５は操作パネルである。
【００２１】
エンジンドライバ４中の、４１は、プログラム、操作パネルからのモード指示およびコントローラ３からのコマンドによってエンジン５全体を制御するＣＰＵである。また、４２はエンジン５の制御プログラムが格納されているメモリ（ＲＯＭ）、４３はＣＰＵのワークメモリ、入力データのインプットバッファ（ＲＡＭ）、４４はエンジンとコントローラ間の入出力インターフェイス（Ｉ／Ｏ）である。
【００２２】
図１は上記レーザプリンタ２のコントローラ３に相当するプリンタコントローラ１００の詳細構成を示すブロック図である。
図１において、１０１は、プログラムＲＯＭ１０４のプログラム、パネル装置からのモード指示、ホスト装置からのコマンドによってコントローラ全体を制御する、ＣＰＵである。
１０２は、フォントデータや、プログラムを外部から供給するＩＣ  Ｃａｒｄである。
１０３は、パネル装置からのモード指示の内容などを記憶しておく不揮発性記憶装置であり、ＮＶＲＡＭである。
１０４は、コントローラの制御プログラムが格納されているプログラムＲＯＭである。
【００２３】
１０５は、フォントのパターンデータなどを記憶するフォントＲＯＭである。
１０６は、ＣＰＵ１０１のワークメモリ、入力データのインプットバッファ、プリントデータのページバッファ、ダウンロードフォント用のメモリ等に使用するＲＡＭである。
１０７は、エンジン１０８とコマンドおよびステータスや、印字データの通信を行うエンジンインタフェースである。
１０８は、実際に印字を行うエンジンである。
１０９は、パネル装置１１０とコマンドおよびステータスの通信を行うパネルインタフェースである。
【００２４】
１１０は、使用者に現在のプリンタの状態を知らせたり、モード指示を行ったりする、パネル装置である。
１１１は、ホスト装置１１２と通信を行うホストインタフェースであり、通常はセントロＩ／ＦやＲＳ２３２Ｃである。
１１２は、プリンタの上位装置である、ホスト装置である。
１１３は、ディスク装置１１４と通信を行う為のディスクインタフエースである。
１１４は、フォントデータや、プログラムや、印字データなどの様々なデータを記憶しておくディスク装置であり、フロッピディスク装置やハードディスク装置などである。
【００２５】
上記によって構成されるプリンタは、ネットワーク上で多量のフォントデータを扱うプリンタ装置を想定して構成されている。このプリンタ装置において、本実施形態のフォントマネージャが適用され、フォントデータを扱う際のフォントマネージメントに関わる動作を実行する。以下にその動作例を説明する。
【００２６】
＜動作例１＞
動作例１は、ホストからの要求に従いプリンタ内のフォント一覧を返信する際、プリンタが保持するフォントデータが多過ぎて、ホスト装置側（アプリ）が用意した受け皿領域に吸収しきれないような場合を考慮している。この様な事態の発生において、使用頻度の高いＲＯＭ上フォントおよびユーザが意図的にフォント辞書に登録しているフォントを優先的に選択する。このことで、むやみに多量なフォントデータを送信する無駄や、その無駄な動作の為に不本意にも発生する受け皿領域のオーバーフローを回避するものである。
【００２７】
図４は、動作例１を示したフローチャートである。
図４において、ホストよりフォント抽出命令を受信すると（Ｓ１０）、まず、プリンタに最初から組み込まれているＲＯＭ上フォントを全て読み出し（Ｓ１１）、プリンタ内のバッファへフォント名を登録する（Ｓ１２）。さらに、ＲＡＭ上にフォントが有る場合は（Ｓ１３／Ｙｅｓ）、ＲＡＭ上のフォントを順次読み出し（Ｓ１４）、バッファへ登録する（Ｓ１５）。この時、ＨＤＤ，ＦＤ等の外部記憶装置にあるものでもＲＡＭ上に登録されていないフォントは対象外となる。
【００２８】
バッファへの登録が終了したところで（Ｓ１４／Ｙｅｓ）、ホストへ「フォント一覧」として返送する（Ｓ１６）。
なお、フローチャート中の点線枠Ａと★印は、後述する動作例４への流用範囲および箇所を示すためのものである。
【００２９】
上記の動作例１において、ホスト側（アプリ）がプリンタの保持するフォント名一覧を欲する理由は、ユーザにより幅広いフォントの選択権を提供する為であり、掲示するフォントは快適な使用環境を保証出来るものでなければならない。この理由は下記による。
【００３０】
プリンタにおいて、ＲＯＭ上にあるフォントは使用頻度の高さ故、フォント展開スピードを最大限上げる為内蔵されている。また、ユーザが意図的に辞書登録しているフォントは、ユーザの要求に対応すべくアクセス効率を上げる為ＲＡＭに登録している。この２つのフォントに対しては、高速に美しい印字が可能なので快適な使用環境が保証されているといってよい。
【００３１】
しかし、外部記憶装置登録のフォントは印字速度に若干問題があり、かならずしも快適に使用出来るとはいいきれない。データ量の多いフォントの場合、かなり低速になってしまうことがあるからである。このようなフォントを多数ユーザに提示するのは、いたずらに混乱させる恐れがある。本動作例１では、快適な使用環境を保証出来るフォントしかホストに通知しないので、ユーザはアプリが提示するフォント全てを安心して選択出来る。
【００３２】
同時に、あまり使用環境の良くないフォントの多量送信で発生していたホスト側のオーバーフローの回避、および、無駄な送信動作によるホスト専有時間の短縮化にも効果がある。
【００３３】
＜動作例２＞
図５は動作例２を表したフローチャートである。また、図８は書体の構成例を概念的に表した図である。ある書体が図８のように３フォントからなる書体だと仮定する。このように同じ書体でありながら、複数のフォントに分割されている書体が少なからず存在する。複数のフォントからなる書体は、各々のフォント名とは別にそれらを統括する書体名をもっている。よって、１書体１フォントの場合は、フォント名と書体名は同一である。
【００３４】
今、仮に複数のフォントを統括する書体を親フォント、親フォントを構成する各々のフォントを子フォントと呼ぶなら、フォント選択時に必要なのは親フォントだけであり、子フォントを用いるのはフォント展開時プリンタ内部での処理の時である。そして、ホストが出力先のフォントテーブルを作成する際必要としているのも、親フォントの名称である。
【００３５】
図５において、ホストよりフォント抽出命令を受信し（Ｓ２０）、フォント読み出しを開始する。フォントを読み出しながら（Ｓ２１）、親フォントかどうか判断し（Ｓ２２）、もし、親フォントなら（Ｓ２２／Ｙｅｓ）プリンタ内のバッファへフォント名を登録する（Ｓ２３）。子フォントは読みとばしていく（Ｓ２２／Ｎｏ）。全てのフォントを読み出したら（Ｓ２１／Ｙｅｓ）、バッファをホストへ「フォント一覧」として返送する（Ｓ２４）。
なお、フローチャート中の点線枠Ｂと★印は、後述する動作例４への流用範囲および箇所を示すためのものである。
【００３６】
動作例２において、欧文フォントに比べ和文フォントは１つの書体に含まれる文字数およびデータ量が格段に多い。よって同じ書体でありながら数個のフォントに分かれて存在している。このように複数に分割されているフォントも元々は１つの書体であるから代表名称である親フォント名さえわかっていれば、プリンタ内においてフォントを選択するレベルでは差し支えが全くない。
【００３７】
ところで、ホスト側（アプリ）がプリンタの保持するフォント名一覧を欲する理由は、ユーザにより幅広いフォントの選択権を提供する為である。つまり、どんな書体が使用可能であるかわかり、プリンタへ使用したい書体を指示することが出来れば充分である。
【００３８】
動作例２では、プリンタとホスト双方が必要とする最低限の情報（親フォント名）を抽出したデータが用意出来るので、メモリ効率も作業効率も上げることが可能になる。同時に、不必要な子フォント名の多量送信で発生していたホスト側のオーバーフローの回避、および、無駄な送信動作によるホスト専有時間の短縮化にも効果がある。
【００３９】
＜動作例３＞
図６は動作例３を表したフローチャートである。
動作例３では、ホストからの要求に従いプリンタ内のフォント一覧を返信する際（Ｓ３６）、プリンタが保持するフォントデータが多過ぎて（Ｓ３４／Ｎｏ）、ホスト側（アプリ）が用意した受け皿領域に吸収しきれないような場合を考慮し、ホストが必要としている親フォント名だけを抜き出し（Ｓ３３）、不必要に多量な子フォント名を送信する無駄や、その無駄な動作の為に不本意にも発生する受け皿領域のオーバーフローを回避する手順を提供するものである。
【００４０】
図６において、ホストからの要求に従いプリンタ内のフォント一覧を返信する際、ホスト側（アプリ）が用意した受け皿領域に吸収しきれない程プリンタ側からフォントデータの送信が行われ、不本意なオーバーフローを起こす原因は、無駄なデータの送信とプリンタ側が送信データ量に制限を持っていないことにある。
本動作例３は、プリンタ側が送信するデータ量の目安として、データを受ける側（ホスト側）の容量限界を把握する手順を設けている（Ｓ３１）。
【００４１】
動作例３は以下の効果を有する。
ホスト側のプリンタフォントの自動抽出機能の欠点は、当機能で相互の情報交換が円滑に行われていないことにある。本動作例３により、送信データの上限が明確になるので、プリンタ側でデータ量に制限を加えることが可能になり、不用意に多量データを送ってホストをオーバーフローさせるような危険は回避出来る。さらに、ホスト／プリンタ間のデータ交換もよりスムーズになることが期待出来る。
【００４２】
＜動作例４＞
動作例４では動作例３のフローチャートを流用する。
動作例４は、動作例３の手段によりデータを受ける側（ホスト側）の容量限界を事前に把握し、情況に応じた抑制方法でオーバーフローを回避しつつ要求データを得る手段を提供するものである。
【００４３】
図６において、ホストよりフォント抽出命令を受信すると（Ｓ３０）、まず、ホストへ回避データ受け皿領域のサイズ確認を行う（Ｓ３１）。その上で全フォントを読み出し（Ｓ３２）、バッファへ登録していく（Ｓ３３）。受け皿のサイズと全フォントを抽出したバッファのサイズを比較した結果（Ｓ３４）、もし、バッファサイズの方が大きければ（Ｓ３４／Ｎｏ）、動作例１または動作例２の方法（図４の動作Ａ／図５の動作Ｂ参照）で抑制を加えながら再度フォント名抽出を行う（Ｓ３５）。この時、動作Ａ／動作Ｂの★印の箇所でバッファサイズをチェックし、容量限界を越えないようにする。フォントを全て読み出すか又はバッファサイズが容量限界に達したところで、バッファを閉じ、ホストへ「フォント一覧」として返送する（Ｓ３６）。
【００４４】
動作例４での効果は、動作例３における送信データの上限が明確になり、動作例１および２の運用をより有効的に行える点にある。
【００４５】
＜動作例５＞
図７は、動作例５のフローチャートを示している。
本動作例５は、動作例４において２度手間になっている動作（１度全フォントを読み出したのち、バッファサイズを確認し、オーバーフローの危険があれば、再度抑制を加えて読み直しする）の無駄と、ホストが欲しているのは親フォントだけであることを考慮し、より効率よく要求データを得る手段を提供するものである。
【００４６】
フォントマネージャは、ダウンロードフォントに対して使用する度書体単位で使用頻度をカウントしておき、ホストよりフォント抽出命令を受信すると（Ｓ４０）、まず、ホストへ回答データを受け皿領域のサイズ確認を行う（Ｓ４１）。そして、ＲＯＭ上フォントを全て読み出し（Ｓ４２）、プリンタ内のバッファへ登録する（Ｓ４３）。その後、ＲＡＭおよび外部記憶装置に登録されたダウンロードフォントに対して、使用頻度とバッファサイズを確認しながら、親フォントをプリンタ内のバッファへ登録していく（Ｓ４４〜Ｓ４８）。フォントを全て読み出すか又はバッファサイズが容量限界に達したところで（Ｓ４４／Ｙｅｓ）、バッファを閉じ、ホストへ「フォント一覧」として返送する（Ｓ４９）。
【００４７】
動作例５の効果として、プリンタ側にとっては、送信データの上限が明確になった上で、使用頻度順にフォントが選択可能であり、しかも必要最低限の情報量で要求データを収集するので、全体サイズは小さくかつ得られる情報が多いデータを用意出来る。よって、受ける側のホストにとっても、そのデータを用い、安全にかつ有効なフォントの運用が可能になる。
【００４８】
【発明の効果】
以上の説明より明らかなように、本発明のフォントマネージャは、ホスト機器より所持しているフォント名一覧を回答させる内蔵フォント抽出命令が送信されて来た際に、登録してあるフォントだけを返送する機能を具備している。よって、この機能により、プリンタが保持するフォントデータが多過ぎて、ホスト装置側（アプリ）が用意した受け皿領域に吸収しきれないような事態の発生において、使用頻度の高いＲＯＭ上フォントおよびユーザが意図的にフォント辞書に登録しているフォントを優先的に選択することが可能となる。このことで、むやみに多量なフォントデータを送信する無駄や、その無駄な動作の為に不本意にも発生する受け皿領域のオーバーフローを回避することが可能となる。
【図面の簡単な説明】
【図１】本発明のフォントマネージャの実施形態が適用されるプリンタ装置のプリンタコントローラの構成例を示す回路ブロック図である。
【図２】本実施形態が適用されるプリンタ装置の構成例を示す縦断面図である。
【図３】本実施形態が適用されるプリンタ装置の回路構成例を示すブロック図である。
【図４】動作例１を示すフローチャートである。
【図５】動作例２を示すフローチャートである。
【図６】動作例３を示すフローチャートである。
【図７】動作例４を示すフローチャートである。
【図８】書体の構成例を概念的に表した図である。
【符号の説明】
１  ホストコンピュータ
２  レーザプリンタ本体
３  コントローラ
４  エンジン制御ボード
５  （プリンタ）エンジン
２６  レーザ書き込みユニット
２７  シーケンス機器群
２８  センサ類
３１  ＭＰＵ
３２、４２  メモリ（ＲＯＭ）
３３、４３  インプットバッファメモリ（ＲＡＭ）
３４、４４  入出力インターフェイス（Ｉ／Ｏ）
３５  操作パネル
４１  ＣＰＵ
１００  プリンタコントローラ
１０１  ＣＰＵ
１０２  ＩＣ  Ｃａｒｄ
１０３  ＮＶＲＡＭ
１０４  プログラムＲＯＭ
１０５  フォントＲＯＭ
１０６  ＲＡＭ
１０７  エンジンインタフェース
１０８  エンジン
１０９  パネルインタフェース
１１０  パネル装置
１１１  ホストインタフェース
１１２  ホスト装置
１１３  ディスクインタフェース
１１４  ディスク装置
【図１】
0003722388.tif 000002
【図２】
0003722388.tif 000003
【図３】
0003722388.tif 000004
【図４】
0003722388.tif 000005
【図５】
0003722388.tif 000006
【図６】
0003722388.tif 000007
【図７】
0003722388.tif 000008
【図８】
0003722388.tif 000009