始めの言葉

「プリンターから印刷できて当たり前」と、ユーザーからもSIerからも軽視されがちなプリンターの世界ですが、実際にはお困りだったり、思ったような印刷結果が得られないまま我慢してお使いの皆様のために、今までの経験が役立てばと、このブログを立ち上げました。印刷の基本から、応用情報、問題の解決方法を情報発信すると共に、PDF化など、これからどうするかについても、ご相談に乗れれば幸いです。ご質問はコメントでお寄せください。

2017年6月25日日曜日

IBM 小型レーザー・プリンターの今まで -第16回- "PAGES"-10

ここで、少し脇道に逸れますが、PAGES モードのプリンターにとって外せない話題が、5400エミュレーターII です。
5400エミュレーターII は、前々回の IBM 小型レーザー・プリンターの今まで -第14回- "PAGES"-8 でご紹介した "Infoprint 13x6J" シリーズ 3モデルを発表した後の、2006年10月に発表されました。
5400エミュレーターII 外観

5400エミュレーターIIについては、既に LAN 直結で双方向通信する印刷方式"Telnet5250E" - 第5回 - でご紹介していますので、ここでは簡単な概要のみお話ししたいと思います。

初代 5400 エミュレーターは、 5400 シリーズ・ライン・プリンターと同様に、5577 系のドット・プリンターをTelnet5250E を使って、AS/400 と直接 LAN 接続して使用したいというお客様のご要望に基づいて製品化されたものです。その後、ドット・プリンターでできるのなら、PAGES のレーザー・プリンターでも、Telnet5250E 接続にできるはずというお客様の声に押されて、初期設定によって、レーザー・プリンターも選択できるようになった 5400 エミュレーターII ができました。
技術的な要素の他には営業政策的な意味もあったと思いますが、初代 5400エミュレーターからの移行(改造)はできず、5400エミュレーターII は、別製品として発表されました。
5400エミュレーターII の開発に当たって、一つの山は、プリンターと接続するパラレル・インターフェイスの規格が、ドット・プリンターとレーザー・プリンターでは異なる点にありました。
5400エミュレーターでは、ドット・プリンターに AS/400 からの印刷データを送信するだけでなく、逆に、プリンターから、印刷中とか、用紙切れや用紙ジャムといったエラー状態、といった情報を把握して AS/400 に送信するために、パラレル・インターフェイスの規格の中でも、コンバージド・モードという、正にこの目的にぴったりのインターフェイスの規格を使用していました。(ちょうど、ドット・プリンターをダム端末、即ち、端末専用機に接続する場合と同じです。)
ところが、当時のレーザー・プリンターには既にコンバージド・モードはありません。そのため、5400エミュレーターII では、パラレル・インターフェイスとして標準の IEEE1284 規格に合わせたインターフェイスで分かる範囲で、プリンターの状態を把握することになりました。
その結果、5400エミュレーターII の初期設定を行なう Web ページの画面では、初めにドット・プリンターに接続するのか、レーザー・プリンターに接続するのかを選択するようになっていました。それによって、インターフェイスの規格が変わり、内部で処理するマイクロコードが全く異なってくるからです。
5400エミュレーターII の機能

お客様のご要望に合わせて機能を拡張し、対応機種を増やしてきた 5400エミュレーターII ですが、いくつかの制約はありました。

- "Infoprint13x6J" の後継シリーズである "Infoprint17x6J"シリーズでは、パラレル・インターフェイスがハーフ・ピッチ・サイズで小型であったため、5400エミュレーターII を取り付けるためには、付属の変換アダプターが必要でした。その結果、取り付けると 5400エミュレーターII 自体の重さで下に傾いてしまい、接続が不安定になるという現象が発生しました。

- 更にその後に発表された "InfoPrint SP 8200 モデルN50" は、50ページ/分という PAGES モードを持ったレーザー・プリンターでは最高速のモデルでしたが、パラレル・インターフェイスが無かったため、5400エミュレーターII を使用できませんでした。

- レーザー・プリンターは受信バッファーのメモリー・サイズが大きいため、プリンター側では印刷データをたくさん溜められます。受信済みの印刷データを印刷するのは、プリンターの責任という考え方でできていますので、プリンターの電源を切られない限り、用紙ジャムや用紙切れ等のエラーが発生しても、印刷完了するまでは、メモリーから印刷データが消されることはありません。その結果、5400エミュレーターII 経由の印刷では、ページ数が少ないスプールの場合、印刷データは、一瞬でプリンター側に溜められますので、5250 端末の OUTQ の画面での、スプールの取り消しや保留が効かないということが発生します。また、取り消しできたとしても、想定以上の多くのページ数を印刷した後になってしまうということになります。この点は、受信バッファーの小さいドット・プリンターと異なる点で、如何ともしがたい点です。

