共通UNIX印刷システム(CUPS)は 現在非常に一般的になってきている。すべての主要なLinuxディストリビューションは 現在既定値の印刷システムとしてこれと導入している。ただ、残念ながら、これは まだ非常に取っつきづらいツールである。ほとんどの場合、これはちゃんと動く。 多くの人は、これが動いている間は、その中身を覗きたくなく、それを “ブラックボックス”として扱う傾向がある。しかし、ひとたび 小さな問題が発生すると、どこからデバッグしていいかということを見つける 困難が生じる。CUPSに関連したより多量の情報もある、 旧式の印刷サポートも参照のこと。

CUPSは固有で強力な機能を持っている。その基本機能は容易に把握でき、 かつそれらは新しい。これは他のものと違い、より現代的な印刷システムであり、 この新しいシステムで印刷することに関する以前の知識を適用しないことが最も良い。 むしろ、最初からCUPSを理解することをすべきである。この文書はCUPSの完全な理解 を手助けする。まず基本的な点から最初に始めよう。

CUPSは印刷スプールシステムというもの以上である。これは、新しいインターネット印刷 プロトコル(IPP)に従う完全な印刷管理システムである。IPPは産業製品であり、 ネットワーク印刷に関するInternet Engineering Task Force (IETF)標準である。 この機能の多くはWebブラウザー(CUPS印刷サーバーにアクセスするプラットフォーム非依存の アクセスを提供する)経由でリモート(またはローカル)から管理することが出来る。さらに 追加で、伝統的なコマンド行といくつかのより新しいGUIインタフェースを持っている (GUIインタフェースはサードパーティによって開発され、たとえば、KDEのoverwhelming KDEPrintなどである)。

CUPSは、smartプリンター(すなわち、CUPSがプリンターに対して要求 された時にファイル形式の変換を行う)と同じように、rawプリンター すなわち、印刷ファイル形式を変換しない)の作成が出来る。多くの手段で、Microsoft Windows 印刷関しシステム同じような機能がCUPSにはある。もちろん、CUPSの推進者ならば、 CUPSの方がもっと良いと言うだろう!多くの場合、Samba経由でMicrosoft Windows印刷 クライアントとの間でCUPSがインタフェースを取るための設定方法を説明しよう。

SambaはCUPSと特別な関係がある。SambaはCUPSライブラリサポート機能を有効にして コンパイルできる。最も最新のバージョンでは、このサポートを有効にしている。 既定値では、CUPSはsmbdとその他のSambaバイナリにリンクされる。もちろん、 libcups.soをSambaにリンクしなくてもCUPSを使う事が できるが、要求されるあるいはサポートされる設定にいくつかの違いがある。

Sambaがlibcupsとリンクされ、コンパイルされた時、 printcap = cupsは、プリンター一覧の表示、 ジョブの投稿、キューの問い合わせなどにCUPS APIを使う。それ以外は、印刷のために、 これらの操作を、-orawオプションを付加して、System Vの コマンドにマップする。Linuxシステムでは、smbdが、libcupsライブラリにリンク されているかを、lddユーティリティを使う事で知ることが出来る (lddは他のOSプラットフォーム上には無いかもしれないか、 その機能は別のコマンドによって行われるかもしれない):

root# ldd `which smbd`
libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000)
libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
[....]

libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000) 行は、このバージョンのSambaがCUPSサポートするようにコンパイルされていることを 示している。もしもこの場合で、printing = cupsが設定されている場合、 他のsmb.conf中にある、手動で設定した印刷関係のコマンドは無視される。 これは重要な点なので覚えておくこと!

最も簡単な印刷関連のsmb.confファイル に、基本的なCUPSサポートを有効にする、最も簡単な印刷関連のsmb.conf設定を 要約する:

これはCUPSに対する基本的な印刷設定に必要なもののすべてである。Windowsクライアント から投稿されたすべてのグラフィック、PDFとPostscriptファイルは印刷できる。 しかし、ほとんどのWindowsユーザーは、GUIアプリケーションを開かないで、印刷する ファイルの種類を送る方法を知らない。Windowsクライアントはインストールされた ローカルのプリンタードライバーを持つ傾向があり、GUIアプリケーションの印刷ボタンは、 プリンタードライバーを開始する。ユーザーは滅多にコマンド行からファイルを送らない。 UNIXクライアントとは違い、グラフィック、テキストあるいはPDFファイルを直接 スプーラに送らない。通常、アプリケーションのネイティブな形式と印刷データ ストリームの間でホックされた“printer driver”を使うGUI アプリケーションから排他的に印刷を行う。もしもバックエンドプリンターが Postscriptデバイスでない場合、印刷データストリームは“バイナリ”で、 対象のプリンターのみが対象である。この問題が引き起こすこととそれを防ぐことを 学ぶために、この先を読み続けること。

1台のプリンター用にグローバルなCUPS設定を上書きする例 は、smb.conf用の、やや複雑な印刷関連設定である。これはすべてのプリンターに対して 一般的なCUPS印刷サポートを有効にするが、1台だけ設定が異なるプリンター共有を定義する。

この特別な共有は、テスト目的専用である。これは印刷ジョブをファイルに書かない。 これは、ジョブパラメーターをSambaが認識する/tmp/smbprn.log ファイルに記録し、ジョブファイルを削除する。さらに、この共有の printer adminは“kurt”で (“@ntadmins”グループではなくて)、ゲストアクセスは許可されず、共有は ネットワークコンピューターに公開されず(そのため、これが共有であることを知っておく 必要がある)、3つのホストのみからアクセスできる。その共有に対して、CUPSが起動し、 印刷ジョブ上で通信をすることを防ぐために、 printing = sysvと printcap = lpstatを設定する必要がある。

多くの小規模オフィスや家庭用ネットワークでは、計画がひどい、より大きな環境と 同じように、各クライアントがネットワークプリンターへ直接アクセス出来るように なっている。これは一般的には悪いアイデアである。他のクライアントのジョブが 印刷しているときに、あるクライアントのアクセスを頻繁にブロックしてしまう。 ジョブが終了するのを待っている間、最初のクライアントのアプリケーションは フリーズしてしまうかもしれない。同様に、数多くのジョブが印刷しているとき、 それぞれが異なったページをまぜこぜにしてしまうという苦情もしばしば聞く。 よりよいコンセプトは、プリントサーバーを使うことである。これは、すべてのジョブを 集中したシステムに一本化し、即時に反応し、複数の並列したクライアントから ジョブを受け取り、正しい順序でプリンターに転送する。

ほとんどの現代的に設定されたUNIX印刷サーバーは、本当に単純なセットアップを意味する、 SambaのWindowsクライアントのために振る舞う。それらの唯一の業務は、Sambaによって すべてのジョブが扱われる“直接”スプーリングを管理することである。 この試みは、Windowsクライアントが、印刷デバイスに送られる準備が出来た印刷ジョブ ファイルを準備することが期待されるということである。この場合、ネイティブな (ベンダが供給した)Windowsプリンタードライバーは、各、およびすべてのクライアントで、 対象デバイスのものをインストールする必要がある。

同様に現代的な、簡単な方法で、CUPS、SambaとWindowsクライアントを設定することは 可能である。CUPSプリンターが直接印刷モード状態で設定されているならば、完全に 印刷ジョブ(ファイル)を描画することは、Sambaクライアントの責任である。ファイルは プリンターに直接配信するのに適した形式で送られる必要がある。クライアントはこれを 行うために、ベンダが提供したドライバーを動作させる必要がある。この場合、CUPSは 何ら印刷ファイル形式変換を行わない。

可能な、最も簡単な印刷設定は、直接印刷(raw print-through)である。これは、 Windowsクライアントに物理的に結合されているようにプリンターをインストールする 事によって行える。次に、それをrawネットワーク印刷キューにリダイレクトする。 この手続きは、以下の手順によって行えるだろう:

Windowsクライアント上のプリンタードライバーは2つの機能的に異なった方法でインストール できる:

二番目の方法は、管理コストの削減と、偶然異なったバージョンのドライバーが使われる ことを防ぐのに、最初のものを使うよりも推奨される。

もしも最初のオプション(ドライバーはクライアントサイド上でインストールされる)を使う 場合、注意すべき設定が1つある:CUPSに対して、手の込んだ(バイナリ)ファイル形式 である“raw”印刷を許可するように設定する。rawモード印刷を動かす ための、正しい設定する必要があるCUPSファイルは以下の通り:

両者はRAMモード操作を許可するためにコメントアウトしなければならないエントリ (それぞれのファイルの最後の部分)を含む。/etc/cups/mime.types 中では下記の行が存在するようにする:

application/octet-stream

/etc/cups/mime.convsでは、この行が存在するようにする:

application/octet-stream   application/vnd.cups-raw   0   - 

もしも、2つのファイルが、Windowsクライアントからの印刷に対して正しく設定されて いない場合、恐ろしいUnable to convert file 0 というメッセージが、が、CUPSのerror_logファイル中に現れる だろう。

背景.  CUPSは、伝統的な印刷システムが既定値では印刷デバイスに手の込んだ(おそらく バイナリ)のデータを、ユーザーに送ることを認めていないと比べて、より セキュリティに気づいている印刷システムである。これは、プリンターに対して、 少なくとも大量の紙とインクを無駄にすることとなる、 “サービス不能”攻撃を引き起こす不正な使い方を簡単に行える。 “不明な”データはCUPSによって、 MIME type: application/octet-streamとタグ付けられ、 プリンターに送ることを許可されない。既定値では、他の(既知の)MIMEタイプである “raw”のみを送ることが出来る。“raw”を送ることは、 CUPSがそれらを変換せず、何もさわらないでプリンターに渡すことを意味する。

これが、ベンダドライバーをローカルにインストールしたWindowsクライアントによって 準備された“raw”ファイルをCUPS/Sambaの協調印刷で行うときに知っておく 必要があることのすべてである。もしもより詳細なCUPS/Samba印刷についての背景 情報について興味がないならば、この章の残りの部分を読み飛ばせばよいだろう。

この節では、プリンタードライバーをアップロードする、3つのなじみやすい方法に、 さらに新しいもの1つについて説明する。

もしも、MS-RPCタイプの印刷を使いたいならば、最初にSambaサーバー上に ([print$]共有)ドライバーをアップロードしなければならない。 Sambaホスト上からプリンタードライバーを配信する方法(結果、Windowsクライアントは “ポイントアンドプリント”経由でダウンロードしそれを利用できる) についての議論は、この資料の 旧式の印刷 の章を参照のこと。 以下は、Sambaサーバー上にクライアントドライバーを準備するための3つの方法への 説明又は参照である:

これらの3つの方法は、CUPSに対して同じように適用される。 cupsaddsmbユーティリティは最新で、CUPSを使っている場合、 WindowsドライバーをSamba中に起き、提供するより便利な方法である。

cupsaddsmbは、この章の後の方でより詳細に説明される。しかし、 まず初めにCUPSフィルタリングシステムを説明し、WindowsとUNIXの印刷アーキテクチャの 違いを比較する。

ネットワーク印刷は最も複雑でエラーが発生しがちであり、ユーザーや管理者が 遭遇しがちである日々の作業の1つである。これはすべてのOSプラットフォーム上で 真実であり、そうなる理由がある。

プリンターに任意のファイルフォーマットを送り込み、それが印刷されることを期待する ことはできない。ファイルフォーマット変換を行う必要がある。問題は、すべての メーカとプリンタータイプに共通の、共通標準印刷ファイルフォーマットがないという ことである。Postscript(Adobeの商標)とその拡張であるPCL(HPの商標)はページ記述言語 (PDL)として使われていることにより、ほぼ公式な“標準”として開発されて いる。しかし、多くのメーカは引き続き“固有のものを使っている” (それらの理由は、プリンター内蔵のPostscriptインタプリタの、受け入れられないような ライセンス費用などである)。

