おがさわらなるひこのオープンソースとかプログラミングとか印刷技術とか

おがさわらなるひこ @naru0ga が技術系で興味を持ったりなんだりしたことをたまーに書くブログです。最近はてなダイアリー放置しすぎて記事書くたびにはてな記法忘れるのではてなブログに移行しました。

クリエイティブ・コモンズ・ライセンス
特に断りがない場合は、本ブログの筆者によるコンテンツは クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。

ドライバーの不具合でプリンターがハングするとかなんで？＆各社のLinux印刷状況ちょろっとまとめ

Linux Printing

ご無沙汰しております。
最後のエントリーが入社報告ってのは仮にも技術ブログのつもりなのにどうなんよって話なんですけど、いやー、なんかこう、下書きにはいくつか記事が溜まってるんですが、忙しくなっちゃて時期を逸したり、書くのにエネルギーが必要だったり、なんだりかんだりで放置してます。

んでまあ、Twitter でちょこちょこ書いたネタってもしかして案外公の場で書かれたりしたことってないのかなって思ってまとめておくことにしました。ナウなヤングなら togetter とか使うのかもしれませんが、ぼくはロートルなのでああいうの苦手なんすよ。

プリンターってデータがおかしいぐらいで死ぬもんなの？

きっかけは Ubuntu ユーザーであるところのテラキン (@terakinizers) 先生が「C 社の IJ と Ubuntu との相性が最悪で結局電源ケーブル引きぬいた。なんでこんなことになるの？」的なことを書いてるのに対して「電源ぶっちんは壊れる可能性があるので、だましだまし使うより人に譲って、別の会社の製品を買ったほうがいいと思います」と私が書いたのが最初で、そこらへんはまあ省略して。

ここらへんは当然私が実装を知ってる訳じゃないので一般論です。たとえば USB の場合パケットサイズが固定なので、パケットサイズ未満のデータを送るとそこでデータ転送終了の意味になるって決まりがあるんですが*1、こういうハンドシェイクをタコってるとかの話ですね。今はコスト制約が厳しいから、潤沢にリソースがある PC 側でなんとかできれば、プリンター側は少ないリソースで処理できるようにシステム設計しようってアイディアもあるわけですけど、そういうシステム設計を引く奴というのは大抵 Windows のことしか考えてなくて、もう一回死んでこいよと思うことになるわけで、いや別に C 社さんの実装がそうとかぼくの前職がどうとかは知らないしそういうことではないのですが、さておき、「Windows ならうまくいくんだけど、それ以外の OS の場合はプリンターが元気かどうかをスプールサブシステムが知る手段がないから、なんかの不具合でハンドシェイクが成立しなくなったら終了」なんてことが起きても不思議ではありません。

あと最後にちょっとだけ書いた「細切れのデータをちまちま送り続けられる」というのは、プリンタードライバーなんてものをやってるとときどきぶち当たるイヤな感じのバグで、たとえばユーザーから見ると単純なパターン塗りつぶしなんだけど、なぜかアプリケーションが生成してくるデータは「超巨大なパターンのビットマップをちょこちょこクリッピングしたもの1000個に分割される」とかがあって、これを GS とか Poppler が処理するときに CPU 食いつぶして酷い目にあったりするとか、あるいはプリンターが受け取った巨大なビットマップをメモリに置けなくて死亡するとかですね。特にインクジェットはリソース厳しいからスワップアウトすらできないわけで、メモリに置けないというのは死を意味するです。

Windows の場合は当然こんなタコなデータを吐いてくる奴というのはもうブラリス扱いになってて (Windows 95の頃の花子とか)、ドライバーで抑えこむのがもう定跡化しているのですけど、Linux なんて誰がどんなデータ吐いてくるとかいうノウハウがいまんとこまったく多分なくて、しかも今印刷の中間データ形式を PostScript から PDF に変えてる最中だから中間レイヤーでなにがどうなるとか多分誰も把握できてなくて、そういう問題は起きそうだな、と。

