Ubuntu 17.04の注目機能の一つ「ドライバーレス印刷」を使ってみたところ、プリンターは簡単に認識したのですが残念ながら不具合に見舞われました。今回はその不具合の解析とエラー報告を行った経緯を紹介します。

先に結論を述べると、ドライバーレス印刷の不具合についてはUbuntuのCUPSパッケージに報告を出すのがよいです。

ドライバーレス印刷を試したい

Ubuntu 17.04は筆者にとって重要なバージョンです。リリースノートにて長文で解説されている目玉機能、ドライバーレス印刷がその理由です。早速使ってみようとメインPCに導入し、昨年に転居したときに梱包したままだったプリンターを取り出してみると……壊れています。うーん、なんということ……。

しかしこれは新しいプリンターを試すチャンスであると捉えることもできます。さっそく機種選定です。

ドライバーレス印刷が導入されたことで、Ubuntu向けにプリンタードライバーが提供されているかどうかを気にしなくてもよくなりました。プリンターがApple AirPrintまたはIPP Everywhereに対応していればよく、Ubuntu側にプリンタードライバーの導入は不要です（だから「ドライバーレス⁠」⁠）⁠。特に家庭用プリンター・複合機の多くが今はApple AirPrint対応を謳っています。Ubuntuでの利用を考えた場合でも、選択肢は格段に広がったことになります。

ですが、印刷はともかくとしてスキャナーも使いたいこと、ドライバーレス印刷はまだ新しい機能なので何か問題があったときに印刷できないのも困ります。そこで、第286回「UbuntuからEPSON複合機EP-805Aを使用する」と同じ理由でEPSON EP-879AWにしました。EPSONの2016年秋モデルで、6色インクを用いた多機能・省スペースのインクジェット複合機です。もちろんApple AirPrint対応機種です。

早速接続。簡単に認識するも……

ドライバーレス印刷でUbuntuからプリンターを使うように設定するのは、拍子抜けするほど簡単です。

EP-879AWはWPSでのネットワーク設定が可能なので、数ステップの操作でUbuntu PCと同じネットワークに接続できました。すると、Ubuntu側ではなにも設定しなくても、［⁠システム設定⁠］⁠-［⁠Printers］でプリンターのアイコンが追加されています（図1⁠）⁠。すごい！

右クリックで［プリンターのプロパティ］を開き、[テストページの印刷]を行ってみます。印刷はされました……が、結果を見るとモノクロになっています。

アプリケーションからも試してみました。LibreOfficeやChromiumなどからの印刷でも、やはりモノクロになってしまいます。

原因を調べてみる

「新品で買ってきたプリンターが使えないのかも」という不安と、「⁠これを調べた結果はネタになるぞ」というワクワクした気持ちと両方を抱えながら調べてみます。

プリンター自体のチェック

こういう機器がらみの不具合の基本は、まずは機器そのものが壊れているかどうかをチェックすることです。次の2点から、機器は問題なさそうということを確認しました。

• 初期導入したときのヘッドパターンの印刷では正しく6色とも印刷されていた。
• EP-879AWのコピー機能を用いてカラー原稿をスキャンしてコピーしたところ、正しくカラーの結果が得られた。

ここでWindowsやmacOSのマシン、あるいはApple AirPrintに対応したモバイルデバイスがある場合はそれらで試してもよいでしょう。しかし残念ながら、筆者は試す機器を持っていないので次に進みます。

プリンタードライバーを導入しての確認

せっかくUbuntuで利用できるドライバーがあるプリンターを選んだので、それで試してみます。

インストール手順は第286回の説明と同様なので省略しますが、一つ問題があります。というのは、［⁠システム設定⁠］⁠-［⁠Printers］でプリンターを「追加」しても、常にドライバーレス印刷が選ばれてしまうのです。

