JP3126367B2 - プリンタ制御装置 - Google Patents

Description

【発明の詳細な説明】 （産業上の利用分野） 本発明は、ドットプリンタの制御装置に関する。

（従来の技術） プリンタで印字を行う場合、最初に書式設定を行う。
この際に、使用者の使用目的に応じて、用紙のサイズ、
印字幅、マージン、改行ピッチなどを設定する。使用者
が設定しなければ、所定の標準書式が初期値として設定
される。

ドットプリンタには、操作パネルに、受信した描画す
るイメージをそのまま印字する縦長（ポートレート）と
描画するイメージを紙に対して90゜回転して印字する横
長（ランドスケープ）を指定するキー又は入力モードを
設けたものがある。この指定に対応して、使用するフォ
ントの角度や印字方向を切り替えることが可能になる。

プリンタが印字できる最大幅（たとえばレターサイズ
（8.5インチ））以上の幅のイメージデータがホストか
ら受信される場合は、この横長印字を指定すればよい。
これに対応して、ホストから受信された横長のイメージ
がプリンタ内での編集により紙に対して90゜回転して縦
長のイメージとしてメモリに記憶され、これに対応して
印字方向も切り替えられる。こうして、プリンタが印字
できる最大幅以上の横幅のイメージが紙に印字できる
（第８図参照）。

（発明が解決しようとする課題） ドットプリンタの中には、コストなどの理由より操作
パネルより横長（ランドスケープ）印字を指定する機能
や横長印字指定コマンドがないものがある。

このようなプリンタでは、他のドットプリンタ用のア
プリケーションプログラムを走らせるエミュレーション
モードにおいて、他のドットプリンタ用のアプリケーシ
ョンプログラムで発生されたイメージを印字する場合、
プリンタの印字可能な最大幅以上のイメージを発生する
アプリケーションプログラムは使用できない。

このような場合、アプリケーションプログラム側にお
いて横長印字指定のコマンドを新しく追加するという手
段も考えられるが、アプリケーションプログラム側でこ
のコマンドに対応していない場合はイメージデータを送
る前にユーザーがあらかじめ横長指定コマンドを送る必
要があり、使い勝手上あまり良くない。

本発明の目的は、ホスト側から受信されたイメージデ
ータのエリアがプリンタの縦長印字可能な最大幅より大
きい場合に、横長印字を可能にしたプリンタの制御装置
を提供することである。

（問題点を解決するための手段） 本発明に係るプリンタ制御装置は、イメージ幅をホス
トからの命令により指定するイメージ幅指定手段、描画
するイメージを縦長から横長に変え、それに応じて使用
するフォントの角度と印字方向を切り替えるランドスケ
ープ設定手段、及びイメージ幅指定手段より指定された
イメージ幅がプリンタの縦長印字可能な最大幅を越えた
ときにランドスケープ設定手段によって自動的にイメー
ジの描画方向を切り替えるイメージ方向切替手段を備え
たことを特徴とする。

（作用） ランドスケープ設定手段により横長（ランドスケー
プ）印字機能を指定可能とする。この指定は、イメージ
幅とプリンタの印字可能な最大幅とを比較することによ
り縦長での印字が不可能と判断されると、ランドスケー
プ設定手段が自動的に行う。これにより、ホストから受
信したイメージが自動的に90゜回転して印字できる。

（実施例） 以下、本発明の実施例を添付の図面を参照して次の順
序で説明する。

（ａ）電子写真プリンタの構成 〈全体の構成〉 〈ビットマップ制御部の構成〉 〈ビットマップ書込部の構成〉 （ｂ）エミュレーションモードとビットマップ制御の動
作 （ｃ）イメージエリアとランドスケープ指定機能 （ｄ）ビットマップ制御のフロー 〈スタートプロセス〉 〈スケジューラ〉 〈ユーザープロセス〉 〈ホストプロセス〉 （ａ）電子写真プリンタの構成 〈全体の構成〉 まず、プリンタおよびプリンタ・コントローラの概略
構成について説明する。

第１図は、本発明の実施例であるグラフィック描画の
可能なプリンタシステム10の処理システムの構成を示
す。コンピュータなどの汎用のデータ処理装置（ホス
ト）１からのデータは、データ処理装置１のスループッ
トを改善するために、ファイルバッファ２に格納された
後、プリンタシステム10に出力される。プリンタシステ
ム10は、ビットマップ方式のデータ処理ユニット３と、
電子写真プロセスとレーザ光学系を用いたプリントエン
ジン４よりなる。