- 5400エミュレーターII の価格が、レーザー・プリンター本体並みと揶揄されるくらいになってしまいました。これは開発費用の影響もありますが、一方ではレーザー・プリンターの低価格化がかなり進んだという面もあるかと思います。(初代の 5587-G01 の価格や速度と、Infoprint1000J シリーズのそれを比較すると 20年という歳月を考えさせられます。)



2017年6月18日日曜日

IBM 小型レーザー・プリンターの今まで -第15回- "PAGES"-9

プリンターを PAGES モードに切り替えるためのコマンドが、PAGES のコマンドの中にあります。それだけでは、PAGES モードに切り変わるためには、PAGES モードのコマンドを正しく処理して PAGES モードになる必要があるといった、ちょうど、鶏と卵の関係のようになってしまいます。
実際には、プリンターの処理機能の基礎となるレベルのマイクロコード(ファームウェア)が、プリンターがどのモードであっても、このコマンドを処理できるようにできているのだと思います。

コマンド自体は、Web 上で公開されている PCOMM や CA の 用の PDF ファイルをメモ帳で開くと、次のように記述されていることで、分かります。

/* エミュレーションモード設定  */
CDS EQU 1B 7E 12 00 01 11                       /* PAGES 選択     */

START_JOB=CDS INZ SEL SA4 FA4 SRO P10 LL6

CDS は、Change Data Stream を略して付けた名称と考えられます。
コマンドとしては、"1B 7E 12 00 01 11" であって、これは "5577 モード" への切り換えにもそのまま使用できます。
"START_JOB=" の直後にこのコマンドが記述されていることによって、プリンター・セッションから送信される印刷データの先頭で、プリンターを "PAGES モード"、若しくは "5577 モード" に切り替えて、その後の PAGES コマンドを正しく処理できるようにしている訳です。

Infoprint 1000J シリーズの基本モードである "RPCS モード" のプリンター・ドライバーでは、プロパティ画面のメニューの中で、"基本設定" -> "その他" と選択した次のような画面に "印刷後のエミュレーション" という設定項目があります。
RPCS モードのドライバーで元のエミュレーションに戻す設定

これを、上の画面のように"直前のエミュレーション"と設定しておくと、PAGES モードで印刷後、このドライバーを使って RPCS モードを使って印刷した場合には、プリンターを元のモード、つまり "PAGES モード"に戻すコマンドを、発行すると考えられます。
従って、"PAGES モード"での印刷から始まった場合には、この設定のみで問題無いかもしれませんが、必ずしもそうではないので、"PAGES モード"を使用するプリンター・セッション経由の印刷では、先頭で切り換え用のコマンドを発行する必要があるということです。

プリンター・セッション経由の印刷以外で、PAGES モードを使う印刷としては、OS/400 の HPT 機能を使った、LAN 直結印刷があります。
プリンター・セッション経由の印刷において、PAGES モード 設定のコマンドを使用することは、Infoprint 1000J シリーズの "PAGES 使用解説書"に記載されていることですが、HPT 機能を使った LAN 直結印刷についての記述はありませんでした。
ところが、実際には、1 台の Infoprint 1000J に対して、RPCS モードのドライバーを使った WindowsXP からの印刷と、HPT 機能を使った AS/400 からの LAN 直結印刷を行なっている中で、AS/400 からの印刷が、文字化けしてしまうという問題が発生したお客様がありました。

"RPCS モード"のドライバーで、"直前のエミュレーションに戻す"設定は行なったものの、問題は解決しません。プリンターが、OS/400 から送信されてくる "PAGES モード" の印刷データを正しく識別できず、"RPCS モード"の状態のまま処理してしまうため、文字化けとなってしまうのです。

PDF ファイルと同様に、印刷データの先頭に、"PAGES モード"への切り替えコマンドを埋め込むには、"WSCST ファイル"を編集します。
"WSCST ファイル"を変更する方法は、Web で公開されています。リンク先の 7 ページ目以降をご覧ください。
また、"PAGES モード" 用の"WSCST ファイル"のサンプルも、同じように公開されています。リンク先のテキスト・ファイルを開いてみると、その中に次のような箇所があることが、分かります。

    :INITPRT
      DATA ='1B7E010000'X                   /*初期化設定*/
            '1B7E0300013C'X                 /*行ピッチ設定6LPI */
            '1B7E02000132'X                 /*文字ピッチ設定10CPI */
            '1B7E5A000403AE0000'X.          /*コードページ変更942 */
 