ドライバーを使うように切り替えるには、［⁠システム設定⁠］⁠-［⁠Printers］から、追加したプリンターを右クリック［プリンターのプロパティ］を選び、［⁠製造元とモデル］の［変更］ボタンを押下して、ドライバーパッケージの導入にて選ばれた末尾が「⁠（⁠Seiko Epson Corporation LSB3.2⁠）⁠」となっているものを選びます（図2⁠）⁠。「⁠現在の設定の転送を試みる」は、新しい設定を利用するほうを選んでください。

これでEPSONで配布されているドライバーが使えるようになりました。同じようにテスト印刷してみると、きちんとカラー印刷できます。

Ubuntuからもちゃんと使える状態になり一安心。調査を続けます。

CUPS印刷システムとしての調査

ここから先の調査はCUPSの印刷システムについての理解が必要になるため、簡単に説明しておきます。

実のところ「ドライバーレス印刷」といっても、ドライバー的な役割をするものが存在しないわけではなく、ただ、それを個別に導入する必要がない仕組みなのです。

まず、アプリケーションやユーザーに対して「このプリンターはこういう能力（両面やカラー印刷の可否、印刷可能な用紙サイズなど）があるよ」と示す情報は、CUPSではPPDというテキストファイルで管理されています。

通常のプリンタードライバーは、プリンターの情報を持つPPDファイルを含んでいますが、ドライバーレス印刷では、プリンターが接続されたときに、能力をInternet Printning Protocolで得てPPDを自動生成して登録しています。

また実際の印刷時には、CUPSの印刷キューに投入されたデータは、いくつかのフィルターを連結したパイプラインで「プリンターが解釈できるデータ」に変換されます。

Apple AirPrint・IPP Everywhereのポイントは「どのプリンターでも解釈できるビットマップ形式」を決めることで、プリンター個別のデータを作る処理を不要にしたことです。ドライバーレス印刷は、この「どのプリンターでも解釈できるデータ」を作るフィルターを標準で持っているため、個別のドライバーの導入がいらないのです。

そのため、ドライバー印刷のトラブルシュートにおいても次の視点で調査が必要です。

• 対応するPPDを参照
• フィルターが適切に動作しているかを確認

PPDの確認

CUPSのプリントキューに対応するPPDは、/etc/cups/ppd以下にあります。中身を覗いてみましょう。まずは次の部分です。

*ColorDevice: True

モノクロになってしまうということはカラーデバイスであると認識されていないのではないかと思ったのですが、そうではないようです。

そのあとに、チェックしたのは次の部分です。

*cupsFilter2: "image/pwg-raster image/pwg-raster 0 -"
*cupsFilter2: "image/urf image/urf 100 -"
*cupsFilter2: "image/jpeg image/jpeg 0 -"

これは最終的にプリンターに送り込むことができるデータ形式です。次のことが読み取れます。

• pwg-rasterで示されるPWG RasterはIPP Everywhere標準のビットマップ形式です。CUPS Rasterという形式が元になっています。
• urfはApple Rasterという形式です。名前の通りApple AirPrintで用いられます。
• このプリンターはJPEGデータを直接受け取ることもできます。

lprでデータを送ってみる

JPEGデータを受け取れることがわかったので、lprコマンドを用いてプリントキューにJPEGデータを送ってみます。

$ lpr -P EPSON-EP-879A-Series TEST.jpg

これはカラーで印刷されました。

では、アプリケーションから印刷するときと同じように、PDFファイルを送ってみましょう。

$ lpr -P EPSON-EP-879A-Series TEST.pdf

モノクロになってしまいます。PDFファイルからラスターデータを作るフィルターパイプラインに問題がありそうなことがわかりました。

プリンターに送られるはずのデータを確認する

CUPSが持っているFileDeviceという機能を用いて、どんなデータが送られているかを確認します。

/etc/cups/cups-files.confファイルを次のように変更して、cupsを再起動すれば機能が有効になります。

# Do we allow file: device URIs other than to /dev/null?
FileDevice Yes