なお、プリンタのカセットにセットされている紙のサ
イズは、通常の手段で検出されるが、検出についての説
明は省略する。

第２図は、プリンタシステム10の外観を示す。プリン
タシステム10は、データ処理ユニット３を内蔵してい
る。また、プリントエンジン４には、システムの状態を
示す表示が並べられた表示パネル44が装着されている。

第３図は、プリンタシステム10の制御概略ブロック図
である。ビットマップ方式データ処理ユニット３は、ビ
ットマップ制御部（第４図参照）30、ビットマップ用の
メモリ（BM−RAM）32、このBM−RAM32に描画を行なうビ
ットマップ書込部31（第５図参照）、及びフォント部33
よりなる。プリントエンジン４との接続は、制御データ
（枚数、アクセサリーなど）用のバスB3とイメージデー
タ用バスB4を介して行う。

プリントエンジン４は、３つのコントローラを中心に
構成される。まず、インターフェイス制御部40は、ビッ
トマップ制御部30からの制御データの処理、表示パネル
44の制御、及び内部バスB5を通じてプリントエンジン４
全体のタイミングの制御を行なう。電子写真制御部41
は、内部バスB5を通じてインターフェイス制御部40から
送られるデータに応じて、電子写真プロセス部45の制御
を行なう。プリントヘッド制御部42は、内部バスB4を通
じてビットマップ書込部31から送られてくる情報に従っ
て、プリントヘッド部43の半導体レーザーの発光やポリ
ゴン・モータの回転を制御する。

〈ビットマップ制御部の構成〉 第４図は本発明によるビットマップ制御部30の構成を
示す。全体の構成としては、データ入出力用のインター
フェイス301,309,310,311と、ビットマップ制御部の中
心となるCPU303とそのシステムROM305,システムRAM30
7、CPU303に定期的に割り込みをかけるタイマー302,そ
してデータ蓄積用のバッファメモリ304,306,308から成
る。

Ｒバッファ304は、ホストからデータ処理ユニットイ
ンターフェイス301を介して取り込まれた受信データを
記憶するために用いる。URバッファ306は、後で説明す
るユーザープロセスで他のプリンタ用のプロトコルで送
られてきたデータを本プリンタのプロトコルに変換して
記憶するために用いる。システムRAM307は、後述のユー
ザープロセスのダウンロード領域も備える。パケットバ
ッファ308は、FIFOメモリであり、Ｒバッファ304又はUR
バッファ306のデータを変換して得られる中間コードで
あるパケットを記憶するために用いる。CPU303は、後に
説明するように、システムROM305に格納されたホストプ
ロセス、パケットプロセスの他、システムRAM307に格納
されたユーザープロセスも実行できる。

〈ビットマップ書込部の構成〉 第５図は、ビットマップ書込部31の詳細ブロック図を
示す。ビットマップ書込部31の機能は大別して、BM−RA
M32への描画機能と、プリントの際にBM−RAM32のデータ
をプリントエンジン４へ出力する機能とに分かれる。

BM−RAM32への描画機能は、さらに２つに分けられ、
グラフィックイメージ書込部316により行われる線や円
の描画と、フォントイメージ書込部311により行われる
フォント描画とからなる。両方ともビットマップ制御部
インターフェイス317を通じてビットマップ制御部30か
ら送られてくる中間コードで動作するロジック部である
が、グラフィックイメージ書込部316のほとんどの処理
は、中間コード内のパラメータを解析してBM−RAM32に
描画するのに対して、フォントイメージ書込部311のほ
とんどの処理は、中間コード内のデータに従ってフォン
ト部インターフェイス314を通じてフォント部33から読
み込んだフォントイメージをBM−RAM32に描画する。

一方、プリントの際のデータ出力の機能は、プリント
ヘッド制御部インターフェイス315により行われる。す
なわち、ビットマップ制御部30からビットマップ制御部
インターフェイス317を介して送られてくるプリント開
始コードを受け取ると、プリントエンジン４のプリント
ヘッド制御部42からバスB4を通じて送られてくる同期信
号に従って、BM−RAM32のデータをプリントヘッド制御
部42に出力する。

（ｂ）エミュレーションモードとビットマップ制御の動
作 次にビットマップ制御部30の動作を説明する。

CPU303は、システムROM305とシステムRAM307のプログ
ラムによりBM−RAM32への描画と電子写真プロセス部45
での印字を制御する。