WindowsOSでは、フォーマット変換ジョブはプリンタードライバーによって行われる。 Microsoft Windows OSプラットフォーム上ではすべてのアプリケーションプログラマは、 それらの基盤となるOSそれ自身の一部分、あるいは一区画として、自由に使える 組み込みのAPI、グラフィカルデバイスインタフェース(GDI)を使える。このGDIコアは 絵、フォントと文書を画面上に描画するのと同様に 紙の上に(印刷)する、すべてのWindowsプログラムにある1つの 共通基盤として使える。そのため、プリンタードライバー開発者はよく定義されたGDI出力を 固有のドライバー入力として標準化できる。WYSIWYG(What You See Is What You Get)の 実現は、スクリーン上のグラフィックプリミティブが紙上の描画オブジェクトと同じ ようで、同じソースから来るために、相対的に容易である。このソース、すなわちGDIは、 しばしば拡張メタファイル(EMF)と呼ばれるファイルフォーマットを生成する。EMFは プリンタードライバーによって処理され、プリンター固有のファイルフォーマットに変換される。

ローカルプリンターに対するWindowsの印刷中の例は、 ローカルWindows印刷を図示している。

Figure 22.1. ローカルプリンターに対するWindowsの印刷

UNIXとLinuxでは、OSカーネルかX(画面表示)サーバー中に、構築された、類似のレイヤは ない。すべてのアプリケーションはそれ自身でその印刷出力を作成することに責任が ある。幸い、大部分がPostscriptを使い、それを何らかの共通基盤としている。 また、悪いことに、同じ文書を画面上に表示することとどのようにそれを紙に 印刷するかを行う、非常にたくさんの(そして何ら共通項がない)方法がある。 これは、数10年前にさかのぼってみると、グラフィカルユーザーインタフェースのための UNIX 基盤とプロトコルを設計したX.orgの前身は、幾人かがその時点で要求したように、 “紙出力”についての責任を取るのを拒否し、それ自身を “画面表示のみ”に制限した(何年か後、“Xprint” プロジェクトが開発中で、Xのフレームワーク中に、PostscriptとPCLドライバーを含む 印刷サポートを構築することを試みたが、まだ完成していない)。この、余り好ましくない 遺産は、使用しているシステムの、種々の“font”ディレクトリ中で、今も 見ることができる。X表示用と印刷用に使うフォントが分かれている。

背景.  Postscriptプログラミング言語はAdobeの“開発物”であるが、その仕様は 広範囲に公開されている。その能力は、その強力なグラフィカルオブジェクト (フォント、シェープ、パターン、行、曲線、と点)を記述する能力、その属性 (色、線の幅)とそれらを操作する(拡大縮小、変形、回転、移動)ことによっている。 その公開された仕様により、能力がある誰でも、固有のPostscriptインタプリタ実装を 作成でき、画面あるいは紙状にPostscriptファイルを表示するのに使える。 ほとんどのグラフィック出力デバイスは “ラスタイメージ”か “ピクセル”(ペンプロッタは特筆すべき例外)というコンセプトを基盤と している。もちろん、テキスト形式でPostscriptファイルを見ることもでき、 ラスタライザによって解釈されるに必要な言語命令であるPostscriptコードを読む ことも出来る。ラスタライザは、ビューワプログラムによって画面上で表示されるか、 プリンターによって印刷されるかする、ピクセルイメージを生成する。

UNIXは紙への印刷と画面上への表示についての共通基盤が欠けている。UNIXの、好ましく ない遺産にもかかわらず、自由に使えるPostscriptプリンターを持っている場合、基本的な 印刷はかなり簡単である。その理由は、それらのデバイスは、ラスタイメージプロセッサ (RIP)と呼ばれる内蔵PostScript言語“インタプリタ”を持っているという (それにより、他のタイプのプリンターよりも値段が高い)ことである。それに向けて PostScriptを送り込むと、印刷したページを出力する。RIPは紙の上で見る事ができる、 ビットマップの絵にPostScript描画コマンドを変換するすべての大変な仕事をこなし、 プリンターによってそれを処理してしまう。これは、Windows上からPostScript印刷を 行うのと何ら違いはない。

Figure 22.2. PostScript Printerによる印刷

しかしながら、それ以外のタイプのプリンターもある。それらはどのようにPostscriptを 印刷するかが分からない。それらは、しばしばメーカ固有のPDLを使う。それらに対して 印刷を行う事の注文はもっと多い。利用しているUNIXアプリケーションはほとんどの 場合、Postscriptを生成し、それらのデバイスはPostscriptを理解しないので、 それに対してデータを送る前に、ホスト上で使用しているプリンターに合わせた印刷 ファイルのフォーマット変換を行う必要がある。

ここからGhostscriptの説明を始める。Ghostscriptは、UNIXプラットフォームで 使われている、伝統的な(そしてとても強力な)Postscriptインタプリタである。 これはソフトウェアによるRIPであり、ソフトウェアファイルフォーマットと同様、 非常に広範囲のハードウェアデバイスへの、たくさんのファイル変換を行う能力がある。 Ghostscript技術とドライバーは非PostscriptハードウェアでPostscript印刷を実行 できるようにするものである。これについては 非Postscriptプリンターに対するRIPとしてのGhostscript に説明がある。

Figure 22.3. 非Postscriptプリンターに対するRIPとしてのGhostscript

Postscriptの本質がデバイス非依存の方式でページレイアウトを表現するための PDLである間は、実世界での印刷上部は常時デバイス固有の機能を持ったハードウェア 上で最終的に出力される。ハードウェアの違いに気を遣うことと、機能改善を図るため、 Adobeは文法とPostscriptプリンター定義(PPD)ファイルのファイルフォーマットを定義 してきた。すべてのPostscriptプリンターはそれらのファイルの1つを同梱して出荷されて いる。

PPDは、そのプリンターに割り当てられた一般的および特別な機能についてのすべての情報を 含んでいる。扱える異なった解像度は何か?両面印刷ユニットがあるか?ペーパートレイは いくつあるか?メディアのタイプとサイズは何が使えるか?それぞれの要素について、 プリンターに送られる特別なコマンド文字列を、それを有効にするために指定する事が 出来る(ほとんどの場合、Postscriptファイル中に)。

PPDからの情報はプリンタードライバーによって考慮されることを意味する。そのため、 与えられたプリンターのための、Windows PostScriptドライバーの一部としてインストール されるものはプリンターのPPDである。それが意味をなす場合、PPD機能は、印刷 オプションをユーザーに選択されるために表示される、ドライバーのユーザーインタフェース ダイアログ中で提供される。最後に、ユーザーの選択は、ドライバーによって作成された PostScriptファイル中に(特別なPostScript、PJL、JCLあるいはベンダ固有のコマンド 形式として)何らかの形で書かれる。

CUPSはそのPostScriptモデルのための、開発元によって供給された、すべての仕様に 従っているPPDを扱うことが出来る。もしもベンダがマニュアルとパンフレットに 使用しているOSについての言及がなかったとしても、それらを安全に信用できる: もしも、Windows NTバージョンのPPDを入手したならば、CUPS中で変更なしに利用でき、 その結果、Windows NTユーザーが出来るように使用するプリンターのすべての能力に アクセスできる。

CUPSは非PostScriptプリンターを扱うために、特別に作成されたPPDをも使う。それらの PPDは通常ベンダから供給されない(そして、同じモデル名のPostScriptプリンター用の PPDファイルを使うことが出来ず、非PostScriptバージョンが動くことを期待することも 同じである)。非PostScriptプリンターに対してPPDがどのように適用されるかを知るため には、最初にCUPSフィルタリングとファイルフォーマット変換アーキテクチャについて 深く言及する必要がある。引き続き読み続けること。

CUPSは/etc/cups/mime.types(と、同じディレクトリ中にある、 すべての*.typesファイル)を起動時に読み込む。これらの ファイルはCUPSがそのautotyping機能を動かしているときに適用されるMIMEタイプ 認識ルールを含む。ルールの文法はmime.typesのマニュアル ページとmime.typesファイルそれ自身のコメントセクションに 記述されている。簡単なルールは以下の通りである:

application/pdf         pdf string(0,%PDF)

これは、もしファイル名に.pdfという拡張子が付いているか、 あるいは、マジック文字列%PDFがファイルそれ自身の先頭の 正しいところ(開始時点からオフセット0)にある場合、それはPDFファイルである (application/pdf)。その他のルールは以下の通り:

application/postscript  ai eps ps string(0,%!) string(0,<04>%!)

もしも、ファイル名が.ai, .eps, .psという拡張子のどれかを持つか、ファイルそれ自身が %!か<04>%!という文字列の どれかで始まるならば、それは一般的なPostScriptファイルである (application/postscript)。

CUPSはASCIIテキスト,HP-GL, PDF, PostScript, DVIと多くの画像イメージ形式 (GIF, PNG, TIFF, JPEG, Photo-CD, SUN-Raster,PNM, PBM, SGI-RGBやその他)と それらに関連したMIMEタイプとそのフィルターを扱うことが出来る。

CUPSは/etc/cups/mime.convs(と、同じディレクトリ中にある、 その他の*.convsというファイルも)を起動時に読み込む。 それらのファイルには入力MIMEタイプ、出力MIMEタイプ、入力タイプから出力を生成 できるフォーマット変換フィルターとその変換に関連する仮想のコストを意味する行を 含む。その1つの例は以下のようになる:

application/pdf         application/postscript   33   pdftops

これは、pdftopsフィルターが入力として application/pdfを取り、出力として application/postscriptを生成する。この操作の仮想コストは 33 CUPS-$である。次のフィルターはより高価で、66 CUPS-$かかる:

application/vnd.hp-HPGL application/postscript   66   hpgltops

これは、HP-GLプロッタファイルをPostScriptへ変換処理する hpgltopsである。

application/octet-stream

さらに2つの例である:

application/x-shell     application/postscript   33    texttops
text/plain              application/postscript   33    texttops

最後の2つの例はapplication/x-shell上と同じように text/plainで動作するtexttops フィルターを意味する(ヒント:この違いは、texttopsの 特筆すべき機能の文法のために必要とされる)。

mime.convsという名前の、よりたくさんの組み合わせがある。 しかし、あらかじめ定義してあるもの以外を使うことに制限はない。好みの、CUPS フレームワークに対する任意のフィルターを追加できる。それは最小限の要求に適合 するか、させねばならない。もしも、ある種の効果的なフィルターを見つける(か書くか) 場合、CUPSの要求が要求するものに従い、適切な行をmime.typesと mime.convsに書く。そうするとCUPS内部でシームレスに動作する。

以前に説明したように、PostScriptは、任意のUNIXベースの印刷システムにおいて 中核となるファイル形式である。PostScriptから、非PostScriptプリンターに送る ためのラスタデータを、CUPSは生成する。

しかし、印刷するためにサポートされた非PSフォーマットのどれかを送る時に何が起きる のだろうか?次にCUPSはPostScriptを最初に生成するために、それらの入力上で “prefilters”を動かす。これは、ASCIIテキスト,PDF, DVI,かHP-GLから PostScriptを生成するためのprefilterである。それらのフィルターからの出力は常時 application/postscriptというMIMEタイプである (これは任意のデバイス固有のオプションはCUPSによってまだPostScriptに埋め込まれて おらず、呼ばれる次のフィルターはpstopsであることを意味する)。その出力は常時 application/vnd.cups-postscriptというMIMEタイプである (application/postscriptではない)場合、プリントオプションはすでにファイルに 埋め込まれている事を意味する。これは、 PostScriptを整形するためのCUPS内のprefiltering で説明されている。