ここが、プリンター・セッション用の PDF ファイルの中の "START_JOB=" 以降に該当します。
そこで、DATA = の次に、"PAGES モード"への切り替えコマンドを、次のように追加します。
 
    :INITPRT
      DATA ='1B7E12000111'X                 /* PAGES 選択*/
            '1B7E010000'X                   /*初期化設定*/ 
 
このお客様では、この "WSCST ファイル" を指定したリモート OUTQ を通して印刷データを送信することによって、プリンターが、先ず "PAGES モード" に切り替わってから、後続のデータを処理するようになり、その結果、文字化けは解消されました。

2017年6月11日日曜日

IBM 小型レーザー・プリンターの今まで -第14回- "PAGES"-8

2003年は、WindowsXP がリリースされた年です。この年、IBM は、小型レーザー・プリンターのシリーズとして、"Infoprint 1000 シリーズ"を発表しました。
Infoprint 1332
MFPオプション付き Infoprint 1352
これらの製品は、Lexmark 社製品から OEM 提供を受けたものと思われます。社内開発を断念し OEM 製品による製品シリーズの拡充に切り替えたと考えられ、個人的には残念だったことを覚えています。
国内向け製品も同じ方針に合わせて、日本版という意味で、"Infoprint 1000J シリーズ"と銘打って、A3 サイズ対応で、印刷速度の異なる 3 モデルを、同じ年に発表しています。
この時から、それまでの 4 桁のマシン・タイプと 3 桁のモデル名の他に、各モデルに対応する "Infoprint 1316J" とか "Infoprint 1356J"といった名前が付くようになりました。その結果、この 3 モデルの概要は、次のようになります。

モデル名 型式         印刷速度  最大用紙サイズ
1356J     5596-3M6  32 枚/分  A3
1336J     5596-3M4  28 枚/分  A3
1316J     5596-3M2  22 枚/分  A3

標準モデルでは、PAGES に対応していません。標準で対応しているのは、"RPCS" モードとあることから、リコー社からの OEM 製品であることが分かります。
付属のプリンター管理ツールにも、"Infoprint Navigator" とか "Infoprint Administrator" というように、"Infoprint" の名前が付けられています。
標準では、リコー社独自のプリンター制御言語 "RPDL" にも対応していますが、Windows からの印刷では、"RPCS" モードがお勧めとなっています。"RPCS" モードは、主にイメージ・データとして印刷データを生成し、解像度も 1,200DPI と高くなっている点では、"5589-L36" の時の専用モードと類似の位置づけ、考え方の印刷データ形式と言えると思います。
Infoprint13X6J 標準とフル・オプション付き

では、PAGES はどうなったのでしょうか ? PAGES モードは、遅れてオプションとして発表され、PAGES オプション付きのキッティング・モデルとしてのみ、提供されることになりました。
キッティング・モデルには、発注用に "M" の代わりに "P"が付いた型式(例えば、5596-3P6)が付けられましたが、このことにより、次のような制約が発生しました。

- 標準モデルを購入後、PAGES オプションが必要になっても後付けができない。
- 購入した製品に、PAGES オプションが付いているかは、プリンターの構成情報を印刷しないと分からない。つまり、"5596-3M6" というプリンターに、PAGES オプションが"キッティング"されているので、プリンターに貼られているシールには、"5596-3M6" としか記載されていないということです。

その結果、特約店やお客様では混乱が発生したことがあることは、否めません。

また、標準モデルでは、オプションも含めると、次のようなに多くの種類の印刷データ形式に対応していて、受信した印刷データを自動認識することもできました。
- RPCS
- RPDL
- PostScript3
- ESC/P
- PR201H
しかし、PAGES に対しては少し冷たく、自動認識できないことがありました。そのため、Windows からの "RPCS" モードを使った印刷と、PCOMM プリンター・セッションからの "PAGES" モードでの PDT 印刷が、1 台のプリンターに対して混在する場合、問題が発生することが、少なくありませんでした。その対策に関しては、次回、お話します。
 

2017年6月4日日曜日

IBM 小型レーザー・プリンターの今まで -第13回- "PAGES"-7

PC の OS の主流が、まだ、J-DOS や DOS/V だった頃には、ワープロや表計算、オンライン端末といったアプリケーションが、それ自身で印刷データを生成して、プリンターに送信してくるという仕組みでした。
一方、インパクト・プリンターと比べて、レーザー・プリンターは、縮小指定、用紙トレイ指定、用紙方向縦/横指定、4 辺の余白の指定等々、制御コマンドの種類が多いのですが、メーカー間で統一されたコマンドは、ありませんでした。
そうなると、各レーザー・プリンター・メーカーは、標準のプリンター制御コマンドを独自の規格で決めて、多くのアプリケーション・メーカーに対応していただくことで、競争力になると判断したわけです。そして、更に、他社が真似して同じコマンドに対応してきたとしても、その時には、自社が先行してコマンドを拡張しておくことで、自社の優位性が保たれるとも考えました。