本プリンタシステムのプログラムには、システムROM3
05に格納されているホストプロセス（第14図参照）とパ
ケットプロセス（図示しない）、及びシステムRAM307の
ダウンロードセグメントに格納されているユーザープロ
セス（第12図参照）がある。これらの３つのプロセスは
独立したプログラムとなっており、優先順位のある時分
割処理によって並行して動作している。優先順位はパケ
ットプロセス、ホストプロセス、ユーザープロセスの順
位となる。

システムROM305には、この他に、タイマー割り込みに
よりこれらのプロセスの管理を行なうスケジューラ（第
11図参照）と、スタート時に起動される初期化のための
スタートプロセスが格納されている。

システムROM305内のスケジューラがタイマー302から
のタイマー割り込みによって各プロセスを状態に応じて
切り替える。ここでシステムRAM307内にはカレント・プ
ロセス・ステータス（CPS）ブロックという領域があっ
て（第９図参照）、各プロセスの切り替え時にCPU303の
レジスタの内容がCPS内に退避されるので、各プロセス
は独立して動作を行うことができる。このようなビット
マップ制御の動作は、本出願人による特開昭63−231957
号公報に開示されている。本実施例との相違は、ユーザ
ープロセスとホストプロセスにおけるランドスケープ指
示機能に関する部分だけである。

エミュレーションモードとは、他のプリンタ用のエミ
ュレーションプログラムで動作するモードである。エミ
ュレーションモードでは、ユーザープロセス、ホストプ
ロセス、パケットプロセスが順次用いられる。

ここで、ユーザープロセス（第12図参照）は、他のプ
リンタに対応するプロトコルで送られてきたデータを、
ホストプロセスが解析可能な本プリンタのプロトコル
（ホストプロトコル）に変換し、URバッファ306に書き
込み、ホストプロセスに渡すプログラムである。エミュ
レーションプログラムは、フォントカートリッジまたは
内蔵ROMさらにデータ処理装置１からのダウンロードに
よって供給される。プロトコル変換が必要なければコー
ド変換は実行されない。

なお、本実施例ではユーザープロセスがロードされる
のは電源投入時か、カートリッジを後から挿入した場合
にホストからのロード要求コードを受信した時となって
いるが、ロード方法及びそのタイミングは別にどのよう
に決めてもかまわない。さらに、ユーザープロセスがカ
ートリッジ内に複数存在する場合も考えられるが、本実
施例では考えていない。

ホストプロセス（第14図参照）は、データ処理装置１
から送られてきたＲバッファ304又はURバッファ306内の
データの解析を行い、ビットマップ書込部31やプリント
エンジン４を制御するための中間データであるパケット
をパケットバッファ308に書き込む。

パケットプロセスは、パケットバッファ308内のパケ
ットを解析してビットマップ書込部インターフェイス31
0よりビットマップ書込部31へ、またはフォントインタ
ーフェイス309を通じてフォント部33へ、さらにプリン
トエンジンインターフェイス311を通してインターフェ
イス制御部40ヘデータを送り、実際にBM−RAM32への描
画とプリントエンジン４の制御を行う。

本実施例ではユーザープロセスとしてエミュレーショ
ンプログラムを動作させ、そのエミュレーションプログ
ラム内でランドスケープ（（ｃ）節参照）とポートレー
トを自動的に切り替える場合について説明する。

すでに説明したように、他のプリンタ用のプロトコル
で送られてきたデータは、Ｒバッファ304にまず格納さ
れる。プロセスの管理を行うスケジューラがタイマ割り
込みによりユーザープロセスに処理を切り替えると（第
11図参照）、起動されたユーザープロセスは、後に説明
するように、受信したイメージの幅が本プリンタの印字
可能な最大幅を越えると判断するとランドスケープ指定
コマンドをURバッファに記憶し、さらに、Ｒバッファ30
4内の受信データを取り出し、本プリンタのプロトコル
に変換した後、URバッファ306に蓄積する。よってデー
タの仮編集を行なうホストプロセスは、ユーザープロセ
スの起動時にはURバッファ306内のデータを取出し、非
起動時にはＲバッファ304内の受信データを取り出すだ
けで良く、他に変更の必要がない。また、プリンタ動作
を制御する他のプロセスを変更する必要もない。従っ
て、ユーザープロセスはデータの変換のみを行なう簡単
なものになり、エミュレーションソフトウエアの開発も
容易となる。

（ｃ）イメージエリアとランドスケープ指定機能 まずイメージエリアの考え方について説明する。