Figure 22.4. PostScriptを整形するためのCUPS内のprefiltering

pstopsは、application/postscriptを application/vnd.cups-postscriptに変換するために使われる フィルターである。以前に説明したように、このフィルターはすべてのデバイス固有の印刷 オプション(両面印刷やstanpingと穴あけなどをプリンターに指示するコマンド)を、 PostScriptファイル中に挿入する。その例は、 デバイス固有印刷オプションの追加に例示されている。

Figure 22.5. デバイス固有印刷オプションの追加

これがすべてではない。これにより行われるその他の処理は以下の通り:

pstorasterはCUPSフィルタリングシステムの中核である。 これは、ラスタライズ処理の最初のステージに対して責任がある。その入力は application/vnd.cups-postscriptというMIMEタイプである。その出力は、 application/vnd.cups-rasterである。この出力形式はまだ印刷可能にはなっていない。 その目的は、デバイス固有印刷データの生成を有効にする、より特殊化した ラスタデバイスのための汎用入力形式として提供することである。 これについては、 PostScriptから中間ラスタ形式への変換ダイアグラム を参照のこと。

Figure 22.6. PostScriptから中間ラスタ形式への変換ダイアグラム

CUPSラスタは強力な機能を持つ汎用ラスタフォーマットである。これは、ページ単位 情報、色のプロファイルなど、下位のラスタドライバーで使われるものを含むことが 出来る。そのMIMEタイプはIANAに登録されていてその仕様はもちろん完全に公開されて いる。それを作るのはとても簡単で、選択したものに対応すべきプリンターモデル用に、 LinuxとUNIXラスタドライバーを製造元が作成するために、費用がかからないように 設計されている。CUPSは常時ラスタライズする最初のステージに注意を払っているので、 ベンダはGhostscript互換について注意を払う必要はない(実際、CUPSラスタドライバーの 開発の資金調達を行っている、1つ以上のベンダが現在存在する)。これは、 Ghostscriptを使うCUPSラスタ生成の図解 に図示している。

Figure 22.7. Ghostscriptを使うCUPSラスタ生成の図解

バージョン1.1.15より前のCUPSバージョンでは、バイナリ(あるいはソースコードで)、 pstorasterという名前の独立フィルターを提供していた。 pstorasterはGNU Ghostscript 5.50由来で、代替インストール 可能で、競合なしにGNUあるいはAFPL Ghostscriptパッケージに追加される。

バージョン1.1.15以降、この機能は変更された。このフィルターの機能は、Ghostscriptに 統合された(現在はGNU Ghostscript バージョン 7.05をベースとしている)。 pstorasterフィルターは現在-sDEVICE=cups パラメーターを付けたgsを呼び出す単純なシェルスクリプトである。 もしも、gs -h |grep cupsを実行したときにGhostscriptがエラーに なるならば、印刷は出来ないので、Ghostscriptをアップデートする必要がある。

prefiltersについての節において、イメージ形式からPostScriptを生成するprefilter について言及した。imagetorasterフィルターは中間PostScript ステージなしにイメージからラスタに直接変換するために使われる。これは以前に 言及したprefilterよりもより頻繁に使われる。イメージファイルのフィルタリングに ついての要約フローチャートは イメージ形式をCUPSラスタ形式に変換する流れである。

Figure 22.8. イメージ形式をCUPSラスタ形式に変換する流れ

CUPSはCUPSラスタを処理するための非常に数多くのラスタドライバーを提供している。 筆者の環境では、/usr/lib/cups/filter/配下に rastertoalps,rastertobj, rastertoepson,rastertoescp, rastertopcl,rastertoturboprint, rastertoapdk,rastertodymo, rastertoescp, rastertohpと rastertoprinterがあった。これよりドライバーの数が少なくても 心配することはない。上記のいくつかはCUPSに対する商用アドオンであり (rastertoturboprintのような)、その他 (rastertoprinterのような)は、可能な限りCUPSと協調する ことを望んでいるサードパーティドライバー開発プロジェクトに由来する (たとえばGutenprint)。 ラスタからプリンター固有形式への変換図 を参照。

Figure 22.9. ラスタからプリンター固有形式への変換図

CUPSフィルタリングチェーンについての最後の部分はバックエンドである。 バックエンドは、最終的なデバイスに印刷可能なファイルを送るための、特別な プログラムである。ネットワーク経由でと、すべてのローカルなインタフェースに 印刷ジョブを送るための、任意の異なった分離されたバックエンドプログラムが ある。すべてのCUPS印刷キューは、それに関連づけられているCUPS “device-URI”を持つ必要がある。device URIは、その送付先にジョブを 送るときに使われる、バックエンドをエンコードする方法である。以下で一覧表示 されているもので分かるように、ネットワークdevice URLは記述の中に2つの スラッシュ(斜線)を使い、ローカルdevice URLは1つのみを使う。ローカル インタフェース名は、OSがLinux以外の場合、筆者の例では非常に自由度があっても よいことを心にとめておくこと:

CUPS印刷システムに対して任意の変更又は拡張の必要性がある場合、シェル又はPerl スクリプトで固有のバックエンドを書くことは簡単である。印刷ジョブをメールとして (“mailto:/”バックエンド経由で)送る、PDFに変換する (“pdfgen:/”バックエンド経由で)、あるいは“/dev/null”に ダンプするというような“特別な”プリンターを作成したいというような 希望が理由としてあげられる(実際、システム全体での既定値のプリンターとして、 devnull:/バックエンドに接続するプリンターを用意している)。とても多くの人が、 プリンターを指定しないでジョブを送信したり、スクリプトとプログラムがプリンターを 指定しない。システム全体での既定値はジョブを削除し、$USERに、 正しいプリンター名を常時指定するようにという丁寧なメールを送る)。

説明したバックエンドすべて以外が使用しているシステム上にあるか、利用可能に (ハードウェア設定に依存する)なっていてもよい。すべての有効なCUPSバックエンドを 調べる1つの方法はlpinfoとして提供されている。これを -vを付けて付こうと、すべての有効なバックエンドを下記のように 表示する:

	$ lpinfo -v
	

cupsomaticフィルターはCUPSをインストールするときに最も広く 使われているだろう。これらはCUPS開発者によって開発されたものではないということを 明確にする必要がある。これらはCUPSに対するサードパーティアドオンである。これらは CUPSのためにジョブをレンダリングする従来のGhostscriptデバイスを使う。 問題が発生したときの調査時にはその違いを知っておく必要がある。ここでは1ステージで すべてのレンダリングプロセスがGhostscript内部で、対象のプリンターに適したデバイスを 使って行われる。cupsomaticは、Linuxprinting.orgにある Foomaticプリンタードライバーデータベースから生成されたPPDを使う。

You can recognize these PPDs from the line calling the cupsomatic filter:

*cupsFilter: "application/vnd.cups-postscript  0  cupsomatic"

PPDファイルの最初の40かそのあたりで、この行を見つけるかもしれない。 もしも、そのような、インストールされたPPDがあるならば、プリンターは foomaticの名前部分にfoomaticが 表示されたCUPS Webインタフェース中で表示される。 cupsomaticは、選択されたPPDとプリントジョブに与えられた コマンドラインオプションから自動的に構成された、すべての複雑なコマンドライン オプションを付けたGhostscriptを実行させるPerlスクリプトである。

しかし、cupsomaticは現在廃止されている。そのPPD(特に 最初に生成したものは、そこで引き続き頻繁に使用される)は、Adobeの仕様に適合して いない。Windowsクライアントに“ポイントアンドプリント”でそれらを ダウンロード仕様とするときに困難に遭遇するかもしれない。よりよい、かつ 強力な解決方法は現在提供されている。それは、foomatic-rip と呼ばれる。CUPSでフィルターとしてfoomatic-ripを使うために、 似たようだが異なった行を持つ、新しいタイプのPPDが必要である:

*cupsFilter: "application/vnd.cups-postscript  0  foomatic-rip"

Linuxprinting.orgにあるPPD生成エンジンは修正された。新しいPPDはAdobeの仕様に 従っている。これらは異なった品質レベル(高解像度の写真、通常の色、グレースケールと ドラフトモード)をシングルクリックで、5つまたはそれ以上の異なった選択(メディア タイプ、解像度、インク種別とディザリングアルゴリズム)を要求できる新しい方法を 提供する。ビルトインされた固有のサイズのメディアサポートもある。ジョブの中間で、 ページ毎に印刷オプションを切り替えることのサポートもある。さらに、最もすばらしい ことは、新しいfoomatic-ripは、印刷時にPPDを使うための アクセスに対するサポートを、すべての旧式なスプーラ(LPRng,BSD-LPD, PDQ, PPRなど) に対してもシームレスに動作するということである。

すべてのフィルターの概要とどのようにそれらが関連するかを知りたい場合、 パズルの完全な図解はこの章の最後にある。

CUPSは与えられたMIMEタイプとインストールされたすべてのプリンターに対する可能な すべてのフィルタリングチェーンパスを自動構築する。しかし、どのようにして 優先するものや特定の選択肢を決めるのであろうか(2つ以上の、同じターゲット プリンターに対するフィルタリングチェーンが存在するような場合があるだろう)? 簡単である。mime-convファイルの3番目のカラム中にある数字に気がついたかも しれない。それはこのフィルターに割り当てられている仮想コストを表現している。 すべての可能なフィルタリングチェーンは全体の“フィルターコスト” として集計される。CUPSは最も“コストの小さい”ルートを選ぶ。

CUPSに対して任意の“raw”ファイルを印刷(ほとんど)させることが出来る。 “raw”はフィルターされないことを意味する。CUPSは、プリンターがそれを理解 できる時に、思い悩まずに“そのまま”プリンターに対してファイルを送る。 ユーザーは賢明なデータ形式のみをそれらに送る事について注意を払う必要がある。raw 形式の印刷は、もしも“-o raw”オプションが コマンド行上で指定されたときにどのキューにおいても発生する。任意のPPDを単に関連 づけない事によってrawのみのキューを設定することも出来る。以下のように行う:

$ lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E

