インフラまわりのプロになりたい

---

- CUPS とは -

CUPS とは 「Common UNIX Printing System（カップス）」 の略でして、「Linux の印刷システム」 です。
「印刷システム」 という言葉にあまり馴染みがないので、まずはイメージから掴んでいきます。


以下、「Windows の印刷システム」 を例に挙げます。
基本的に Windows で印刷するときは、プリンタドライバ 「だけ」 インストールすれば印刷が可能です。


↑図1：Windows 印刷フローの簡易図

「だけ」 という表現に違和感を覚えるかもしれませんが、実は Windows という OS には、既に印刷システムが搭載されています。

他にも印刷システムだけでなく、様々なシステムが Windows には搭載されていますので、ユーザーはデバイスに対して 「ドライバのみ」 意識すれば問題ありません。


↑図2：印刷システムを加えた簡易図


さて、ここからが CUPS の説明です。
冒頭でもお話しましたが、Linux はプリンタドライバを入れただけでは印刷ができないことが多いです。


↑図3：冒頭の「なぜ動かない！？」がこの状態

では、なぜ印刷ができないのでしょうか？
それは Linux インストール時のデフォルトが、印刷システムを搭載していないからです。

これは印刷システムに限らず、Linux では 「必要に応じてシステム（モジュール）を追加」 する必要があります。
非常に煩わしいかもしれませんが、それゆえにリソースを効率的に使えるメリットもあるのです。

勘の良い方ならもうお分かりかと思いますが、一般的な Linux の印刷システムが、今回メモする 「CUPS」 なのです。


↑図4：CUPS は印刷を制御する


こうやって見ると、Windows と Linux の特性も見えてくるような気がしますね。

* Windows
　特性： あらかじめ様々なモジュールが組み込まれている。
　長所： モジュールの理解が必要ないため、エンドユーザーは簡単に操作できる。
　短所： 不必要なモジュールが満載なことから、リソースの無駄遣いの可能性大。

* Linux
　特性： 必要に応じてモジュールを組み込む必要あり。
　長所： 必要な機能のみモジュールが動くため、リソースを効率よく使える。
　短所： モジュールの存在を知らないと、本記事を書くような手間が発生する。OTL

こういったところでしょうか。

---

- Linux の印刷フロー -

Linux の印刷フローを見ていきましょう。
まずは下図から簡単なイメージを掴みます。


↑図5：印刷フロー

おおまかなフローを箇条書すると、以下のようになります。

　1．ユーザが印刷を開始
　2．CUPS が印刷データを受け取る
　3．CUPS が適切なプリンタへ印刷データを送信
　　3’．プリンタが PS 未対応の場合、GS が印刷データを変換する
　4．プリンタが印刷データを受け取り、印刷をする

CUPS はユーザから 「印刷ジョブ」 を受け取り、それをプリンタへ橋渡しする役割を担っています。
CUPS が 「印刷を制御するシステム」 だとイメージできたと思います。

次は、Linux の印刷に不可欠な 「Postscript」 についてメモします。

※ CUPS の簡単な説明は以上です。
Linux に深く携わることのない方は、ここまでのイメージで全く問題ないと思います。
ライトなユーザーは、以下を読み飛ばして下さい。

---

- Postscript とは -

前項では、おおまかな CUPS の動きを解説しました。
ここからは CUPS の細かな動きを追ってメモします。

一般的に Linux では、印刷データを 「Postscript ファイル」という形式で扱います。
CUPS の動きを知るには、まずはこの Postscript の仕組みの理解が不可欠です。


Postscript は Adobe 社が開発した 「ページ記述言語」 です。
通常のプリンタの場合、クライアントサイドで描画処理（プリンタが解読できる言語に変換）しますが、ページ記述言語は、プリンタサイドで描画処理を行わせる仕組みをしています。


↑図6：PS 非対応プリンタと PS 対応プリンタ

通常の印刷 （図6上） では、印刷するファイルをクライアント側で 「ラスタデータ」 に変換します。
このラスタデータを受け取ったプリンタは、このデータをもとに紙へ印刷をするのです。
※ラスタデータとは、「プリンタが認識できるデータ」 だとイメージしてください。


一方で Linux が扱っている Postscript 印刷 （図6下） は、通常の印刷とはかなり異なります。

まず印刷するファイルを、ラスタデータではなく 「Postscript データ」 という形式にクライアント側が変換します。
この Postscript データは、ラスタデータのようなバイナリとは違って、完全なテキスト形式です。

このテキスト形式の Postscript データには、「印刷情報」 がギッシリと書かれており、メモ帳などでこのデータを開くと、曲線の支点の座標・カラー情報などが確認できると思います。

そしてこのテキスト形式をプリンタが受け取ると、プリンタ側でラスタデータに変換して印刷します。
プログラミングに馴染みのある言い方をしますと、プリンタがインタプリタするイメージでしょうか。

このように Linux が扱う Postscript は、プリンタ側でラスタデータに変換する仕組みなのです。


ところが、プリンタ側でラスタデータを処理するには、Postscript に対応したプリンタが必要です。
印刷業界ならともかく、一般の方で Postscript 対応プリンタを扱うことは稀でしょうから、一般のプリンタでは、Postscript データの印刷ができないのです。


↑図7：PS 非対応プリンタは PS データを扱えない

「じゃぁ、Linux の印刷には Postscript 対応プリンタが必須？」

と思うかもしれませんが、その必要はありません。
Postscript 非対応プリンタでも、Linux の印刷は可能です。