第６図と第７図に、ホスト１から受信した通常の場合
（ポートレート）のイメージデータのイメージエリアの
例を示す。ここで、全エリアA1で示される部分が、１枚
の紙のサイズに相当する。マージンエリアA2は、実際に
紙にプリントを行なう際の余白部分で、BM−RAM32で印
字データの描画が行われるのは、残ったイメージエリア
A3の部分である。ホストから受信したデータより、第６
図の場合、縦に長いイメージエリアA3にイメージデータ
が発生され、第７図の場合、横に長いイメージエリアA3
にイメージデータが発生される。なお、マージンエリア
A2は、ホストからの指定によりページ単位に変更が可能
である。ここで、レフトマージンA4とは、全エリアA1の
左端より文字の書出し位置まで、ライトマージンA5と
は、全エリアA1の左端よりイメージエリアA3の右端まで
をいう。

印字の開始は、イメージエリアA3の左上から行なわ
れ、文字は印字方向A10に従って順次印字される。途
中、改行コードが入力された場合、改行方向A11に、改
行幅A12だけ次の印字位置が移動する。また、復行コー
ドが入力されると、イメージエリア左端の復行位置A13
に次の印字位置が移動する。印字の際の通紙方向A14
は、印字方向A10と90゜回転した方向にある。

本プリンタの印字可能な最大幅は、ライトマージンA5
やレフトマージンA4から定まる。レフトマージンA4を一
定とすると、印字幅は、ライトマージンの最大値で定ま
り、これをイメージの横幅と比較すると、印字可能か否
かが判断できる。

本実施例のプリンタでは、既に説明したように、他の
ドットプリンタのエミュレーションプログラムを走らせ
ることができるユーザープロセスとよぶプログラム（第
12図参照）を実行できる。そこで、他のプリンタ用の表
計算プログラムなどのアプリケーションプログラムの場
合、第７図に示すような横長のイメージがホスト１から
送られて、イメージの横幅が本プリンタの印字可能な幅
を越えることがある。かかる場合には、そのままではそ
のイメージの印字はできない。

そこでランドスケープモードを設けて、第８図に示す
ように、受信したイメージを紙に対して90゜回転して縦
長の形でBM−RAM32に展開し、印字するようにすればよ
い。

しかし、本実施例のプリンタでは、ランドスケープ指
定コマンドが無く、操作パネル上でランドスケープモー
ドを指定できない。そこで、エミュレーションプログラ
ムで所定の幅以上のイメージが発生されたと判断した場
合、ランドスケープ指定コマンドを発生させて、ホスト
より受信した所定幅以上の横長イメージも紙に対して90
゜回転して印字可能とした。

具体的には、ユーザープロセスでのエミュレーション
プログラムのライトマージン設定コマンドのコード変換
処理（第13図ステップS602〜S605参照）において、１頁
のイメージの初めならば、プリンタの印字可能な横幅と
エミュレーションプログラムで指定されたイメージサイ
ズとを比較する。そして、イメージサイズが印字可能な
最大横幅より大きい場合に、ランドスケープ指定コマン
ドをURバッファ306に送る。そして、ライトマージンに
イメージサイズを設定する。これによりランダスケープ
指定コマンドが無く、操作パネル上でもその指定ができ
ない本プリンタにおいて、印字可能な最大横幅よりも大
きな横長のイメージサイズが指定された場合、ランドス
ケープ指定コマンドに対応して自動的に編集イメージの
サイズを90゜回転して横長（ランドスケープ）に切り替
えることができる（第８図参照）。

（ｄ）ビットマップ制御のフロー 以下、フローチャートを参照しながらビットマップ制
御の動作を詳細に説明する。なお、パケットプロセス
は、ポートレート（縦長）とランドスケープ（横長）の
切り替えに無関係であり、従来と同じなので、説明を省
略する。

〈スタートプロセス〉 第10図はスタートプロセスを示すフローチャートであ
る。このプロセスはスタート時に１回だけ起動される。

このプロセスでは、システムRAM307のカレント・プロ
セス・ステータス（CPS）ブロック（第９図参照）にお
いて記憶されるリクエストベクターとカレントベクター
の２つのステータスを表わすベクターが使用される。リ
クエストベクターは、タイマー割り込みによってスケジ
ューラ（第11図参照）が起動されたとき、実行が中断さ
れたプロセスがスケジューラに対して実行の放棄と他プ
ロセスの起動要求を伝達するために使用され、各プロセ
スに対応するビットがセットまたはリセットされる。ま
たカレントベクターは実行中のプロセスに対応するビッ
トをセットするようになっていて、スケジューラが起動
されたときは実行が中断されたプロセスのビットがセッ
トされている。さらに、CPSブロックのCRTPRSにはカレ
ントベクターの示すプロセスの番号が入っていて、プロ
セスの番号は優先順位が高い程大きくしてある。