これは、“rawprinter”という“socket”プロトコル (別名“HP JetDirect”)経由で接続してポート9100のIPアドレス 11.12.1.3.14のデバイスに接続するように設定する(もしもこのコマンド行に -P /path/to/PPDを付けたPPDを追加したならば、 “通常の”印刷キューとしてインストールされる。

CUPSは、もしもキューに関連づけられるPPDを見いだせない場合、自動的に各ジョブを “raw”と見なしてキューに送るように扱う。しかし、CUPSは既知の MIMEタイプ(CUPSが持つmime.typesファイルで定義されている)のみを送り、それ以外は 拒否する。

/etc/cups/mime.typesファイル中にルールがない任意のMIME タイプは、unknownかapplication/octet-streamと 見なされ、送信されない。既定値で不明なMIMEタイプの印刷をCUPSが拒否するので、 Windowsクライアント由来の印刷ジョブが印刷されないということを経験するかも しれない。以下のようなエラーメッセージがCUPSログファイル中に見つかるかもしれない:

Unable to convert file 0 to printable format for job

application/octet-streamの印刷を有効にするためには、以下の 2つのファイルを編集する:

両方ともapplication/octet-streamのためのrawモード操作を 有効にするためにコメントアウトしなければならないエントリ(それぞれのファイルの 最後の所)を含む。下記の行が/etc/cups/mime.typesに存在する ようにすること:

application/octet-stream

自動タイプルールセットが指定されていないこの行は、他の行で application/octet-streamのメンバーが自動タイプされていない 限り、全てのファイルを作成する。/etc/cups/mime.convs中では 以下のような行になる:

application/octet-stream   application/vnd.cups-raw   0   -

この行はCUPSに、application/octet-stream上で (“-”で示される、何もしない)Null Filter を使うことを指示し、application/vnd.cups-rawとして 結果をタグづける。この最後の部分は、プリンターに接続しファイルを送信するための バックエンドに向けてCUPSスケジューラがいつでも今あるファイルを引き渡せるように している。

Background.  そのCUPSは従来のものよりセキュリティに気を払っている印刷システムで、既定値では、 印刷デバイスに対して手の込んだ(おそらくバイナリ)データを送ることを誰にも許可して いない(これは、使用しているプリンターに対してサービス不能攻撃をかける不正使用が 簡単にでき、少なくとも大量の紙とインクが無駄になることが発生する)。 “不明な”データはCUPSによって、MIMEタイプ application/octet-streamと見なされる。 “raw”形式でデータを送ることができる場合、 それらのMIMEタイプは、CUPSとそれによって許可された、既知のもののどれかでなければ ならない。/etc/cups/mime.typesというファイルはCUPSが どのようにMIMEタイプを認識するかの“規則”を定義する。 /etc/cups/mime.convsというファイルはどのファイル変換 フィルターがそのMIMEタイプに適用されるかを定義する。

オリジナルのPPDはPostScriptプリンターのみに使われることを意図していた。それらは ジョブファイルを処理する、RIPのためのデバイス固有のコマンドと設定を送るための 手助けとなる。CUPSはPPDに対するこのスコープを拡張し、非PostScriptプリンターにも カバーするようにした。これが標準化されたファイル形式のために、これを行うのは 難しくない。その方法は論理的でもある:CUPSはPostScriptを取り扱い、ジョブファイルを 処理するためにPostScript RIP(Ghostscript)を使う。唯一の違いはPostScriptプリンターは RIPを内蔵していて、その他のタイプのプリンターはホストコンピューター上でGhostscript のRIPを動かすと言うことである。

非PostScriptプリンターに対するPPDはCUPS固有のいくつかの行を持っている。最も 重要なものは下記と似たようなものである:

*cupsFilter: application/vnd.cups-raster  66   rastertoprinter

これが CUPS フィルタリングの最後の難所のひとつである。この行では、CUPSデーモンに 対して、rastertoprinterを最後のフィルターとして使うように 設定している。このフィルターは application/vnd.cups-raster というMIMEタイプのファイルが入力の際に用いられることになる。CUPSは指定されたMIME タイプを最終的な出力とするようなフィルターのチェインを自動的に生成する。 次にこれは指定されたrastertoprinterフィルターのための入力と なる。最後のフィルターが処理を終えた後(rastertoprinterは Gutenprintフィルターである)、ファイルは、出力デバイスに送信を行うバックエンドに 送られる。

CUPSが提供しているPPDは数少ないが、プリンターモデルは数多くある。異なった紙の トレイや指定されたモデルがサポートしているよりもより大きなマージンを取ることが 出来ないかもしれない。要約は表21.1“CUPSに同梱されているPPD”を参照。

ネイティブなCUPSラスタライズ作業は2つのステップに分かれている:

しばしばこれは、その他の方法よりもより良い品質のものを生成する(そして、 いくつかのより優位な点がある)。これについては cupsomatic/foomaticの処理対ネイティブなCUPSの図 に図解がある。

Figure 22.10. cupsomatic/foomaticの処理対ネイティブなCUPSの図

1つの他の方法は、cupsomatic/foomatic-ripによるものである。 cupsomaticは、決してCUPS開発者によって 作られたものではないということに注意。これは、印刷環境に 対する独立した貢献であり、Linuxprinting.orgの人々によって作られたものである。 [6] cupsomaticはもはや開発、メンテナンス、サポートされいない。 これは現在 foomatic-ripによって置き換えられている。 foomatic-ripは古いcupsomaticの アイデアを完全に書き換えたものであるが、とても改善され、他の(非CUPS)スプーラに 対して汎用化されている。 foomatic-ripへのアップグレードは、 特にもしも最新バージョンのCUPSにアップグレードするならば強く推奨される。

古いcupsomaticのように、(新しい)Linuxprinting.orgが使う 現代的なGhostscript印刷処理からのfoomatic-ripは、すべてを 単一のステップで行う。従ってそれはGhostscript中に組み込まれる他のすべての デバイスに依存する。他のスプーラでのGhostscriptのレンダリングと同じくらい 品質は良い(あるいは悪い)。優位点は、この方法は、より最新のCUPSによる方法によって (まだ)サポートされていない、たくさんのプリンターモデルをサポートするということで ある。

もちろん、あるシステムで並列に両方の手法を使うことが出来(もしも異なったキューを 設定するならば1つのプリンターに対しても)、どれが一番うまく動作するかを見いだせる。

cupsomaticは印刷ファイルを application/vnd.cups-postscriptステージ後に捕まえ、 システム全体でインストールされたGhostscriptである、CUPS-externalを通してそれを 横取りする。その結果、印刷ファイルはpstorasterフィルター をバイパスする(さらにCUPSラスタドライバーrastertosomethingも バイパスする)。Gostscriptがラスタライズ処理を終えた後、 cupsomaticはレンダリングされたファイルディレクトリをCUPS バックエンドに渡す。 cupsomatic/foomaticの処理対ネイティブなCUPS にはネイティブなCUPSレンダリングとFoomatic/cupsomatic手法の 違いについて図解している。

以下は、CUPSの動作を図解するための、よくあるフィルタリングチェインの例である。

HP JetDirect接続のPostScriptプリンターにPDFファイルを印刷しようとしていることを 仮定するが、ページ3-5,7と11-13のみを印刷したく、更にそれを“2アップ” と“両面印刷”にしたいとする:

フィルタリングチェーンの結果は以下の PDFからソケットへのチェーンの模式図のようになる。

Figure 22.11. PDFからソケットへのチェーン

CUPSstphoto2.ppdをインストールした、USB接続の Epson Stylus Photo Printerに同じフィルターで印刷したいと仮定しよう。最初の いくつかのフィルタリングステージはおおよそ同じである:

フィルタリングチェーンの結果は PDFからUSBチェーンへの模式図のようになる。

Figure 22.12. PDFからUSBチェーン

インターネット上でたくさんのCUPS-PPDファイルを(それに適したフィルターと一緒に)、 たくさんの言語環境で、1000以上の非PostScriptモデル用をサポートしているものを 見つけることが出来る。

CUPSはまたSystemV AT&T印刷システムからとして知られている “interface scripts”の使用もサポートしている。それらはしばしば PCL印刷ジョブを生成するアプリケーションから、PCLプリンターにおいて使われる。 interface scriptsはプリンターモデルに特化している。これらはPostScriptプリンターの ためのPPDと同様の役割を持っている。interface scriptsは、たとえば、もしも ユーザーが特定のペーパートレイを選択したか、紙の方向を変更したかA3用紙を しようするような場合、印刷データストリーム中に要求されたESCシーケンスを 追加してもよい。interface scriptsはLinux領域ではほとんど知られていない。 HP-UXプラットフォームでは、もう少し使われている。動作する任意の interface scriptsをCUPS上で一緒に使うことも可能である。以下のように、 -iを使ってインストールする:

root# lpadmin -p pclprinter -v socket://11.12.13.14:9100 \
          -i /path/to/interface-script

interface scriptsは多くの人にとって“未知の動物”かもしれない。 しかし、これは、CUPSと共に使うことで、ある特定の印刷キューに対する、固有の、 専用として記述した、フィルタリングスクリプトやプログラムを組み込む最も簡単な 方法を提供する(現代的なinterface scriptsの使い方に関するいくつかの情報は、 http://playground.sun.com/printing/documentation/interface.htmlにある)。

WindowsクライアントからNTベースの印刷サーバーへの印刷は、2つのオプションがある。 それらは以下の2つである:

両方の印刷パスは クライアント上での印刷ドライバーの実行と サーバー上での印刷ドライバーの実行という フローチャートで図示されている。

最初の場合、印刷サーバーはraw形式でファイルをスプールせねばならない。これはジョブファイルに さわらず、何らの方法での変換もしないことを意味する。これは、現代的なUNIXベースの印刷 サーバーが同じように行えることでもあり、NT印刷サーバーよりもよりよいパフォーマンスとより 信頼性がある。これは、おそらくほとんどのSamba管理者が慣れ親しんでいるものである。この 設定の1つの利点は、この“スプールのみ”の印刷サーバーが、UNIX用のドライバーがない 場合にも使えるかもしれないと言うことである。これは、有効なWindowsクライアントドライバーが あり、クライアントにインストールされていれば十分である。これは クライアント上での印刷ドライバーの実行ダイアグラム で図示されている。

Figure 22.13. クライアント上での印刷ドライバーの実行

他のパスはサーバー上でプリンタードライバーを実行する。クライアントはサーバーにEMF形式で印刷 ファイルを送る。サーバーはPostScript, PCL, ESC/Pか他のドライバーを、EMFファイルをプリンター 固有の言語に変換するために使う。同じ事はUNIX上ではできない。現在、プリンターが理解できる ものに、UNIXサーバー上でWindowsクライアントのGDI出力を変換するプログラムか手法はない。 これはサーバー上での印刷ドライバーの実行ダイアグラムで 図示されている。

Figure 22.14. Print Driver Execution on the Server.

しかし、似たようなものはCUPSで可能なので、引き続き読むこと。

Windowsネットワーク印刷クライアントに対する、CUPSの強力な機能の利点をどのように 利用するかを示す簡単なレシピである:

これは、クライアントにPostScriptドライバー(プリンターが非PostScriptモデルであっても。CUPS サーバー上でのドライバーがあることも要求する)を使うことを要求する。

最初に、Samba経由でのCUPSベースの印刷を有効にするため、以下のオプションをsmb.conf ファイルの[global]セクションに設定すべきである:

これらのパラメーターが指定されると、smb.conf中の(Sambaそれ自身と同様)、すべての手動設定 した印刷ディレクティブ(たとえばprint commandか lppause command)は無視される。その代わりSambaは、SambaがCUPS ライブラリ(libcups)をサポートするようにコンパイルされているとき、CUPS APIを通してCUPSと 直接やりとりする。他の印刷コマンドが設定されていない場合、印刷は、-orawオプションを 自動的に付けてパススルーする、System VAT&Tコマンドセットを 使う(もし、コンパイル時にCUPSサポートをするようしたSambaサーバーで動作するよう、個別に 定義した印刷コマンドを使いたい場合、単に classicalprinting = sysvを使う)。これは CUPS/Sambaサーバー経由での印刷ダイアグラムで図示されている。

Figure 22.15. CUPS/Sambaサーバー経由での印刷

Sambaはそれ固有のスプールディレクトリ (path = /var/spool/sambaに類似したもので設定される) を、smb.confの[printers]か[printername] セクション中で使わなければならない。 Sambaは固有スプール空間にジョブを受け取り、CUPSのスプールディレクトリ(CUPSのスプール ディレクトリは、既定値がRequestRoot /var/spool/cupsである、 RequestRootディレクティブ行で設定される)中に渡す。 CUPSはそのスプールディレクトリのアクセス権限を検査し、毎回の再起動に備えて適切な値に それをリセットする。 SambaとCUPSで共通のスプール空間を使う例は滅多に見たことがなく、何週間もこの “問題”と苦闘してきた。

WindowsユーザーはSambaでのみ認証する(構成されるどんな手段でも)。もしもSambaがCUPSと同じ ホストで動作しているならば、印刷においては“localhost”のみ許可しなければ ならない。もしも異なったマシンで動作しているならば、CUPSで印刷できるように、Samba ホストがアクセス権を得られるようにしておかねばならない。

CUPSはそのPPDの使用にあたっては“実際の”PostScriptプリンターだけにに制限 されない。CUPS開発者は非PostScriptプリンターに対してもCUPS-PPDを使って有効なデバイスと ドライバーオプションを記述するPPDコンセプトの範囲を拡張した。

CUPSは完全なPostScriptインタプリタ(RIP)を含んでいるため、これは合理的である。RIPは GhostScriptをベースにしている。これはクライアントからすべてのPostScript(と更に追加で、 その他のファイル形式)を受け取り処理できる。すべてのCUPS-PPDは、キーワード *cupsFilterで始まる追加の行を含んでいると非PostScriptプリンターに ギアを切り替える。この行はCUPS印刷システムに、受け取ったPostScriptを解釈するための プリンター固有のフィルターを使うように告げる。そのため、そのプリンターに対してPostScript RIP として振る舞うことが出来るため、そのクライアントに対してPostScriptデバイスとしてその すべてのプリンターを見せるようにし、受け取ったPostScriptコードを適切なラスタ印刷形式に 処理する。

Windowsクライアントでは“中核の”PostScript ドライバー に加えて CUPS-PPD も利用可能である。（ただし現在は CUPS PostScript Driver for Windows NT/200x/XP が推奨されている。これを使うと、制 限付きながら Adobe のドライバーが利用できる）。CUPS-PPD を使う場合、 他のスプーラではできない機能のいくつかを CUPS が利用できるよう になる。

Windowsクライアント上のCUPS PPDを使うと、すべての印刷ジョブ設定をUNIXクライアントが 出来るように制御する事が出来るようになる。

“カーネルモード”で動作するWindows NTプリンタードライバーは、ドライバーが安定せず、 よくテストされていない場合には、システムの安定性にとって高いリスクとなる。そして、できの 悪いドライバーはたくさんあるのである!特に、悪名高いものは、ジョブの終了時にサウンドカード 経由でユーザーに通知を行う追加のサウンドモジュールが動くものを持っているPCLドライバーが例で ある。通常使っていて、“ブルースクリーン”をこれが出してしまうと言うことを言う 必要があるだろうか?

PostScriptドライバーは一般的によくテストされている。カーネルモードで動作したとしても、 それらが何かの問題を引き起こすことは知られていない。これは2つの異なったPostScript ドライバーが現在存在しているという事によるのかもしれない。1つはAdobeのものであり、もう1つは Microsoftのものである。両方ともよくテストされ、Windows上で想像できるように安定している。 CUPSドライバーはマイクロソフトのもの由来である。

回避方法として、サイト管理者は、WTS上にインストールされる許可されたドライバーを、1つの 汎用PCLと1つのPostScriptドライバーだけに制限するという方針を選んだ。しかしこれは、 クライアントが使う事が出来るたくさんの印刷オプションを制限することになる。 異なったドライバーによって制御される場合、そのデバイスはより良い動作が出来るはずが、 しばしば、1つの標準ペーパトレイでの単純な印刷よりも複雑なことが出来なくなる!

PostScriptドライバーを使い、CUPS-PPDを有効にすることは、すべてのこれらの欠点を解決する とてもエレガントな方法に見える。これらは使用するWindows OSバージョンに依存する、最大3つの 異なったドライバー、すなわちAdobe、MicrosoftとCUPS PostScriptドライバーが現在有効である。 WTS上で大きな安定性の問題を引き起こすことは、上記3つのどれも知られていない(たとえ、 たくさんの異なったPPDを使ったとしても)。クライアントは(再度)ペーパトレイ、両面印刷や その他の設定を選択できる。しかし、確かな代価もある:そのクライアントに対して、CUPSサーバーは PostScript RIPとして振る舞い、“raw スプール”デバイスとして振る舞うよりも よりCPUとメモリを必要とする。更に、この設定は、最初のフィードバックがとても有望ではあるが、 広範囲にはテストされていない。

より新しいW200xとに同梱されているXPプリンタードライバーでは、Windows NTとは異なり、カーネル モードでは動作しない。ただし、両OS共に、引き続き、カーネルモードで動作するドライバーを 使う事は可能である(端的に言って、サブディレクトリ“W32X86”中の “2”にあるドライバーが、“古い”ものかだと思って良いだろう)。 以前に説明したように、AdobeのものはMicrosoft PostScriptドライバーのように安定している。 CUPSドライバーはMicrosoftベースである。これは次のような理由による。Visual Studioの ライセンスを持つ人が無償で使える、Windows NT用のMicrosoftのDDK(Device Development Kit)は、 Microsoftがライセンスを持つドライバーのソースコードが含まれる。Visual Studioのライセンスを 持つ人は、自分が作るドライバーの開発作業に、そのコードを使用し、変更する事が許可されている。 CUPSではこのように開発されている。しかし、Microsoftのライセンスは、(DDKの部分を含む) ソースコード全体を公開することは許可していない。しかし、CUPSは、GPL配下で“差分”を リリースしている。そのため、もしも“MS DDK for Windows NT”のライセンスを 持っていれば、差分コードを使い、ドライバーを自分自身で調べる事が出来る。

cupsaddsmbユーティリティ(現在すべてのCUPSバージョンに同梱)は、 Sambaの[print$]共有中に、プリンタードライバーを転送する別の解で ある。思い出してほしいのは、この共有は、クライアントが、ドライバーが配布されると期待 し、ダウンロードとインストールのためにセットアップする場所であるということである。 これは、とても簡単に、任意の(か全部の)インストールされたCUPSプリンターの共有が出来るように なる。cupsaddsmbは、Adobe PostScriptドライバーを、最近開発された Windows NT/200x/XP用のCUPS PostScriptドライバーと同様に使うことが出来る。 cupsaddsmbは、ベンダプリンタードライバーと一緒に 動作することはできず、そのマニュアルページ中に名前がある ドライバーと同じもののみ動作する。

CUPSプリンタードライバーはCUPSダウンロードサイトにある。そのパッケージ名は cups-samba-[version].tar.gzである。これには以下のような数多くの 利点があるので、Adobeドライバーよりも好まれる:

しかし、現在Windows NT,2000とXPのみがCUPSドライバーによってサポートされている。もしも、 Windows95、98とMEクライアントのサポートが必要ならば、Adobe Driverのそれぞれの部分を 入手する事も必要である。

cupsaddsmbを走らせる前に、 cupsaddsmb使用のためのsmb.confで示されるように、 smb.confを設定する必要がある。

CUPSユーザーは http://www.cups.org/software.html から正確に同じパッケージを入手できる。これは、CUPSベースのソフトウェアファイルから 分離されたパッケージで、CUPS 1.1.x Windows NT/200x/XP Printer Driver for Samba (tar.gz,192k) とタグづけられている。ダウンロードするファイル名はcups-samba-1.1.x.tar.gz である。tar.gzファイルを解凍後、以下のファイルが展開される:

root# tar xvzf cups-samba-1.1.19.tar.gz
cups-samba.install
cups-samba.license
cups-samba.readme
cups-samba.remove
cups-samba.ss

これらはESPメタパッケージャソフトウェアEPMでパッケージ化されている。 *.installと*.removeファイルは簡単なシェル スクリプトで、*.ssのtarファイルを展開したものである (*.ssは、“tar”によって回答できる、tarアーカイブ 以外の何者でもない)。次に、これは内容物を/usr/share/cups/drivers/に 置く。この内容物は以下のファイルを含む:

root# tar tv cups-samba.ss
cupsdrvr.dll
cupsui.dll
cups.hlp  

cups-samba.installシェルスクリプトは簡単に扱える:

root# ./cups-samba.install
[....]
Installing software...
Updating file permissions...
Running post-install commands...
Installation is complete.       

スクリプトは/usr/share/cups/drivers/ディレクトリ中に ドライバーファイルを自動的に置く:

root# cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/

この新しいCUPS PostScriptドライバーは現在バイナリのみである。しかし、無料で使える。 (まだ)完全なソースコードは提供されていない。その理由は、Microsoft DDKの手助けを得て Microsoft Visual Studio 6でコンパイルしつつ、開発されているからである。ドライバー開発者は フリーソフトウェアとしてソースコード全体を配布する許可を得ていない。しかし、CUPS開発者は GPL配下でソースコードの“差分”をリリースしているので、Visual StudioとDDK のライセンスを持つ人は誰でも自分自身でコンパイルすることが出来る。

CUPSドライバーは古いWindows 95/98/Meをサポートせず、Windows NT/2000/XPクライアントのみサポートする。

Windows NT, 2000と XPは以下でサポートされる:

古いWindows 95/98/MeのためのAdobeドライバーはWindows NT/2000/XPクライアントと 同じように提供されている。ファイルの組み合わせは異なったプラットフォームでは 異なる。

Windows 95, 98と MEは以下でサポートされる:

Windows NT, 2000, と XPは以下でサポートされる:

Adobeドライバーファイルの入手は、多くのユーザーにとって予想外に難しいように見える。それらは Adobe Webサイトに1つのファイルとして見えているわけではなく、自己解凍か自動インストールを 行うWindows-.exeファイルを見つけるのも難しい。おそらく内蔵されたネイティブな インストーラーを使用しなければならず、クライアント上で一回はインストールプロセスを動かす ことが必要である。これは、クライアント上ローカルにドライバー(と1つの汎用PostScriptプリンター) をインストールする。それらがインストールされた後、汎用PostScriptプリンターを共有する。 この作業後、クライアントの[print$]共有は、CUPSホストから smbclientで入手可能なAdobeファイルを保持する。

ESP Print ProソフトウェアのユーザーはAdobe PostScriptドライバーの代替として、ESCプリント ドライバーパッケージをインストールすることが出来る。これを行うために、 Easy Software Webサイトで、ESC Print Proソフトウェアの通常のダウンロード領域からドライバーファイルを 検索できる。Download Printer Drivers for ESP Print Pro 4.x 領域の間で“SAMBA”と名前が付いたリンクを探し、パッケージをダウンロード する。一度インストールすると、Printer Manager GUI中の中のメニューの、 Export Driver...を選択して、プリンターを単にハイライトさせる ことによって任意のドライバーを準備できる。もちろん、ドライバーファイルを扱うために、 あらかじめ準備されたSambaが必要である。すなわち、[print$] 共有を設定することなどである。ESP Print ProパッケージにはWindows 95/98/Me クライアントファミリ用の(ライセンスされた)Adobeドライバー一式と同様にCUPSドライバー ファイルが含まれている。

一度インストールスクリプト(と、/usr/share/cups/drivers/への cups.hlpファイルの手動での移動)を実行すると、ドライバーはSambaの [print$]共有(これはしばしば /etc/samba/drivers/にマップされ、WIN40と W32X86という枝を持つサブディレクトリを含む)中に、ドライバーが 配置できるようになる。これは、cupsaddsmbを動かすことによって 行える(CUPSリリース1.1.16以降ではman cupsaddsmbも参照)。

いったんドライバーファイルが[print$]共有に置かれ、初期化 されると、それらはダウンロード可能になり、Windows NT/200x/XPクライアントによって インストールされる。

CUPSとAdobe PostScriptドライバーの比較に興味があるだろうか?我々の目的のために、 Are you interested in a comparison between the CUPS and the Adobe PostScript drivers? For our purposes, these are the most important items that weigh in favor of CUPS:

cupsaddsmbコマンドは、必要とされるファイルを [print$]共有にコピーする。さらに追加で、このプリンターに関連 づけられているPPDは、/etc/cups/ppd/から [print$]にコピーされる。これらファイルはポイントアンドプリント 経由でWindowsクライアントのインストールの都合のために待機している。コマンドを 正しく実行できる前に、Sambaに対して認証を行っておく必要がある。小さなネットワーク 環境では、おそらくユーザーレベルのセキュリティ (security = user)を使っているだろう。

以下は、正しく動くcupsaddsmbコマンドの例である:

root# cupsaddsmb -U root infotec_IS2027
Password for root required to access localhost via Samba: ['secret']

すべてのプリンターとドライバーを共有するために、プリンター名の代わりに -aパラメーターを使う。cupsaddsmbがプリンタードライバーを Sambaに“エクスポート”してから、CUPSドライバーに関連づけられているキュー のみ動作することは明白になるべきである。

おそらく何が起きているかを見たいのだと思う。より詳細な出力は、-v パラメーターを使う。可読性向上のために下記の出力には手を入れてある。 すべての行末の“\”は手動で入れてあり、そのほかにインデントもしている:

root# cupsaddsmb -U root -v infotec_2105
Password for root required to access localhost via GANDALF:
Running command: smbclient //localhost/print\$ -N -U'root%secret' \
    -c 'mkdir W32X86; \
    put /var/spool/cups/tmp/3e98bf2d333b5 W32X86/infotec_2105.ppd; \
	put /usr/share/cups/drivers/cupsdrvr.dll W32X86/cupsdrvr.dll; \
    put /usr/share/cups/drivers/cupsui.dll W32X86/cupsui.dll; \
    put /usr/share/cups/drivers/cups.hlp W32X86/cups.hlp'
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
putting file /var/spool/cups/tmp/3e98bf2d333b5 as \W32X86/infotec_2105.ppd
putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll
putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll
putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp
  
Running command: rpcclient localhost -N -U'root%secret' 
   -c 'adddriver "Windows NT x86"   \
   "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \
    RAW:NULL"'
cmd = adddriver "Windows NT x86" \
   "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \
	RAW:NULL"
Printer Driver infotec_2105 successfully installed.
  
Running command: smbclient //localhost/print\$ -N -U'root%secret' \
-c 'mkdir WIN40; \
    put /var/spool/cups/tmp/3e98bf2d333b5 WIN40/infotec_2105.PPD; \
	put /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM;   \
    put /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV; \
    put /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP; \
    put /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD; \
	put /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL; \
	put /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;'
  added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
  Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
  NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
  putting file /var/spool/cups/tmp/3e98bf2d333b5 as \WIN40/infotec_2105.PPD
  putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM
  putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV
  putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP
  putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD
  putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL
  putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL
  
  Running command: rpcclient localhost -N -U'root%secret' \
   -c 'adddriver "Windows 4.0"      \
   "infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL:ADOBEPS4.HLP: \
   PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL, \
    ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
	cmd = adddriver "Windows 4.0" "infotec_2105:ADOBEPS4.DRV:\
	infotec_2105.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,\
	infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,\
	ICONLIB.DLL"
  Printer Driver infotec_2105 successfully installed.
  
  Running command: rpcclient localhost -N -U'root%secret'  \
   -c 'setdriver infotec_2105 infotec_2105'
  cmd = setdriver infotec_2105 infotec_2105
  Successfully set infotec_2105 to driver infotec_2105.

もし、しっかり見た場合、ネットワーク上で暗号化されていないrootパスワードが転送されて いることを発見するはずなので、注意するように。また、もしもさらによく見てみると、 出力中にNT_STATUS_OBJECT_NAME_COLLISIONというようなエラーメッセージを見つけるだろう。 これは、WIN40とW32X36というディレクトリが(以前のドライバーインストールにより) すでに[print$]というドライバーダウンロード共有中に存在 している時に発生する。これらは問題のないエラーメッセージである。

何が起きたのか?cupsaddsmbは何をしたのか?手順には5つのステージがある:

root# cupsaddsmb -H sambaserver -h cupsserver -v printer

もしもユーティリティがすべてのフィールドで正しく終わった場合、常時検査を しなければならない。少なくとも出力中の、以下の3つの メッセージをチェックする必要がある:

これらのメッセージはおそらく一般的な出力中では簡単に認識できない。もしも (ダウンロードのための、すべての有効なプリンタードライバーを 準備しようとする)-aオプションを付けてcupsaddsmbを 動かした場合、もしも個々のプリンタードライバーに、正しくにインストールすることに関して 問題がある場合、失敗するかもしれない。出力のリダイレクトは、結果を解析することを 手助けする。

もしも下記のメッセージが出た場合:

SetPrinter call failed!
result was WERR_ACCESS_DENIED

これは、このプリンターに対してuse client driver = yes という設定がされているかもしれないということを意味する。この設定を“no”に すると、この問題が解決する。smb.confマニュアルページ中の、 use client driverについての説明を参照のこと。

Samba PDC上で動かすために、標準のcupsaddsmbコマンドは動かないのか? 認証のためにパスワードを繰り返し聞かれ、コマンドは全く起動しないのか?以下にある応用の どれかを試してみてほしい:

root# cupsaddsmb -U MIDEARTH\\root -v printername
root# cupsaddsmb -H SAURON -U MIDEARTH\\root -v printername
root# cupsaddsmb -H SAURON -U MIDEARTH\\root -h cups-server -v printername

(2つのバックスラッシュに注意:最初のものは二番目のものに対する“escape”である)。

cupsaddsmbフローチャートは、cupaddsmbの 処理手順、コマンドフローとデータフローを示すチャートである。再度注意:cupsaddsmbは raw印刷キューと一緒に動かないし、そういうことを意図してもいない!

Figure 22.16. cupsaddsmbのフローチャート

cupsaddsmbの完了後、ドライバーは、クライアントから使えるようになる。 以下は、ポイントアンドプリント経由でダウンロードしインストールするために行わなければ ならない手順である。Windowsクライアントから、CUPS/Sambaサーバーをブラウズする:

数秒後、クライアントのローカルプリンター フォルダー中に新しいプリンターが現れる。Windows XP上では、 Sambaサーバー上のプリンター名という名前が付けられている (現在多くの場合kde-bitshop上のinfotec_2105のようになる)。もしもMicrosoft Wordのような アプリケーションから、テストと最初のジョブを送りたい場合、有効なプリンター一覧の ドロップダウンリスト中に、\\SambaServer\PrinterNameという エントリで新しいプリンターが現れる。

cupsaddsmbはCUPSバージョン1.1.15以上とSamba バージョン2.2.4以降でのみ 確実に動作する。もしも動かない場合か、クライアントへの自動プリンターダウンロードが成功 しないばあい、クライアント上でAdobe PostScriptドライバーのtop ofのCUPSプリンターPPDを手動で インストールトーすすることができる。次に、UNCタイプの接続のために、クライアントの プリンターキューをSambaプリンター共有に指定する: cupsaddsmb will only reliably work with CUPS version 1.1.15 or higher and with Samba version 2.2.4, or later. If it does not work, or if the automatic printer driver download to the clients does not succeed, you can still manually install the CUPS printer PPD on top of the Adobe PostScript driver on clients. Then point the client's printer queue to the Samba printer share for a UNC type of connection:

C:\> net use lpt1: \\sambaserver\printershare /user:ntadmin

これは、CUPSでネットワークされたPostScript RIP機能を使用することが出来るようになる (ユーザー“ntadmin”はプリンター共有にアクセスするための必要な権限を持つ 有効なSambaユーザーである必要がある)。これは、従来からのLanManによる方法(MS-RPCを使わない) でプリンターの接続を設定する。

印刷が動作するが、まだ問題があるとする。ほとんどのジョブは正しく印刷するが、いくつかは 全く印刷できない。いくつかのジョブは、とても良いとは見えないフォントの問題を抱えている。 いくつかのジョブは速やかに処理されるが、いくつかはとても遅い。これらの問題の多くは、 いくつかのガイドラインに従うことで、劇的に軽減できるか、完全になくなる。思い出して ほしいが、もしも使用している印刷デバイスがPostScriptが有効でない場合、 使用しているクライアントドライバーの設定が生成する出力を使って、CUPSホスト上での Ghostscriptインストールを取り扱ているはずである。以下のようにうまく処理するようにする:

最初に、rpcclientマニュアルページをチェックしよう。 個々には2つの読むべきな文節がある:

adddriver <arch> <config>は、サーバー上でプリンタードライバー 情報をインストールするために、AddPrinterDriver()RPCを実行する。 ドライバーファイルはgetdriverdirによって返されるディレクトリ中に すでに存在すべきである。archが取れる値は getdriverdirコマンドのものと同じである。config パラメーターは以下のように定義される:

Long Printer Name:\
Driver File Name:\
Data File Name:\
Config File Name:\
Help File Name:\
Language Monitor Name:\
Default Data Type:\
Comma Separated list of Files

任意の空白のフィールドは“NULL”という文字列を入力すべきである。

Sambaはプリントモニターというコンセプトをサポートする必要がないので、通信のために双方向 リンクを使うことが出来るドライバーがあるローカルプリンターのためにのみそれらは適用される。 このフィールドは“NULL”にすべきである。リモートNT印刷サーバー上で、ドライバーに 対する印刷モニターはドライバーを追加する前にすでにインストールされていなければならない。 そうしないと、RPCは失敗する。

setdriver <printername> <drivername>は、インストール されたプリンターに関連するプリンタードライバーをアップロードするために、 SetPrinter()コマンドを実行する。プリンタードライバーはプリンターサーバー 上にあらかじめ正しくインストールされている必要がある。

インストールされたプリンターとドライバーの一覧を得るための、 enumprintersとenumdriversコマンドも 参照のこと。

正確なフォーマットはマニュアルページによって明快にはならないので、 空白を含むパラメーターを扱う必要がある。以下は、それに対するもう少しわかりやすい説明で ある。ここではコマンドを改行し、改行は“\”で示している。通常、改行なしに 1行でコマンドを記述するだろう: The exact format isn't made too clear by the man page, since you have to deal with some parameters containing spaces. Here is a better description for it. We have line-broken the command and indicated the breaks with “\”. Usually you would type the command in one line without the line breaks:

adddriver "Architecture" \
   "LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\
   LanguageMonitorFile:DataType:ListOfFiles,Comma-separated"

マニュアルページが示すものは、実際に存在する3つのコロンで分離されたフィールド中の、 単純な<config>キーワードである。最後のフィールドは、 複数の(あまり尋常でない場合では、異なった20のもの)ファイルである。これは、最初は 混乱するように見えるかもしれない。“LongPrinterName”とマニュアルページが 呼んでいるものは、実際では“ドライバー名”と呼ばれるべきである。これは 自由に名前を付けられ、後でrpcclient ... setdriverコマンド中で この名前を使える。実用的な理由で、多くはプリンターと同じ名前をドライバーに付ける。 What the man pages denote as a simple <config> keyword in reality consists of eight colon-separated fields. The last field may take multiple (in some very insane cases, even 20 different additional) files. This might sound confusing at first. What the man pages call the “LongPrinterName” in reality should be called the “Driver Name”. You can name it anything you want, as long as you use this name later in the rpcclient ... setdriver command. For practical reasons, many name the driver the same as the printer.

これは全く単純ではない。“どのファイルがドライバーファイルをどうやったら分かるか”、 各“データファイル”, “構成ファイル”, “ヘルプファイル” と“Language Monitorファイルの場合は?”という質問があるだろう。答えのために、 共有プリンターを持つWindows NTがそれらのファイルをどのように提供しているかを見てみるのも よいかもしれない。覚えておいてほしいが、この全体の手続きはネットワーク上でWindows コンピューターが発生させたトラフィックをモニターすることによってSambaチームにより開発 されねばならなかったと言うことである。Windowsマシンに切り替えて、UNIX ワークステーションからうまくアクセスしても良い。それが何を送っているかを見るために、 rpcclientで問い合わせてもよく、より明快にするために、マニュアル ページの理解を試みても良い。 It isn't simple at all. I hear you asking: “How do I know which files are Driver File”, “Data File”, “Config File”, “Help File” and “Language Monitor File in each case?” For an answer, you may want to have a look at how a Windows NT box with a shared printer presents the files to us. Remember that this whole procedure has to be developed by the Samba Team by listening to the traffic caused by Windows computers on the wire. We may as well turn to a Windows box now and access it from a UNIX workstation. We will query it with rpcclient to see what it tells us and try to understand the man page more clearly.

We could run rpcclient with a getdriver or a getprinter subcommand (in level 3 verbosity) against it. Just sit down at a UNIX or Linux workstation with the Samba utilities installed, then type the following command:

root# rpcclient -U'user%secret' NT-SERVER -c 'getdriver printername 3'

結果から、どれがどれであるか明快になるべきである。以下はインストールの例である:

root# rpcclient -U'Danka%xxxx' W200xSERVER \
    -c'getdriver "DANKA InfoStream Virtual Printer" 3'
    cmd = getdriver "DANKA InfoStream Virtual Printer" 3

 [Windows NT x86]
 Printer Driver Info 3:
         Version: [2]
         Driver Name: [DANKA InfoStream]
         Architecture: [Windows NT x86]
         Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.DLL]
         Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\INFOSTRM.PPD]
         Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRPTUI.DLL]
         Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.HLP]
 
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
 
         Monitorname: []
         Defaultdatatype: []

