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

Abstract

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

Description

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

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

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

プリンタが印字できる最大幅（たとえばレターサイズ（
８，５インチ））以上の幅のイメージデータかホストか
ら受信される場合は、この横長印字を指定すればよい。

これに対応して、ホストから受信された横長のイメージ
がプリンタ内での編集により紙に対して９０°回転して
縦長のイメージとしてメモリに記憶され、これに対応し
て印字方向も切り替えられる。こうして、プリンタが印
字できる最大幅以上の横幅のイメージが紙に印字できる
（第８図参照）。

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

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

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

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

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

（作用） ランドスケーグ設定手段により横長（ラン１゛スケープ
）印字機能を指定可能とする。この指定は、イメージ幅
とプリンタの印字可能な最大幅とを比較することにより
縦長での印字が不可能と判断されると、ランドスケープ
設定手段が自動的に行う。

これにより、ホストから受信したイメージか自動的に９
０°回転して印字できる。

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

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

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

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

第２図は、プリンタ／ステム１０の外観を示す。

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

第３図は、プリンタ７ステム１０の制御概略ブロック図
である。ビットマツプ方式データ処理ユニント３は、ビ
ットマツプ制御部（第４図参照）３０、ビットマツプ用
のメモリ（ＢＭ−ＲＡＭ）３２、このＢＭ−ＲＡＭ３２
に描画を行なうビットマツプ書込部３１（第５図参照）
、及びフォント部３３よりなる。プリントエンジン４と
の接続は、制御データ（枚数、アクセサリ−など）用の
バスＢ３とイメージデータ用バスＢ４を介して行う。

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

〈ヒツトマツプ制御部の構成〉 第４図は本発明によるヒツトマツプ制御部３０の構成を
示す。全体の構成としては、データ入出力用のインター
フェイス３０１，３０９，３１０，３１１と、ヒツトマ
ツプ制御部の中心となるＣＰＵ３０３とそのシステムＲ
ＯＭ３０５．システムＲＡＭ３０７、ＣＰＵ３０３に定
期的に割り込みをかけるタイマー３０２．そしてデータ
蓄積用のバッファメモリ３０４，３０６，３０８から成
る。

Ｒバッファ３０４は、ホストからデータ処理ユニ７トイ
ンターフエイス３０１を介して取り込まれた受信データ
を記憶するために用いる。ＵＲバッファ３０６は、後で
説明するユーザープロセスで他のプリンタ用のプロトコ
ルで送られてきたブタを本プリンタのプロトコルに変換
して記憶するために用いる。システムＲＡＭ３０７は、
後述のユーザープロセスのダウンロード領域も備える。

パケットバッファ３０８は、ＦＩＦ○メモリであり、Ｒ
バッファ３０４又はＵＲ／（ッファ３０６（７）データ
を変換して得られる中間コードであるパケットを記憶す
るために用いる。ＣＰＵ３０３は、後に説明するように
、システムＲＯＭ３０５に格納され！ニホストプロセス
、パケットプロセスの他、システムＲＡＭ３０７に格納
されたユーザープロセスも実行できる。

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

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

方、プリントの際のデータ出力の機能は、プリントヘッ
ド制御部インターフェイス３１５により行われる。すな
わち、ヒツトマツプ制御部３０からヒツトマツプ制御部
インターフェイス３１７を介して送られてくるプリント
開始コードを受は取ると、プリントエンジン４のプリン
トヘッド制御部４２からバスＢ４を通じて送られてくる
同期信号に従って、ＢＭ−ＲＡＭ３２のデータをプリン
トヘッド制御部４２に出力する。

′Ｃｂ）エミュレ＝７ヨンモードとビノトマ／ブ制御の
動作 次にピントマツプ制御部３０の動作を説明する。

ＣＰＵ３０３は、システムＲＯＭ３０５とンステムＲＡ
Ｍ３０７のプログラムによりＢＭ−ＲＡＭ３２への描画
と電子写真プロセス部４５での印字を制御する。

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

優先順位はパケットプロセス、ホストプロセス、ユーザ
ープロセスの順位となる。

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

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

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

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

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

サラに、ユーザープロセスがカートリッジ内に複数存在
する場合も考えられるが、本実施例では考えていない。

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