スタートプロセスでは、まず電源が投入されると（ス
テップS1）、内部の初期化を行ない（ステップS2）、Ｒ
バッファ304、URバッファ306、及びパケットバッファ
（FIFOメモリ）308のクリアを行なう（ステップS3,S4,S
5）。次に、この後ユーザープロセスを起動するため準
備動作として、リクエストベクターのホストプロセスを
示すビットをセットし（ステップS6）、カレントベクタ
ーのユーザープロセスを示すビットをセットし（ステッ
プS7）、CRTPRSにユーザープロセスを示す番号を入れる
（ステップS8）。この後に、システムRAM307のCPSブロ
ックの初期化を行なう（ステップS9）。具体的には、各
CPSでCPU303の実行アドレスポインタのデータを格納す
るエリアに、各プロセスプログラムのスタートアドレス
値を入れ、スタックポインタを格納するエリアに所定の
アドレス値を入れる。また必要に応じて他のポインタの
初期値も入れる。

これらの初期設定を終えると割り込みを許可し（ステ
ップS10）、タイマー割り込み待ち（ステップS11）のル
ープに入る。タイマー割込があると、スケジューラ（第
11図参照）が起動され、上記のリクエストベクター、カ
レントベクター、CRTPRSを用いてスケジューラは次のプ
ロセスの実行先を決定する。

この様な構成を取ることによって、本プリンタと異な
るプロトコルのデータに対しても、ダウンロードを行な
うユーザープロセスを変えることによって任意に対応可
能となる。

〈スケジューラ〉 第11図はタイマ割り込みによって起動されるスケジュ
ーラのフローを示す。まずタイマによる割り込みが入る
と（ステップS30）、CPUの各レジスタの値をCPSブロッ
ク内の退避エリアへ退避する（ステップS31）。次にリ
クエストベクタにセットされているビットの内で、最優
先のプロセス番号をREQPRSに入れる（ステップS32）。
ここでCRTPRSには割り込み処理を行う直前のプロセス番
号が入っているので、これとREQPRSを比較することによ
って、より優先順位の高いプロセスの起動リクエストが
あるかどうかを判断する（ステップS33）。上位プロセ
スの起動リクエストがない場合（ステップS33でNO）、
処理中だったプロセス（CRTPRSが示している）がリクエ
ストベクタのビットをリセットして先の実行を放棄して
いるかどうかをチェックし（ステップS42）、もし放棄
していないならば（ステップS42でYES）CPSブロックの
退避エリアの各レジスタのデータをCPUにセットして
（ステップS39）、復帰する。この場合タイマ割り込み
によって中断したプロセスがそのまま実行される。もし
先の実行を放棄している場合は（ステップS42でNO）CRT
PRSの示すプロセスよりも下位でかつ最上位のプロセス
番号をREQPRSに入れて（ステップS41）、ステップS35に
進み、ステップS33でYESの場合と同様の処理を行う。こ
こではCRTPRSの示す実行を中断するプロセスのCPSに退
避エリアの値を転送し（ステップS35）、REQPRSの示す
プロセスのCPSの値を退避エリアに転送する（ステップS
36）。さらに、CRTPRSにREQPRSの値を入れ（ステップS3
7）、REQPRSの示すプロセスのカレントベクタのビット
だけをセットし、他はリセットする（ステップS38）。
これらの処理によって退避エリアにはREQPRSの示すプロ
セスのレジスタの値が入っているので、復帰先はREQPRS
の示すプロセスとなる。

〈ユーザープロセス〉 第12図はユーザープロセスの処理例を示すフローであ
る。ユーザープロセス自体は対応するプロトコルによっ
ていくつかのプログラムが存在するであろうが、基本的
な形態はこの様になっている。特に、ステップS501〜S5
04,S509は各ユーザープロセスで共通化しておかないと
他のプロセスとの対応が取れなくなる。

まず、Ｒバッファ304にデータが有ることをチェック
し（ステップS501）、その後にURバッファ306の空きを
チェックする（ステップS502）。