いくつかのプリンタードライバーはDependentfilesというラベルで、 追加のファイルを一覧表示し、それらは最後のフィールドである ListOfFiles,Comma-separated中に押し込まれる。CUPS PostScript ドライバー用には、それらは不要で(Adobe PostScriptドライバーも)、それゆえ、フィールドには “NULL”が入るだろう。 Some printer drivers list additional files under the label Dependentfiles, and these would go into the last field ListOfFiles,Comma-separated. For the CUPS PostScript drivers, we do not need any (nor would we for the Adobe PostScript driver); therefore, the field will get a “NULL” entry.

マニュアルページから(と上記のcupsaddsmbの引用された出力から)、 手動でのアップロードとドライバーファイルの初期化を成功させるために、一定の状態を用意 する必要があることが明確になる。2つのrpcclientサブコマンド (adddriverとsetdriver)は、成功させるために、 以下の前提条件を準備する必要がある:

すべての要求されたコマンドを実行して、手動で、プリンタードライバーをインストールしてみる。 最初、これは複雑なプロセスなように見えるという理由で、手順を1つずつ、やらなければ ならない、単一のアクションアイテム毎に説明する。 We are going to install a printer driver now by manually executing all required commands. Because this may seem a rather complicated process at first, we go through the procedure step by step, explaining every single action item as it comes up.