パケットプロセスは、パケントバッフ７３０ｇ内のバケ
ットを解析してヒツトマツプ書込部インターフェイス３
１０よりヒントマツプ書込部３１へ、マを二はフォント
インターフェイス３０９ｔ−通してフォント部３３へ、
さら（こプリントエンジンインターフェイス３１１を通
してインターフェイス制御部４０ヘデータを送り、実際
にＢＭ−ＲＡＭ３２への描画とプリントエンジン４の制
御を行う。

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

すでに説明したように、他のプリンタ用のプロトコルで
送られてきたデータは、Ｒバッファ３０４にまず格納さ
れる。プロセスの管理を行うスケジューラがタイマ割り
込みによりユーザープロセスに処理を切り替えると（第
１１図参照）、起動されたユーザープロセスは、後に説
明するように、受信したイメージの幅が本プリンタの印
字可能な最大幅を越えると判断するとランドスケープ指
定コマンドをＵＲバンファに記憶し、サラに、Ｒバッフ
ァ３０４内の受信データを取り出し、本プリンタのプロ
トコルに変換した後、ＵＲバッファ３０６に蓄積する。

よってデータの仮編集を行なうホストプロセスは、ユー
ザープロセスの起動時にはＵＲバッファ３０６内のデー
タを取出し、非起動時にはＲバッファ３０４内の受信デ
ータを取り出すだけで良く、他に変更の必要かない。ま
た、プリンタ動作を制御する他のプロセスを変更する必
要もない。従って、ユーザープロセスはデータの変換の
みを行なう間車なものになり、エミュレーションソフト
ウェアの開発も容易となる。

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

第６図と第７図に、ホスト１から受信した通常の場合（
ポートレート）のイメージデータのイメージエリアの例
を示す。ここで、全エリアＡＩで示される部分が、１枚
の紙のサイズに相当する。

マージンエリアＡ２は、実際に紙にプリントを行なう際
の余白部分で、ＢＭ−ＲＡＭ３２で印字データの描画か
行われるのは、残ったイメージエリアＡ３の部分である
。ホストから受信したデータより、第６図の場合、縦に
長いイメージエリアＡ３にイメージデータか発生され、
第７図の場合、横に長いイメージエリアＡ３にイメージ
データか発生される。なお、マージンエリアＡ２は、ホ
ストからの指定によりページ単位に変更が可能である。

ここで、レフトマージンＡ４とは、全エリアＡＩの左端
より文字の書出し位置まで、ライトマージンＡ５とは、
全エリアＡＩの左端よりイメージエリアＡ３の右端まで
をいう。

印字の開始は、イメージエリアＡ３の左上から行なわれ
、文字は印字方向ＡＩＯに従って順次印字される。途中
、改行コードが入力された場合、改行方向Ａｌｌに、改
行幅ＡＩ２だけ次の印字位置か移動する。また、復行コ
ードが入力されると、イメージエリア左端の復行位置Ａ
１３に次の印字位置か移動する。印字の際の通紙方向Ａ
１４は、印字方向ＡｌＯと９０°回転した方向にある。

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

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

そこでランドスケープモードを設けて、第８図に示すよ
うに、受信したイメージを紙に対して９０°回転して縦
長の形でＢＭ−ＲＡＭ３２に展開し、印字するようにす
ればよい。

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

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

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

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

このプロセスでは、システムＲＡＭ３０７のカレント・
プロセス・ステータス（ＣＰＳ）ブロック（第９図参照
）において記憶されるリクエストベクターとカレントベ
クターの２つのステータスを表わすベクターが使用され
る。リクエストベクターは、タイマー割り込みによって
スケジューラ（第１１図参照）か起動されたとき、実行
か中断されたプロセスかスケジューラに対して実行の放
棄と他プロセスの起動要求を伝達するために使用され、
各プロセスに対応するビットかセットまたはリセットさ
れる。またカレントベクターは実行中のプロセスに対応
するビットをセットするようになっていて、スケジュー
ラが起動されたときは実行が中断されたプロセスのヒツ
トかセントされている。

さらに、ＣＰＳブロックのＣＲＴＰＲ５にはカレントベ
クターの示すプロセスの番号が入っていて、プロセスの
番号は優先順位が高い程大きくしである。

スタートプロセスでは、まず電源か投入されると（ステ
ップＳｌ）、内部の初期化を行ない（ステップＳ２）、
Ｒバッファ３０４、ＵＲバッファ３０６、及びバケット
バッファ（ＦＩＦＯメモリ）３０８のクリアを行なう（
ステップＳ３．Ｓ４．Ｓ５）。