URバッファ306の空きがないときは（ステップS502でN
O）、ホストプロセスの起動要求をリクエストベクター
によって行ない（ステップS503）、URバッファ304に空
きを作るようにする。そして、S501に戻る。

URバッファ306の空きがあるときは（ステップS502でY
ES）、Ｒバッファ304よりデータを取り込み（ステップS
504）、プロトコル変換処理（ステップS505〜S508,S51
3）を行なう。すわなち、制御コードであれば（ステッ
プS505でYES）、コード変換処理（ステップS506,第13図
参照）を行い、必要ならばランドスケープ指定コマンド
をURバッファ306に送り、上位プロセス（ホストプロセ
ス）のリクエストベクターのビットをセットする。そし
てステップS501に戻る。制御コードでなければ、次にス
テップS508で印字データであるか否かを判定する。印字
データでなければ、データをそのままURバッファ306に
書き込み（ステップS509）、ステップS501に戻る。

ステップS508で印字データであると判定されたとき
は、次にPAGE_WRITEフラグが０かどうか、つまりそのペ
ージで初めて印字データを受けたかどうかをチェックし
（ステップS511）、受信しているときはPAGE_WRITEフラ
グを１にセットする（ステップS512）。最後にデータ変
換を行い（S513）、URバッファ306に書き込み（ステッ
プS509）、ステップS501に戻る。

この実施例では受信データを制御コードと印字データ
に分け、制御コードを受信した時のみホストプロセスの
起動要求を行なうようになっているが、リクエストベク
ターのセットのタイミングは変更を行なうプロトコルの
形態や処理効率を考慮して任意の位置で行なってもかま
わない。

次に、制御コードのコード変換処理（第12図ステップ
S505）の詳細を第13図に示す。

ステップS601で、Ｒバッファ304より読み込んだデー
タがライトマージン設定コマンドであると判定されたと
きは（ステップS601でYES）、次にそのページに印字デ
ータが書き込まれたことを示すフラグPAGE_WRITEが１か
どうかをチェックし（ステップS602）、PAGE_WRITEフラ
グが０のとき、つまりそのページに印字データが書き込
まれていないとき（ステップS602でYES）には、ステッ
プS603以下の処理を行なう。ステップS603ではライトマ
ージン設定コマンドのパラメータが印字可能エリアの最
大横幅を示すRIGHTMAXを越えているかどうかをチェック
する。越えているとき（ステップS603でYES）は、横長
印字をするためにランドスケープ指定コマンドをURバッ
ファ306へ送り（ステップS604）、現在のライトマージ
ン値を示すRIGHTMGにパラメータの値をセットする（ス
テップS605）。ステップS603でNOのときはポートレート
指定コマンドをURバッファ306へ送り（ステップS60
6）、ステップS605に入ってRIGHTMGにパラメータの値を
セットする。ステップS607〜S614のステップはPAGE_WRI
TEフラグの管理を示している。まず、改頁コマンド（0C
H）のときは（ステップS607でYES）PAGE_WRITEフラグを
０にセットした後（ステップS608）、改頁コマンドをUR
バッファ306へ送る（ステップS609） 次にラインフィードコマンドのときは（ステップS610
でYES）Ｙ方向のカーソルを１行分下方へ動かし（ステ
ップS611）、Ｙ方向のカーソルが設定されているページ
長を越えたかどうかをチェックする（ステップS612）。

ここでページ長を越えたときは（ステップS612でYE
S）Ｙ方向のカーソル値を０へ動かし、改頁の処理（ス
テップS608,S609）を行なう。

その他のコマンドのときはそのコマンドに対応した変
換コマンドをURバッファ306へ送るが（ステップS61
4）、ここでは詳しくは説明しない。

〈ホストプロセス〉 第14図はホストプロセスの動作を示すフローチャート
である。ホストプロセスの最初の起動は、前述のように
タイマー割り込みによって起動されたスケジューラがホ
ストプロセスに切り替えることによって行なわれる。こ
のとき、ビットマップ制御部のCPU303のプログラムカウ
ンタにホストプロセスの先頭アドレスが設定される。