もしもSambaが、キューがそこにないと考えた場合、setdriverコマンドは失敗する。 インストールが成功すると以下の頼もしいメッセージが表示される:

Printer Driver ABC successfully installed.

この後、adddriver部分の手続きが続く。しかし、以下のような 期待はずれのメッセージが出るかもしれない: result was NT_STATUS_UNSUCCESSFUL

CUPS中のキューを見ることができるだけでは十分ではないので、 lpstat -p ir85wmコマンドを使う。最も最近のSambaのバージョンでは、 適切なキュー一覧の更新を妨害するというバグがある。Sambaを再起動するか、すべてのsmbd プロセスにHUPを送るまで、新しくインストールしたCUPSプリンターの認識に失敗する。なぜSambaが setdriverコマンドを正しく実行しないかという理由がこれかと言うことを 検証するために、Sambaがプリンターを“認識している”かを調べる:

root# rpcclient transmeta -N -U'root%xxxx' -c 'enumprinters 0'|grep ir85wm
        printername:[ir85wm]

別のコマンドでのやり方もある:

root# rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm' 
        cmd = getprinter ir85wm
        flags:[0x800000]
        name:[\\transmeta\ir85wm]
        description:[\\transmeta\ir85wm,ir85wm,DPD]
        comment:[CUPS PostScript-Treiber for Windows NT/200x/XP]