次に、この後ユーザープロセスを起動するため準備動作
として、リクエストベクターのホストプロセスを示すピ
ントをセットしくステップＳ６）、カレントベクターの
ユーザープロセスを示すヒ′ントをセットしくステップ
Ｓ７）、ＣＲＴＰＲ３にユーザープロセスを示す番号を
入れる（ステップＳ８）。

この後に、システムＲＡＭ３０７のＣＰＳブロックの初
期化を行なう（ステップＳ９）。具体的には、各ＣＰＳ
でＣＰＵ３０３の実行アドレスポインタのデータを格納
するエリアに、各プロセスプログラムのスタートアドレ
ス値を入れ、スタックポインタを格納するエリアに所定
のアドレス値を入れる。また必要に応して他のポインタ
の初期値も入れる。

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

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

くスケジューラ〉 第１１図はタイマ割り込みによって起動されるスケジュ
ーラの７０−を示す。まずタイマによる割り込みが入る
と（ステップ５３０）、ＣＰＵの各レジスタの値をＣＰ
Ｓブロック内の退避エリアへ退避する（ステップ５３１
）。次にリクエストベクタにセントされているピントの
内で、最優先のプロセス番号をＲＥＱＰＲ５に入れる（
ステップ５３２）。ここでＣＲＴＰＲ５には割り込み処
理を行う直前のプロセス番号か入っているので、これと
ＲＥＱＰＲ５を比較することによって、より優先順位の
高いプロセスの起動リクエストかあるかとうかを判断す
る（ステップ５３３）。上位プロセスの起動リクエスト
かない場合（ステップ３３３でＮＯ）、処理中だったプ
ロセス（ＣＲＴＰＲ５が示している）がリクエストベク
タのビ・ントをリセットして先の実行を放棄しているか
どうかをチエツクしくステップ５４２）、もし放棄して
いないならば（ステップＳ４２でＹＥＳ）ＣＰＳブロッ
クの退避エリアの各レジスタのデータをＣＰＵにセット
して（ステップ５３９）、復帰する。この場合タイマ割
り込みによって中断したプロセスがそのまま実行される
。もし先の実行を放棄している場合は（ステップＳ４２
でＮｏ）ＣＲＴＰＲ５の示すプロセスよりも下位でかつ
最上位のプロセス番号をＲＥＱＰＲ５に入れて（ステッ
プ５４１）、ステップＳ３５に進み、ステップＳ３３で
ＹＥＳの場合と同様の処理を行う。ここではＣＲＴＰＲ
５の示す実行を中断するプロセスのＣＰＳに退避エリア
の値を転送しくステップ５３５）　、ＲＥＱＰ’Ｒ５の
示すプロセスのｃｐｓの値を退避エリアに転送する（ス
テップ５３６）。さらに、ＣＲＴ　Ｐ　ＲＳ　ｌ：　Ｒ
Ｅ　Ｑ　Ｐ　ＲＳの値を入れ（ステップ３３７）、ＲＥ
ＱＰＲ３の示すプロセスのカレントベクタのビットだけ
をセットし、他はリセットする（ステップ５３８）。こ
れらの処理によって退避エリアにはＲＥＱＰＲ５の示す
プロセスのレジスタの値が入っているので、復帰先はＲ
ＥＱＰＲ３の示すプロセスとなる。

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

まず、Ｒバッファ３０４にデータが有ることをチエツク
しくステップ５５０１）、その後にＵＲ／＜ッファ３０
６の空きをチエツクする（ステップ５５０２）。

ＵＲ，（ッ７ア３０６の空きかないときは（ステップ５
５０２でＮｏ）、ホストプロセスの起動要求をリクエス
トベクターによって行ない（ステップＳ　５０３）、Ｕ
Ｒバッファ３０４に空きを作るようにする。そして、５
５０１に戻る。

ＵＲバッファ３０６の空きがあるときは（ステップ５５
０２でＹＥＳ）、Ｒハンファ３０４よりデータを取り込
み（ステップ５５０４）、プロトコル変換処理（ステッ
プ８５０５〜５５０８．５５１３）を行なう。すなわち
、制御コードであれば（ステップ５５０５でＹＥＳ）、
フード変換処理（ステップ５５０６、第１３図参照）を
行い、必要ならばランドスケープ指定コマンドをＵＲバ
ッファ３０６に送す、上位プロセス（ホストプロセス）
のリクエストベクターのビットをセントする。そしてス
テップ５５０１に戻る。制御コードでなけれは、次にス
テップ５５０８で印字データであるか否かを判定する。