処理の流れを説明すると、まずホストプロセスに用い
ているフラグの初期化を行う（ステップS51）。具体的
には、ユーザープロセスの実行の有無を示すUSERフラグ
を０にリセットし、受信データ処理ルーチンで仮イメー
ジ編集中であることを示すLPWRITEフラグを０にセット
する。そして、中間コード作成の準備としてフォント部
33よりフォント属性を読み込む（ステップS52）。この
ときフォント部33のフォントカートリッジ内にユーザー
プロセスが有るかどうかをチェックして（ステップS5
3）、有りの場合はシステムRAM307の所定の領域にユー
ザープロセスをロードする（ステップS54）。そして、
ロード終了（ステップS55）を待ってユーザープロセス
の実行を示すUSERフラグを１にセットし（ステップS5
6）、リクエストベクターのユーザープロセスのビット
をセットする（ステップS57）。これは、最下位のプロ
セスであるユーザープロセスが有るときは常にリクエス
トベクターのビットをセットしておき、自分自身の実行
を放棄することの無いようにするためである。これらの
初期化動作（ステップS51〜ステップS57）を行なった
後、主ループ（ステップS58〜ステップS63）に入る。

主ループではパケットバッファ308の空エリアがなく
なるとき（ステップS58でNO）、USERフラグ＝１のとき
（ステップS59でYES）URバッファ306にデータがないと
き（ステップS60でNO）、USERフラグ＝０のとき（ステ
ップS59でNO）でＲバッファ304が空になるとき（ステッ
プS61でNO）以外は、受信データ処理（ステップS62）を
行なう。また、受信データ処理を行なわないとき（ステ
ップS58、ステップS60、ステップS61でNO）はJOBOUT処
理１（第15図参照）を実行する（ステップS63）。JOBOU
T処理１では、ホストプロセスがスケジューラに対して
上位プロセス（実施例ではパケットプロセス）への切り
替えを要求するために、リクエストベクターを更新す
る。

これらの流れから明らかなように、特定の条件（パケ
ットバッファ308の空エリアがないかまたはＲバッファ3
04,URバッファ306が空きとか、他に受信データ処理内で
も設定している）によってJOBOUT処理１が実行されリク
エストベクターが更新されるまでは、タイマー割り込み
によってスケジューラが起動されても再びホストプロセ
スに戻ってくるので受信データ処理をくり返して行なう
ことになる。

第15図は、JOBOUT処理１のフローを示す。この処理で
は、ホストプロセスがスケジューラに対して上位プロセ
ス（実施例ではパケットプロセス）への切り替えを要求
するために、リクエストベクタのパケットプロセスビッ
トをセットし（ステップS72）、ユーザープロセスがあ
る場合（ステップS73でYES）にはホストプロセスは最下
位プロセスではないのでリクエストベクタのホストプロ
セスのビットをリセットし自らの実行を放棄する。また
ユーザープロセスの無い場合（ステップS73でNO）は、
ホストプロセスが最下位プロセスとなるのでリクエスト
ベクタのホストプロセスのビットはセットしたままにし
ておく。なお、これらの処理中はタイマー割り込みを禁
止して（ステップS71、S75）誤動作を防ぐようにしてい
る。

受信データは、第16図に示すようにデータの受信割り
込みによってデータ処理インターフェイス301より取り
込まれ（ステップS191）、Ｒバッファ304に蓄積される
（ステップS192）。

受信データ処理（S62）のフローを第17図（ａ），
（ｂ）に示す。

まず、受信データの処理を行なうためにＲバッファ30
4よりデータを取り出す必要がある。ここで、ユーザー
プロセスが有る場合は（USERフラグ＝１）、Ｒバッファ
304のデータのプロトコル変換を行なった後URバッファ3
06に蓄積されているのでユーザープロセスを優先する。
そこで、USERフラグが１のときは（ステップS101でYE
S）URバッファ306より、USERフラグが０のときは（ステ
ップS101でNO）Ｒバッファ304よりデータを取り込む
（ステップS102,ステップS107）。

ここで受信データは次の６つに分類される。

・IFC関連コード（プリント・エンジン関連コード）
（ステップS103〜ステップS105） ・JOB制御コード（JOBSTART,PAGEEJECT）（ステップS10
8〜ステップS112）。

・書式制御コード（ステップS113〜ステップS114） ・印字データ（文字コード，グラフィックコード）（ス
テップS128〜ステップS134） ・ユーザープロセス制御コード（ステップS118〜ステッ
プS122） まず、印字データの場合は（ステップS103、S108、S1
10、S113、S115、S117、S123、S126でいずれもNO）、対
応するフォーマットの中間コード（パケット）に変換し
てパケットバッファ308に出力する。すなわち、第17図
（ｂ）に示すように、仮イメージ編集を示すLPWRITEフ
ラグが０であれば（ステップS126でYES）、LPWRITEフラ
グを１にセットする。次に文字コードの場合は（ステッ
プS128でYES）、フォント・イメージ書込部311へのフォ
ーマットと同じでフォント・パターンのアドレス（ステ
ップS129）、イメージ・エリア上の印字位置に対応する
BM−BAM32への書込みアドレス（ステップS130）および
書込みモード（ステップS131）をパケットバッファ308
に出力する。グラフィックコードの場合は（ステップS1
33でYES）、グラフィックイメージ書込部316へのコマン
ドと同一のフォーマットでパケットバッファ308に出力
される（ステップS134）。このとき、文字コードの場合
は、次の文字印字位置を更新しておく（ステップS13
2）。