所で、上記のコマンドに、さらにいくつかを使うことが出来、もちろん、 リモートのWindows NT印刷サーバーにもインストールできる!

Windows NT(印刷)サーバーは、Windowsレジストリ中にエントリを格納することによって、その クライアントに対して、その作業を提供するのに必要なすべての情報を記録する。クライアントの 問い合わせはレジストリを読み取ることによって回答が行われ、Administratorかユーザーの 構成設定はレジストリ中に書き込むことで保存される。SambaとUNIXは明らかにこのような レジストリを持っていない。Sambaはその代わりに、一連の*.tdbファイルに すべてのクライアントに関連する情報を保存する(TDBはtrivial data baseの省略形である)。 これらはたいてい/var/lib/samba/か /var/lock/samba/にある。印刷関連のファイルは、 ntprinters.tdb, printing.tdb, ntforms.tdbとntdrivers.tdbである。

*.tdbは人間に可読なファイルではない。それらはバイナリ形式である。 “なぜASCIIでないのか?”と質問するかもしれない。 “結局の所、ASCII設定ファイルは、便利でUNIXでの伝統である。” Sambaチームによって、デザインがこうなった理由は、主に性能である。Sambaは高速で動作する 必要がある。ある環境では数千にもなる、各クライアントの接続毎に分離された smbdプロセスが動く。これらのいくつかは、 同じ時間に同じ*.tdbファイルをそれら smbdプロセスが書き込みアクセスをする必要があるかもしれない。 Sambaの*.tdbファイル形式は、これを提供できる。多くのsmbd プロセスは同じ時間に同じ*.tdbファイルに書き込みができる。 これは純粋なASCIIファイルでは不可能である。