印字データでなければ、データをそのままＵＲバッファ
３０６に賓き込み（ステップ５５０９）、ステップ５５
０１１こ戻る。

ステップ５５０８で印字データであると判定されたとき
は、次にＰＡＧＥ　　ＷＲＩＴＥフラグが０かどうか、
つまりそのページで初めて印字データを受けたかどうか
をチエツクしくステップ５５１１）、受信しているとき
１まＰＡＧＥ　　ＷＲＩＴＥフラグを１にセットする（
ステップ５５１２）。

最後にデータ変換を行い（５５１３）、ＵＲバッフ７３
０６に書き込み（ステップＳ　５０９）、ステップ５５
０１に戻る。

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

次に、制御コードのコード変換処理（第１２図ステップ
ｓ　５０５）の詳細を第１３図に示す。

ステップ５６０１で、Ｒバッファ３０４より読み込んだ
データがライトマージン設定コマンドであると判定され
たときは（ステップ５６０１でＹＥＳ）、次にそのペー
ジに印字データが書き込まれたことを示すフラグＰＡＧ
Ｅ　　ＷＲＩＴＥが１かとうかをチエツクしくステップ
５６０２）、ＰＡＧＥ　　ＷＲＩＴＥフラグが０のとき
、つまりそのページに印字データが書き込まれていない
とき（ステップ５６０２でＹＥＳ）には、ステップＳ６
０３以下の処理を行なう。ステップ５６０３ではライト
マージン設定コマンドのパラメータが印字可能エリアの
最大横幅を示すＲＩ　ＧＨＴＭＡＸを越えているかとう
かをチエツクする。越えているとき（ステップ５６０３
でＹＥＳ）は、横長印字をするためにランドスケープ指
定コマンドをＵＲバッファ３０６へ送り（ステップ５６
０４）、現在のライトマージン値を示すＲＩ　ＧＨＴＭ
Ｇにパラメータの値をセットする（ステップ５６０５）
。ステップ５６０３でＮＯのときはポートレート指定コ
マンドをＵＲバッファ３０６へ送り（ステ・ン７’５６
０６）、ステップ５６０５に入ってＲＩ　ＧＨＴＭＧに
パラメータの値をセントする。ステ・７プ５６０７〜５
６１４のステップはＰＡＧＥ　　ＷＲＩＴＥフラグの管
理を示している。まず、改頁コマンド（ＯＣＨ）のとき
は（ステップ５６０７でＹＥＳ）ＰＡＧＥ　　ＷＲＩＴ
Ｅフラグを０にセントした後（ステップ５６０８）、改
頁コマンドをＵ　Ｒ／（−ンファ３０６へ送る（ステ７
プ５６０９） 次にラインフィードコマンドのときは（ステ・ンプ５６
１０でＹＥＳ）Ｙ方向のカーソルを１行分下方へ動かし
くステップ５６１１）、Ｙ方向のカーソルか設定されて
いるページ長を越えたかどうかをチエツクする（ステッ
プ５６１２）。

ここでページ長を越えたときは（ステップ５６１２でＹ
ＥＳ）Ｙ方向のカーソル値を０へ動かし、改頁の処理（
ステップ５６０８，５６０９）を行なう。

その他のコマンドのときはそのコマンドに対応した変換
コマンドをＵＲ／Ｘツファ３０６へ送るが（ステップ５
６１４）、ここでは詳しくは説明しない。

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

処理の流れを説明すると、まずホストプロセスに用いて
いるフラグの初期化を行う（ステップ５５１）。具体的
には、ユーザープロセスの実行の有無を示すＵＳＥＲフ
ラグをＯにリセットし、受信データ処理ルーチンで仮イ
メージ編集中であることを示すＬＰＷＲＩＴＥフラグを
０にセットする。そして、中間コード作成の準備として
フォント部３３よりフォント属性を読み込む（ステップ
５５２）。このときフォント部３３のフォントカートリ
ッジ内にユーザープロセスか有るかどうかをチエツクし
て（ステップ５５３）、有りの場合はシステムＲＡＭ３
０７の所定の領域にユーザープロセスをロードする（ス
テップ５５４）。そして、ロード終了（ステップ５５５
）を待ってユーザープロセスの実行を示すＵＳＥＲフラ
グを１にセットしくステップ５５６）、リクエストベク
ターのユーザープロセスのビットをセットする（ステッ
プ５５７）。これは、最下位のプロセスであるユーザー
プロセスが有るときは常にリクエストベクターのビット
をセットしておき、自分自身の実行を放棄することの無
いようにするためである。これらの初期化動作（ステッ
プ５５８〜ステツプ５５７）を行なった後、主ループ（
ステップ５５８〜ステツプ５６３）に入る。