第17図（ａ）に示すように、IFC関連コードの場合は
（ステップS103でYES）、インターフェイス制御部（IF
C）40に出力するものであるが、印字データとの同期を
とるため、印字データとは形式の異なるファンクション
タイプの中間コードとしてパケットバッファ308へ出力
し（ステップS104）、JOBOUT処理１を行う（ステップS1
05）。

JOB制御コードには、ページの区切りに用いるPAGE E
JECTコード（ステップS110でYES）と、ページ群の区切
りに用いるJOBSTART（ステップS108でYES）の２つがあ
る。どちらもIFC関連コードと同様に、パケットバッフ
ァ308に出力する（ステップS109,ステップS111）。

書式制御コードの場合は（ステップS113でYES）、印
字の書式を制御する（S114）。

同一イメージのコピー枚数を指定するコピー枚数コー
ドの場合は（ステップS115でYES）、印字データとの同
期をとるためパケットバッファ308に対応するファンク
ションを出力する。

第17図（ｂ）図に示すように、次にユーザープロセス
ロード要求コードの場合は（ステップS117でYES）、ユ
ーザープロセスの有無をチェックした後（ステップS11
8）、フォントカートリッジよりユーザープロセスのプ
ログラムのロード処理を行ない（ステップS119、ステッ
プS120）、USERフラグのセットをし（ステップS121）、
さらにリクエストベクターのユーザープロセスビットを
セットする（ステップS122）。

またユーザープロセス解除コードの場合（ステップS1
23でYES）は逆にUSERフラグをリセットし（ステップS12
4）、リクエストベクターのユーザープロセスビットを
リセットする（ステップS125）。

（発明の効果） アプリケーションプログラム側で設定したイメージ幅
とプリンタが印字可能な幅に応じて、自動的にランドス
ケープ印字に切り替えることができるようになる。特に
操作部によりランドスケープを指定する機能がないプリ
ンタの場合でも、使い勝手がよくなる。

【図面の簡単な説明】

第１図は、プリンタシステムの構成図である。 第２図は、プリンタシステムの斜視図である。 第３図は、プリンタシステムの制御系のブロック図であ
る。 第４図は、ビットマップ制御部のブロック図である。 第５図は、ビットマップ書込部のブロック図である。 第６図は、縦長のイメージの図である。 第７図は、横長のイメージの図である。 第８図は、第７図の図を回転したランドスケープモード
でのイメージの図である。 第９図は、カレントプロセスブロックの構成図である。 第10図は、スタートプロセスのフローチャートである 第11図は、スケジューラのフローチャートである。 第12図は、ユーザープロセスのフローチャートである。 第13図は、コード変換処理のフローチャートである。 第14図は、ホストプロセスのフローチャートである。 第15図は、JOBOUT処理１のフローチャートである。 第16図は、受信割込のフローチャートである。 第17図（ａ），（ｂ）は、受信データ処理のフローチャ
ートである。 30……ビットマップ制御部、 32……BM−RAM、303……CPU、 304……Ｒバッファ、 306……URバッファ、 308……パケットバッファ。

フロントページの続き (56)参考文献 特開 昭61−177067（ＪＰ，Ａ) 特開 昭63−162255（ＪＰ，Ａ) 特開 平３−124464（ＪＰ，Ａ) 特開 平２−213933（ＪＰ，Ａ)

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】イメージ幅をホストからの命令により指定
   するイメージ幅指定手段、 描画するイメージを縦長から横長に変え、それに応じて
   使用するフォントの角度と印字方向を切り替えるランド
   スケープ設定手段、及び イメージ幅指定手段より指定されたイメージ幅がプリン
   タの縦長印字可能な最大幅を越えたときにランドスケー
   プ設定手段によって自動的にイメージの描画方向を切り
   替えるイメージ方向切替手段を備えたことを特徴とする
   プリンタ制御装置。