その際に、インパクト・プリンターの実績のあった、IBM と EPSON 社は、インパクト・プリンターのコマンドを独自に拡張する方式で、それぞれ、PAGES、ESC/Page というレーザー・プリンター向けの規格を作りました。それ以外のレーザー・プリンター・メーカー、例えば、CANON 社は、LIPS という全くレーザー・プリンター独自の自社規格を決めて、多くのアプリケーション・メーカーのサポートを得ていました。
その中で、多くのプリンター・メーカーがターゲットにしたのが、IBM の AS/400 やメイン・フレームのシステム・ユーザーです。この市場は大きいと判断したのだと思います。
それらのシステムからの印刷を行なうためのアプリケーションは、3270PC であったり、5250PC ですが、それらは、5577 形式か、ESC/P 形式のコマンドしか送信しません。そこで、5577 のマニュアルに記載されているコマンドの説明や、それらアプリケーションからの印刷データを調べて、5577 互換 + 各社独自のレーザー・プリンター制御コマンドという組み合わせの、所謂「5577 エミュレーション・コマンド」(エミュレーションとは、真似という意味)を、レーザー・プリンターのオプションとして販売しました。
5577 コマンドに対する各社の拡張

しかし、その後、Windows の登場によって、印刷データの流れは大きく変化し、アプリケーションは印刷データの生成という作業から解放され、その分の仕事は、自社プリンター用のドライバーの開発として、プリンター・メーカーに移ったわけです。自社の規格を業界標準として競争力を維持するという戦略の下に、独自規格でコマンドを決めてきたことが、Windows の登場によって、自社の負担になってしまったという、皮肉な結果になっています。

そのような時代の変化の下で、AS/400 も含めたホスト・システムから、端末アプリケーションを介して、(PAGES も含めた)5577 互換のレーザー・プリンターへの印刷という図式も、いつの間にか崩れてきたようです。
つまり、一般の Windows アプリケーションと同様に、PCOMM プリンター・セッション経由の印刷も、最早、PDT 印刷ではなく、PDT を指定しないドライバー印刷で対応可能になってきているようです。
これは、PCOMM 側の改良や、プリンター・メーカーによるドライバーの改良の両方が寄与していると思います。

さて、そうなってくると、PAGES の必要性は、どこかに残っているのでしょうか ?
それは、次の 3 つのケースに絞られるかと思います。
1. OS/400 のHPT 機能を使った、AS/400 からの LAN 直結印刷の場合
2. AS/400 上のアプリケーションとして、PAGES コマンドをキャラクター・モードを使って送信する場合
3. AIX 等の UNIX 系のシステムからの文字印刷の場合

Windows のドライバー印刷では、印刷データは、アプリケーションとプリンター・ドライバーが、MS 明朝や、MS ゴシック等々の Windows に付属のフォントのイメージを使って、文字もイメージ・データと各ページのイメージをプリンターに送信してきます。
それに対して、"1" と "3" は、途中にWIndows を介しませんから、文字は文字コードとしてプリンターに送られ、プリンターが内蔵フォントを使って印刷イメージを生成します。
次の画面は、OS/400 V7R1 において、リモートOUTQの設定の画面ですが、コマンド変換するための選択肢である "MFRTYPMDL" にも、例えば "*IBMPAGES300" が準備されています。これは、前回までお話した、300DPI の解像度を持つ、ネットワーク・プリンター・シリーズの PAGES オプション用のものです。
MFRTYPMDL *IBMPAGES300

"2" は、文字通り、キャラクター = 文字としてプリンターを制御する PAGES コマンドをプリンターに届けないとなりませんから、プリンター・セッションでは、印刷データはイメージではなく、文字コードや制御コマンドとしてプリンターに送信する必要があります。
例えば、スプール・データの 1 ページ目は、A3 サイズの用紙に印刷するが、2 ページ目以降は、A4 サイズ用紙に印刷するといった業務の場合、データの先頭で、A3 サイズの用紙がセットされた用紙トレイを指定し、2 ページ目の先頭では、A4 サイズの用紙がセットされた用紙トレイを指定するコマンドを、印刷データの中に埋め込むことになり、このような場合に、キャラクター・モードが使用されます。
この業務を継続するために、PAGES モードを持ったプリンターを使い続けるという方法以外に、PAGES という一種の制約を外すことを検討するのであれば、Mapping Suite のようなソリューションの導入を検討されるのが良いと思います。