［システム設定⁠］⁠-［⁠Printers］でプリントキューを複製し、新たなキューの設定の「デバイスURI」をfile:///tmp/test.prnとして、印刷を行います。/tmp/test.prnというファイルができますので、fileコマンドで確認します。

$ sudo file /tmp/test.prn
/tmp/test.prn: Cups Raster version 2, Big Endian, 360x360 dpi, 2976x4209 pixels 1 bits/color 1 bits/pixel ColorOrder=Chunky ColorSpace=black

フィルターパイプラインで生成されたpwg-rasterファイルが、すでにモノクロになっていることを確認できました。

不具合を報告する

これは明らかな不具合なので報告することにします。しかし、いったいどこに不具合報告するのが適切なのでしょうか。

印刷機能に限らず、オープンソースの不具合報告はなるべく、「⁠不具合の原因となっている部分」を特定して、その開発者に報告するのが解決の近道です。しかし、現在のシステム構成は複雑なため、どこに原因があるかを特定するのはなかなか困難です。今回の場合はCUPS、cups-filters、プリンターと最低でも3つの可能性があります。

しかし、ちょっとズルをすれば、要は原因を特定して問題を解決できる人間に伝わればよいわけです。ドライバーレス印刷の場合、2つのキーマンがすぐに浮かびます。

一人はオープンソースの印刷標準化団体OpenPrintingのリーダーかつCanonical社員のTill Kamppeter、もう一人はCUPSのオリジナル作者であり現Apple社員のMichael Sweetです。

過去の経験からすると、Michaelは「それはCUPSの問題ではない」といって不具合を閉じたがる傾向があるのに対し、Tillは問題を解決できるなら手段は汚くてもよいという姿勢が見えます。であれば、一旦はTillに見てもらう、つまりUbuntu側で起票するのがよさそうです。

考えた末に、最終的にモノクロのデータを生成しているモジュールということでcups-filtersパッケージに起票しました。

そして解決へ

起票後わずか数時間でTillから「CUPS付属のipptoolで、プリンターが返している情報を知らせてほしい」と反応があり、それに答えたところ、「⁠CUPSのupstreamに報告したよ」とコメントがありました。CUPS側の問題ということで、影響パッケージにCUPSも追加されました。

CUPSのチケットでの議論は次のような流れでした。ここまで1日足らずです。

Till:「IPPの問い合わせで、プリンターがサポート色空間を大文字で返してくるために、CUPSが生成するPPDに問題が起きる。大文字小文字を無視できないか？」

Mike:「それはプリンターがIPPの仕様に合致していない。考えてみるけど、EPSONにレポートして修正ファームウェアを出してもらうのがいい」

IPP（Internet Printing Protocol）では大文字小文字も含めスキーマが定義されています。Mikeの言い分はもっとも……とはいえ、彼も現実主義者ではあって、ファームウェアの修正がそれほど簡単ではないことは理解しています。そして数日後、ふと見直したところ：

• [master d2817c9] Allow PWG Raster types to vary by case (non-conformant behavior for Issue #4998)

直っています！

このパッチを取り込んだCUPSのパッケージをあわしろいくやさんに作っていただきました（この場を借りてお礼申し上げます。ありがとうございました⁠）⁠。そして導入したところ、PPDの生成ロジックは対応できていることを確認しました。

ただ、一度ドライバーレス印刷でPPDを生成してしまった場合はどこかでそれを覚えているようで、現在、問題の解決には至っていません。Ubuntuのバグ票で質問はしているので、遠からず問題は解消されるのではと思っています。

今回の教訓として、ドライバーレス印刷の場合はUbuntuのCUPSパッケージの不具合として報告するのがよさそうということがわかりました。

ドライバーレス印刷は新しい機能です。筆者のように不具合にあたる可能性もあるでしょうが、なにしろ使うのは感動するほど簡単です。手元に対応プリンターをお持ちの場合、ぜひ試して結果を共有していきましょう！