主ループではパケットバッファ３０８の空エリアかなく
なるとき（ステップ５５８でＮＯ）、ＵＳＥＲフラグ＝
１のとき（ステップＳ５９でＹＥＳ）ＵＲバッファ３０
６にデータがないとき（ステップ５６０でＮｏ）、ＵＳ
ＥＲフラグ＝０のとき（ステップＳ５９でＮｏ）でＲバ
ッファ３０４が空になるとき（ステップ５６１でＮｏ）
以外は、受信データ処理（ステップ５６２）を行なう。

また、受信データ処理を行なわないとき（ステップＳ５
８、ステップ５６０、ステップ５６１でＮＯ）はＪＯＢ
ＯＵＴ処理Ｉ　（第１５図参照）を実行する（ステップ
５６３）。ＪＯＢＯＵＴ処理ｌでは処理区トプロセスが
スケジューラに対して上位プロセス（実施例ではパケッ
トプロセス）への切り替えを要求するために、リクエス
トベクターを更新する。

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

第１５図は、ＪＯＢＯＵＴ処理ｌのフローを示す。この
処理では、ホストプロセスがスケジューラに対して上位
プロセス（笑施例ではパケットプロセス）への切り替え
を要求するために、リクエストベクタのパケットプロセ
スビットをセットしくステップ５７２）、ユーザープロ
セスがある場合（ステップＳ７３でＹＥＳ）にはホスト
プロセスは最下位プロセスではないの゛でリクエストベ
クタのホストプロセスのビットをリセットし自らの実行
を放棄する。またユーザープロセスの無い場合（ステッ
プ５７３でＮＯ）は、ホストプロセスが最下位プロセス
となるのでリクエストベクタのホストプロセスのヒツト
はセットしたままにしておく。

なお、これらの処理中はタイマー割り込みを禁止して（
ステップ５７１，５７５）誤動作を防ぐようＩこしてい
る。

受信データは、第１６図に示すようにデータの受信割り
込みによってデータ処理インターフェイス３０１より取
り込まれ（ステップ５１９１）、Ｒバッファ３０４に蓄
積される（ステップ５１９２）。

受信データ処理（Ｓ６２）のフローを第１７図（ａ）、
（ｂ）に示す。

まず、受信データの処理を行なうためにＲバッファ３０
４よりデータを取り出す必要がある。ここで、ユーザー
プロセスが有る場合は（Ｕ　Ｓ　Ｅ　Ｒフラグ＝１）、
Ｒバッファ３０４のデータのプロトコル変換を行なった
後ＵＲバｙ　７−ｒ　３０６に蓄積されているのでユー
ザープロセスを優先する。

そこで、ＵＳＥＲフラグが１のときは（ステップ５１０
１でＹＥＳ）ＵＲバッファ３０６より、ＵＳＥＲ７ラグ
がＯのときは（ステップ５１０１でＮｏ）Ｒバッファ３
０４よりデータを取り込む（ステップ５１０２．ステッ
プ５１０７）。

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

・ＩＦＣ関連コード（プリント・エンジン関連コード）
（ステップ５１０３〜ステツプ５１０５）・ＪＯＢ制御
コード（ＪＯＢＳＴＡＲＴ、ＰＡＧＥＥＪＥＣＴＸステ
ップ５ＩＯ８〜ステップ５１１２）。