すべての*.tdbファイルはすべての読み取りと書き込みアクセス間で 整合性を保持することはとても重要である。しかし、これらのファイルが 壊れることがあるかもしれない(書き込み処理中に、 kill -9 `pidof smbd'を実行すると、ダメージを与えることになる。 そのほか、急な電源断など)。このようなトラブルの場合、古い印刷関係の *.tdbファイルを削除するのが唯一の解である。その後、その時点で *.tdbファイルをバックアップから戻さない限り、すべての印刷関連の 設定を再作成する必要がある。

Sambaは、システム中にある*.tdbファイルをバックアップする、 rootユーザーを手助けする小さなユーティリティを同梱している。もしも引数なしでそれを 動かすと、以下のメッセージが表示される:

root# tdbbackup
 Usage: tdbbackup [options] <fname...>
 
 Version:3.0a
   -h            this help message
   -s suffix     set the backup suffix
   -v            verify mode (restore if corrupt)

以下はprinting.tdbファイルをどのようにバックアップするかの例である:

root# ls
.              browse.dat     locking.tdb     ntdrivers.tdb printing.tdb
..             share_info.tdb connections.tdb messages.tdb  ntforms.tdb
printing.tdbkp unexpected.tdb brlock.tdb      gmon.out      namelist.debug  
ntprinters.tdb sessionid.tdb
 
root# tdbbackup -s .bak printing.tdb
 printing.tdb : 135 records
 
root# ls -l printing.tdb*
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb.bak

最近、ほとんどのLinuxディストリビューションは、(すべてのUNIXとMac OS XとDarwinでも動く) 印刷関連のソフトウェアを作成するために、 Linuxprinting.orgからのユーティリティに 頼っている。このサイトからのユーティリティは、サポートしているすべてのモデル、すべての スプーラ、すべてのOSとすべてのパッケージ形式(それらがないので)に対して、ドライバーとPPDの 簡単な更新が出来る、エンドユーザーにとてもわかりやすいインタフェースを持っている。その 歴史は、数年前にさかのぼる。

最近、Foomaticは、対応プリンターモデルが 1,000を超えるという 驚くべきマイルストーンに到達した。Linuxprinting.orgは、プリンタードライバー、サポートする モデルと、Foomatic データベース中で有効な種々のドライバー/プリンターの組み合わせに対するオプションについての、 すべての重要な要素を保持している。現在、そのデータベース中には、 245のドライバーが存在 する。多くのドライバーは種々のモデルをサポートし、多くのモデルは、異なったドライバーで 動作するかもしれない。これはあなたが選択するものである!

以下はfoomati-ripで制御される、CUPSでのLaserJet 4Plus互換プリンターインストール手順である (SuSE、UnitedLinuxとMandrakeにおける最新ディストリビューションではFoomatic-PPDの完全な パッケージとfoomatic-ripユーティリティを同梱している。 Linuxprinting.orgに直接行くと最新のドライバー/PPDファイルを入手できる)。

一度Foomatic PPDで設定された印刷キューに印刷すると、CUPSは適切なコマンドを挿入し、 結果のPostScriptファイル中にコメントを挿入する。foomatic-ripはそれを読み、それらに 対して処理を行うことが出来、さらに、ジョブファイル中に埋め込まれている、特別にエンコード されたFoomaticコメントのいくつかを使う。それらは順に(ユーザーにとっては透過的に) どのように結果のラスタデータを見えるようにすべきかと、どのプリンターコマンドを、 データストリーム中に埋め込むかを、正確に、プリンタードライバーに指示する、複雑なGhostscript コマンドを組み立てるのに使われる。以下が必要である:

CUPSで印刷quotaをrootがどのように設定するかのコマンド例であり、存在するプリンターが “quotaprinter”であることを仮定している:

root# lpadmin -p quotaprinter -o job-quota-period=604800 \
	-o job-k-limit=1024 -o job-page-limit=100

これは個々ののユーザーに対して、604800秒(=一週間)で、100ページまたはデータが1024KBでの 制限を行う(どちらか小さい方)。

CUPSで正しく計測するために、印刷ファイルはCUPSpstopsフィルターに送られる必要がある; そうでない場合、ダミーのカウント“1”を使う。いくつかの印刷ファイルは それに送られないが(例えば画像ファイル)、それらはほとんど1ページのジョブである。 これはまた、それらのファイルを“raw”(すなわちそれらに何も変更をせず、 フィルタリングもしない)すぷーすする、クライアントコンピューターとCUPS/Samba上で動いている、 対象プリンター用のプロプラエティなドライバーは、1ページとして計測するということでもある!

課金を行える機会を得るために、それらのクライアントからPostScriptで送る必要がある (すなわち、そこでPostScriptドライバーを動かす)。もしも、プリンターが非PostScriptモデル ならば、対象のプリンター用に印刷可能な形式にファイルを変換するためのジョブを、CUPSで 行わせる必要がある。Linuxprinting.orgにはドライバーの リストがある。

CUPS 1.1.16より前は、Windowsクライアント上でAdobe PostScriptドライバーを使うことが出来る のみであった。このドライバーの出力は、CUPS/Sambaサイド上のpstops フィルターに常時渡されるわけではなく、そのため、正しく計測出来なかった(その理由は、 それがしばしば使用されるPPDに依存するからであり、CUPSにpstopsを スキップさせる真のPostScriptの直前にPJL-ヘッダーが書かれ、直接pstoraster ステージに行くからである)。

CUPS 1.1.16とそれ以降のリリースから、Windows NT/200x/XPクライアント用のCUPS PostScript ドライバーを使うことが出来る(これはcups-samba-1.1.16.tar.gzという パッケージとしてhttp://www.cups.org/のダウンロード領域中に タグされている)。これはWindows 9x/Meクライアントでは動かないが 以下は保証される:

この組み合わせによる設定についてのより詳細は、cupsaddsmbのマニュアル ページで読むことが出来る(これはCUPSがインストールされている所でのみに存在し1.1.16 以降で有効である)。

ジョブの各ページに対するpage_log中のCUPSログの項目は以下の通り:

以下は項目を含む形式の図示を行うための、CUPSサーバーのpage_logファイル から抜き出したものである:

tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13
Dig9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33

これはジョブID401で、tec_IS2027上で ユーザーkurtによって印刷され、64ページのジョブで三部印刷され、 #marketingに請求が行き、IPアドレス10.160.50.13. から送られた。次のジョブはIDが402であり、ユーザー bossによって、10.160.51.33というIP アドレスから送られ、1ページ、440部印刷され、finance-depに 請求が行った。

何か問題か欠点がこのquotaシステムにあるだろうか?

これは現在使えるものの中で最も優れたシステムであり、CUPS 1.2にむけて大量の改善が 行われている:

使用できる他のアカウントツールは以下のものが含まれる:PrintAnalyzer, pyKota, printbill, LogReport。 これらのツールについての詳細はググること。

CUPS設定ファイルcupsd.conf中で設定される、いくつかの 重要なパラメーターは以下の通り:

(MaxJobsPerUserとMaxJobsPerPrinterという 追加の設定もある)。

すべてをきちんと動くようにするために、以下の3つを行う必要がある:

すべてを手動で行いたいならば、printing = cupsを printing = bsdに置き換える。そうすると手動で設定した コマンドが動作し(テストはしていないが)、 print command = lp -d %P %s; rm %sが期待通りの 事を行うだろう。

Windows 9x/Me用クライアント用には、最大8文字までのプリンター名を必要とする (あるいは、“8文字に3文字の拡張子”)。そうでないと、 Sambaからそれらをダウンロードするときに、ドライバーファイルが転送できない。

security = userを設定したか? Sambaアカウントのrootとしてsmbpasswdを使ったか? アカウントを作成するために、smbpasswd -a rootを使い、 最初の質問にパスワードを入れる。あるいは、Enterを二回入力することで、 ループを終了する(パスワードを入力しないで)。

もしも、エラーが“Tree connect failed: NT_STATUS_BAD_NETWORK_NAME” ならば、/etc/samba/driversディレクトリを作成するのを忘れている。

もしもcupsaddsmbかrpcclient addriverが、 WERR_BAD_PASSWORDというエラーメッセージを出す場合は、 the previous common errorを参照すること。

“cupsaddsmb”を使うと、PPDが存在する間、 “No PPD file for printer...”というメッセージが出る。 この問題の理由は?

CUPS上でプリンター共有を有効にしていないだろうか?これは、 “cupsaddsmb”が動いているホストからのアクセスを拒否する、 CUPSサーバーのcupsd.conf中に、 <Location /printers>....</Location> があるということである。cupsaddsmbをリモートで使っているか、 -hパラメーターを付けて: cupsaddsmb -H sambaserver -h cupsserver -v printername として使っている場合、これは問題となりえる。

cupsd.conf中のTempDir ディレクティブが正しい値に設定されているだろうか?またそれは書き込み可能だろうか?

Sambaの観点からどのユーザーであるかを、smbstatusを 使って調べる。[print$]共有に対して書き込み許可が あるだろうか?

ひとたび間違ったユーザー(たとえば、map to guest = bad user を設定した場合、しばしば発生するnobodyなど)で接続すると、Windows エクスプローラーは異なったユーザーで再度接続する試みを受け付けない。Sambaに対しては全くデータ 転送が出来ないが、Sambaがアクセスを拒否したと考えられる不可解なメッセージが表示され 続ける。有効な接続の状態をsmbstatusで確認すること。そして、当該の プロセス(PID)をKillする。まだ再接続は出来なく、接続しようとすると、 You can't connect with a second account from the same machine というメッセージがすぐに出る。再説俗を試みても、、まだ1バイトもSambaには届かない (ログを見ること。“ethereal”を使う)。Windows上のすべてのエクスプローラーを 閉じる。 これは確立した接続としてメモリ中にキャッシュされたものを、Windowsに 捨てさせる。次に正しいユーザーで接続する。一番良い方法は、DOSターミナルウィンドウを 使い、最初に net use z: \\GANDALF\print$ /user:rootを行う。 異なったアカウントで接続されたと言うことを、smbstatusで確認する。 この後、プリンターフォルダーを開き(Sambaサーバー上の ネットワークコンピューターで)、質問中のプリンター上で右クリックし、 接続....を選択する。

nobodyとして接続されていることをsmbstatus で確認するが、 本当はrootかprinter adminにしたい。これは、おそらく、正しくないユーザー名(たぶん 何らかのミス)を指定した時に、黙ってguest accountとする、 map to guest = bad userのせいであろう。 これを防ぐためには、map to guestを取り除く。

この情報は、Microsoft Windows NT/200x/XPクライアント上で、AdobeドライバーからCUPSドライバーに アップグレードした時、それに関連した問題の体験を、メーリングリスト上に投稿されたもの によっている。

最初に、すべての古い、Adobeが使っているプリンターを削除する。次に、すべとの古い Adobeドライバーを削除する(Windows 200x/XP上では、プリンターフォルダーの 背景部分で右クリックし、Server Properties...を選択し、 ドライバータブを選択し、ここで削除する)。

“そのままの”rootユーザー名を使っていないか?以下の方法を 試してみよう: cupsaddsmb -U DOMAINNAME\\root -v printername> (2つのバックスラッシュ:最初のものは二番目のものを“エスケープ” する事に注意)。

クライアント上のプリンターの削除は、ドライバーも一緒に削除はしない (それを確かめるために、プリンターフォルダーの白い背景部分で 右クリックし、サーバーのプロパティを選択し、 ドライバータブをクリックする)。これら同じ古いドライバーは、 同じ名前でプリンターをインストールする時に再度使われる。もしも、新しいドライバーに アップデートしたい場合は、古いものを最初に削除する。削除は、同じドライバーを使う他の プリンターが無い場合にのみ可能である。

ローカルセキュリティポリシーは、未署名のドライバーのインストールを許可しないようにも できる。“ローカルセキュリティポリシー”は全くプリンタードライバーの インストールを許可しないようにしてもよい。

Windows XPは“ユーザー単位に”SMBプリンターを扱うことが出来る。 これは、すべてのユーザーは自分自身でプリンターをインストールする必要があることを意味する。 すべてのユーザーに対してプリンターを有効にするためには、Windows XPにおける内蔵IPP クライアントの機能を使う事になるかもしれない。 http://cupsserver:631/printers/printernameという印刷パスで プリンターを追加する。これについては引き続き調査中である。おそらく、すべてのユーザーに対して 自動的にプリンターのインストールが出来るログオンスクリプトかもしれない。

印刷の変更のために、NT++クライアント上でその機能に通知する。これらは 最初にサーバーサービスを動かす必要がある(XP中では File & Print Sharing for MS Networksに名前が変わっている)。

Windows XP SP1では、ポイントアンドプリントの制限ポリシーが導入された(この制限は、 “Administrator”か“Power User”グループのユーザーには適用されない)。 グループポリシーオブジェクトエディター中で、 ユーザーの設定 -> 管理テンプレート -> コントロールパネル -> プリンターに 行く。ポリシーは自動的に有効に設定され、 ユーザーはそのフォレスト中のマシンに対してのみポイントアンドプリントが 使える。おそらく、無効か、ドライバーのダウンロードをSambaから出来るように、 ユーザーはそれらのサーバーに対してのみポイントアンドプリントが使える それを変更する必要がある。

何をしているのだろうか?間違っているに違いない(しかし、これを発見するのは容易では ない)。すべてを設定するように見えるダイアログを表示するための、 3つの異なった方法がある。それら3つのダイアログは、同じように見える が、そのうちの1つのみが意図しているものである。これをすべてのユーザーに対して行うために、 AdministratorかPrint Administratorである必要がある。XP上でどのようにやるかは以下の通り:

違いがわかるだろうか?私にはわからない。しかし、“C.1. から C.6.”の手順で 到達した最後のもののみ、任意の設定を恒久的に保存し、新しいユーザーの既定値となる。もしも、 すべてのユーザーに同じ既定値を設定したいならば、これらのステップを as Administrator(smb.conf中でprinter admin であるもの)で、クライアントが、(クライアントが、以下の手順Aまたは B)によって、各固有の、ユーザー単位の既定値を 設定出来る)ドライバーをダウンロードする前に行う必要がある。

Optimize for Speedを使わずに、代わりに、 Optimize for Portabilityを使う(Adobe PSドライバーの場合)。 Page Independence: Noを使わない。常時、 Page Independence: Yesを使う(Windows NT/200x/XP用の、 Microsoft PDドライバーとCUPS PSドライバー)。もしもフォントに問題がある場合には、 Download as Softfont into printerを使う(Adobe PS ドライバーの場合)。TrueType Download Optionsオプション用に、 Outlineを選択する。もしも、非PSプリンターでトラブルがあるか、 選択できる場合はPostScript Level 2を使う。

以下と同様: cupsaddsmbの最後のコマンドが完全に終わっていない。もしも、 cmd = setdriver printername printernameの結果が NT_STATUS_UNSUCCESSFULの場合、おそらくプリンターがまだSambaによって認識されていない。 ネットワークコンピューター中に表示されているだろうか? rpcclient hostname -c `enumprinters'で表示されるだろうか? smbdを再起動(か、smbstatusで一覧表示されるすべてのプロセスに対して kill -HUPを行う)し、再度試してみる。

同じ位置へのCUPSスプールディレクトリの設定で、以前に何か問題が起きなかったか? (cupsd.conf中のRequestRoot /var/spool/samba/か、 その逆:[printers]セクション中で、 /var/spool/cups/をpath>として設定しているか)? これらは異なってなければならない。cupsd.conf 中のRequestRoot /var/spool/cups/とsmb.confの [printers]セクション中の path = /var/spool/sambaを設定する。それ以外は、 cupsdは再起動後毎回そのスプールディレクトリのアクセス許可を整理するので、印刷は確実に うまくいかない。

この場合、“lp”という名前の印刷キューが、間欠的にジョブを取りこぼし、 送られたものとは完全に違うものを出力する。

プリンターに対して“lp”という名前を付けるのは好ましくない。これは、伝統的な UNIXにおける既定値のプリンターである。CUPSは暗黙のクラスを自動的に作成する事を行うように 設定されているかもしれない。これは、デバイスをプールするために同じ名前のすべてのプリンターを グループ化するためと、ラウンドロビン方式でジョブのロードバランスを取るということである。 誰かが“lp”という名前のプリンターを持っている場合にもこれがあり得る。その人の ジョブを受け取り、無意識にその人のデバイスに自分のジョブを送っているかもしれない。 プリンター名に対して厳密の制御をするためには、巨大なネットワーク環境において起こるかも しれない事に対する、より良い制御を行う、BrowseShortNames Noを 設定する。

共有されたPostScriptプリンターを持つWindowsマシンに繋ぐために、smbclient を、 smbclient //windowsbox/print\$ -U guest のように使う。W32X86/2サブディレクトリに移動でき、 mget ADOBE*し、あるいはWIN40/0で、同じ事をやる。 他のオプションは、Adobe Webサイトから*.exeをダウンロードする。