Linux で使うこと前提でプリンターを買うならどれ？

もとベンダーにいた人間からすると、こういうバイヤーズガイド的なことを書くのはあんまり好きじゃないんですけど、その理由はまあ機会があれば書くとして、むしろ「私がプリンターベンダーの動向をみるときにどういうことに着目しているか」を感じてほしいなあと思ってまとめておくことにしました。

ちょっと補足。ソフトの出来うんぬんは、Linux 対応 (HPLIP) だけのことじゃなくて、Web スキャンとか管理画面とか e-Print とかそういうレベルがもう全然違う。事務機器ベンダーの複合機が100万でオプションごってりつけてもことがサラッとできるのがすごい（技術的にすごいというより、企画力とかシステム化とかそういうレベルの話で）。

ただインクの減りが異常に早いのはぼくの B110a という製品がそうなのかなーと思ってたら、どの商品も基本そうみたいですね*2。完全にそういうモデルで考えてる。想像だけど、メカ的な設計寿命とかもあんまり長く見込んでないんじゃないかな？　せいぜい１〜２年。壊れたら買い換えてもらえばいいんだから*3。でもそれが行き過ぎちゃうと「インク買うよりプリンター買うほうが安くていいじゃん」ってなっちゃってあんまエコじゃないのが辛いところ。

ここらへんは私が繰り返し主張している「Linux 対応を謳うならショートサイクルでモノをデリバリーできる仕組みがないとダメ」「Linux 対応を始めるのはカンタンだけど継続は非常に大変」「だから、今このマシンに対応したドライバーがある、使える、ということだけでは判断できない」ってことなんですよね。

最後にサポートの話

正直ベース、今の Linux の市場規模において Linux のドライバーを Windows や OS X のようにサポートするというのはどのベンダーにも無理です。HP だって、日本のサポートに Linux で使ってるって相談したら、「HPLIP プロジェクトにバグレポしてくれ」っていわれたらラッキー、たいていは「は？」といわれて終了かもしれません（推測）。

そんなわけでサポートについても思うところをちょっと書きました。

説明する前にまずは最高の姿をいえば、やっぱり健全なオープン性を持ったプロジェクトで作られるオープンソースソフトウェアであること、だと思います。で、実はその姿に一番近いところにいるのは、実のところ米国 (というか日本以外) における R 社だと思います。そこらへんの話は d:id:naruoga:20120405:1333637462 の繰り返しになるので省略。

そして次善の姿は、プロジェクトにオープン性は乏しいけれども、オープンソースソフトウェアであり、ディストリビューションに取り込まれていることです。これは HP の HPLIP ですね。サポートについては昔は「FAQ 見て、そこで答えが得られなかったらメールしてね」とか割と酷い感じでしたが、今は Launchpad でバグ管理してるみたいなんで、それはよいことです。

まあ、もちろんどのように各社対応するかというのはベンダーのビジネス判断で我々がどうということもできないんですけど、それならベンダー独立な、OpenPrinting とかその上位組織の Linux Foundation がユーザーフォーラムをもってもいいじゃないかってぼくは思うんですけどね。そしたらディストリビューション横断で知恵を出し合えるし、もしかしたら（日本の会社の閉鎖性を考えると難しいかもしれないけど）ベンダー内の技術者やサポートエンジニアが回答をくれるかもしれない。

そういう場を作ろうと思ってさくっと挫折しちゃったんですが（だめじゃん）、誰かがやるぜおー、というならお手伝いしたいと思うので、考えてくれないかなー。

*1:パケットサイズの整数倍のデータを送るときには空パケットを送信するってことになってて、某 USB ドライバーがこの処理バグってていつまでたっても通信完了にならないという不具合を踏んだことがあります。

*2:ここらへん、繰り返すけどぼくはバイヤーズガイドは専門じゃないので話半分でよろしく。

*3:私は専門じゃないから日本の製造業なら普通に考えてメカは10年ぐらいはライフサイクル考えるよね。エレキの部品調達があるから、3年から5年ってのが本当のとこだと思うけど。