・書式制御フード（ステップ５１１３〜ステツプ・印字
データ（文字コード、グラフィックコード）（ステップ
５１２８〜ステツプ５１３４）・ユーザーフロセス制御
コード（ステップ５ｌ１８〜ステツプ５１２２） まず、印字データの場合は（ステップ５１０３．５１０
８．５ｉｌｏ、５１１３．５１１５．５１１７．５１２
３．５１２６でいずれもＮＯ）、対応するフォーマット
の中間コード（パケット）に変換してパケットバッファ
３０８に出力する。すなわち、第１７図（ｂ）に示すよ
うに、仮イメージ編集を示すＬＰＷＲＩＴＥフラグがＯ
であれば（ステップ５１２６でＹＥＳ）、ＬＰＷＲＩＴ
Ｅフラグを１にセットする。次に文字コードの場合は（
ステップ５１２８でＹＥＳ）、フォント・イメージ書込
部３１１へのフォーマットと同じでフォント・パターン
のアドレス（ステップ５１２９）、イメージ・エリア上
の印字位置に対応するＢＭ−ＲＡＭ３２への書込みアド
レス（ステップ５１３０）お、１−び書込みモード（ス
テップ５１３１）をパケットバンフ７３０８に出力する
。グラフィックコードの場合は（ステップ５１３３でＹ
ＥＳ）、グラフィックイメージ書込部３１６へのコマン
ドと同一のフォーマットでパケットバッファ３０８に出
力される（ステップ５１３４）。このとき、文字コード
の場合は、次の文字印字位置を更新しておく（ステップ
５１３２）。

第１７図（ａ）に示すように、ＩＦＣ関連コードの場合
は（ステップ５１０３でＹＥＳ）、インターフェイス制
御部（ＩＦＣ）４０に出力するものであるが、印字デー
タとの同期をとるため、印字デ−夕とは形式の異なるフ
ァンクションタイプの中間コードとしてバケットバッフ
ァ３０８へ出カシ（ステップ５１０４）、ＪＯＢＯＵＴ
処理１を行う（ステップ５１０５）。

ＪＯＢ制御コードには、ページの区切りに用いるＰＡＧ
Ｅ　　ＥＪＥＣＴコード（ステップ５ｌｌＯでＹＥＳ）
と、ページ群の区切りに用いるＪＯＢＳＴＡＲＴ（ステ
ップ５１０８でＹＥＳ）の２つがある。どちらもＩＦＣ
関連コードと同様に、バケットバッファ３０８に出力す
る（ステップ５１０９　ステップＳ　１１１）。

書式制御コードの場合は（ステップ５１１３でＹＥＳ）
、印字の書式を制御する（Ｓ　１１４）。

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

８１７図（ｂ）図に示すように、次にユーザープロセス
ロード要求コードの場合は（ステップ３１１７でＹＥＳ
）、ユーザープロセスの有無をチエツクしｔ二後（ステ
・ンプ５１１８）、フォントカートリ・ンジよりユーザ
ープロセスのプログラムのロード処理を行ない（ステッ
プＳ　１１９、ステップ５１２０）、ＵＳＥＲフラグの
セントをしくステップ５１２１）、さらにリクエストベ
クターのユーザープロセスヒツトをセットする（ステッ
プ５１２２）。

またユーザープロセス解除コードの場合（ステップ５１
２３でＹＥＳ）は逆にＵＳＥＲフラグをリセットしくス
テップ５１２４）、リクエストペクタのユーザープロセ
スビットをリセットする（ステップ５１２５）。

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

【図面の簡単な説明】

第１囚は、プリンタシステムの４１１成図である。 第２図は、プリンタンステムの斜視因である第３図は、
プリンタンステムの制御系のブロック図である。 第４図は、ビットマツプ制御部のブロック図である。 第５図は、ビットマツプ書込部のブロック図である。 第６図は、縦長のイメージの図である。 第７図は、横長のイメージの図である。 第８図は、第７図の図を回転したランドスケープードで
のイメージの図である。 第９図は、カレントプロセスブロンクの構成図である。 第１０［ｆｆｌは、スタートプロセスのフローチャート
である。 第１１図は、スケジューラのフローチャートである。 第１２図は、ユーザープロセスのフローチャトである。 第１３図は、コード変換処理の７０−チャートである。 第１４図は、ホストプロセスの７０−チャートである。 第１５図は、ＪＯＢＯＵＴ処理ｌのフローチャートであ
る。 第１６図は、受信割込のフローチャートである。 第１７図（ａ）、（ｂ）は、受信データ処理のフローチ
ャートである。 ３０・・・ビットマツプ制御部、 ３２・・・ＢＭ−ＲＡＭ、３０３・・・ＣＰＵ、３０４
・・・Ｒバッファ、 ３０６・・・ＵＲバッファ、 ３０８・・・バケットバッファ。 特許出願人　ミ　ノルタ　カ　メ　ラ株式会社代　理　
人　弁理士　青白　葆　ほか２名第 図 第 図 囚旦甲ま方向 第６図 第７図 第 図 ＡＩＯ印字方向 第 図 第１１図 第１Ｏ図 第 １５図

Claims (1)

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