では次に、その印刷を可能にさせる、「Ghostscript」 または 「CUPS フィルタ」 という仕組みをメモします。

---

- Ghostscript とは -

Ghostscript は、簡単にいいますと 「Postscript をラスタデータに変換するインタプリタ」 です。
※ CUPS フィルタ も似た仕組みなので、同じイメージと受け止めてください。

Postscript 非対応のプリンタは、Postscript データを読み取ることができませんが、ラスタデータを読み込み、印刷することは可能です（図6上） 。
Ghostscript は Postscript 非対応のプリンタでも印刷できるよう、CUPS と連動して、Postscript をラスタデータに変換する働きをします。


↑図8：GS は PS をラスタデータに変換

このような、ラスタイメージの変換機能のことを 「RIP （Raster Image Processor）」 といいます。
Ghostscript などの RIP によって、Postscript 非対応のプリンタでも Linux 印刷が可能になるのです。

ただ、Ghostscript はクライアント側でラスタデータを生成することから、Postscript 対応プリンタと比べると、印刷が遅延する傾向にあります。（最近は PC の性能やネットワークの足回りが太いので、遅延といっても微々たる程度かもしれませんね）

---

- CUPS のフロー -

「Linux の印刷フロー」 でもメモしましたが、CUPS はアプリケーションから印刷データを受け取ると、プリンタの Postscript の対応状況を確認したのち、プリンタへ印刷データを送ります。

ここでは、これら一連の処理を行う CUPS の 「内部的な動き」 を、簡単にメモしていきます。

まず CUPS は、以下の4つのシステムから成ります。

1．スケジューラ / スプーラ　（印刷ジョブの管理）
2．フィルタ　（印刷データをプリンタ言語に変換）
3．バックエンド　（プリンタへ印刷データを渡す）


↑図9：CUPS 内部のシステム

上図を見ていただければ、大体のイメージはつかめると思います。

「スケジューラ／スプーラ」 は、アプリケーションから送られてくる印刷ジョブを受け取り、「フィルタ」 へ印刷ジョブを転送する役割を担います。

「フィルタ」 は、印刷データをプリンタが印刷できるプリンタ言語に変換します。
自身は CUPS フィルタ という、独自でプリンタ言語に変換するフィルタリング機能を持っていますが、それだけでは事足りない場合、Ghostscript などの外部フィルタを使ってラスタデータに変換します。


↑図10：フィルタシステム

「バックエンド」 は、印刷データをプリンタに転送します。
バックエンドは、USB ポート、シリアルポート、イーサネットなどなど、様々な接続方式に対応しています。


↑図11：バックエンドシステム

やや大雑把に書いてしまいましたが、これくらいの認識で問題ないと思います。

---

- 最後に -

以上で、CUPS 印刷システムのメモは終了です。
つたない説明でしたが、CUPS のイメージが掴めていれば幸いです。

もっと CUPS システムについて詳しく知りたい方は、以下の画像 （英語版 Wikipeda の CUPS 画像） を見ていただければと思います。


↑図12：CUPS フローの詳細

上図のような本格的な図を見ると、僕の記事がいかに 「端折っているか」 が分かると思います。
けれども、前向きに考えれば 「端折っているかの判断がつくまで理解できた」 ということですので、メモしてよかったと思っています。

…あとは、僕の知識が間違っていないことを祈るばかりですヽ(´Д`；)ﾉｗ



- 教訓 （余談） -

僕が初めて CUPS という言葉を知ったのは、今から2年ほど前の 2011年 でした。
日医標準レセプトソフト (ORCA） というレセコンのプリンタ設定をしたときです。OS は Ubuntu 10.04 でした。

あのころは Linux の右も左もわからず （今もわからないですけど）、ただただマニュアル通りに設定しました。
「印刷できればいいや」 的なノリで設定し、CUPS も Ghostscript も 「よく分かんないけど、とりあえずインストールすれば印刷できるアプリ」 という大した理解をしないまま、プリンタの設定を完了させました。


それから2年後の2013年 （この記事を書くきっかけになった出来事）、次は 「ラベルプリンタの設定」 を再び CentOS に施すことになったのですが。。。
ただでさえ珍しいラベルプリンタに加え、Linux の印刷ですからインストールマニュアルなんかありゃしない。
冒頭にも書きましたように…、

「プリンタドライバをインストールして、プリンタを認識させて……って、なぜ動かない！？」

というトラブルが続出です。

その後も数日間、印刷できないトラブルが続きました。
もう印刷を諦めかけたとき、ふと日医標準レセプトソフトで Ghostscript をインストールした記憶がよみがえりました。
結果、その Ghostscript インストールが幸運にも当たりまして、今回は無事にラベルプリンタの印刷に成功したのです。

（2年前の日医標準レセプトソフトのときに CUPS や Ghostscript についてもっと調べていれば、今回はこんなに悩まずに済んだだろうに…）

こういった経緯から、今回は CUPS と Ghostscript についての記事を書き始めました。
おかげさまで 「なぜ動かない！？」 と再三叫んでいた Linux 印刷も、この記事を書き終えた今となっては、「確かにソレじゃ動かないよね」 という理解もできました。


これはプリンタに限らず、様々なシステムやアプリケーションでも当てはまると思います。


インフラまわりのプロを目指す限り、「とりあえず分かんないけど動いた。じゃぁ次に行こう」 という認識はいけないことを知った、そんな CUPS の印刷システムでした。