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

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

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

OpenPrinting Architecture MLに投稿されたUbuntuのモバイルソリューションにおける印刷をネタに

*nix 環境の印刷標準化技術を議論するワーキンググループである OpenPrinting は、月一で定例ミーティングを行うのですが、そこで Ubuntu のリリースポリシーの変更についてとモバイルに対しての取り組みが議題に上がったようで、「別途サマリを上げます」ということで投稿されていたのがこのメール。

[Printing-architecture] Changes in Ubuntu

前半のリリースポリシー云々な話は Ubuntu にそれなりに関心を持ってて Gihyo.jp さんの Ubuntu Weekly Topics とかを読んでいる方なら耳新しい話はないと思うのですが、当然 Printing Architecture ML にポストされたメールなので、印刷についてもちょっと書いてありました。その部分だけやっつけ翻訳。

Currently, the most important project of Canonical is to bring Ubuntu onto mobile devices, phones and tablets. Last week, on the Mobile World Congress in Barcelona, Canonical announced Ubuntu Touch, the mobile version of Ubuntu, to the public.

現在、Canonical における最重要なプロジェクトは Ubuntu をモバイルデバイス、すなわちスマートフォンタブレットに展開することです。先週、バルセロナの Mobile World Congress において、CanonicalUbuntu のモバイルバージョンである Ubuntu Touch を公式にアナウンスしました。


So everyone is working on getting everything working on mobile, also me as the maintainer of Ubuntu's printing stack is doing the appropriate part. This is the reason why I am working on cups-browsed discovering Bonjour-broadcasted IPP printers with known languages (PWG-Raster/IPP Everywhere, PDF, PostScript, PCL) and setting them up as local CUPS queues fully automatically, without interactive printer setup tool and without printer-model-specific software or date (printer drivers, PPDs) on the local machine. Users should simply get the network printers in the app's print dialogs to just print.

そんなわけでみんなモバイル化が最優先の業務となり、Ubuntu の印刷スタックのメンテナーとしての私も適切な役割を負うことになりました。Bonjour でブロードキャストされた、公開されたプリンター言語 (PWG-Raster/IPP-Everywhere, PDF, PostScript, PCL) をサポートする IPP プリンターを CUPS から見えるようにディスカバリーし、設定ツールの操作も、プリンターモデルごとの専用のソフトウェアやデーター (プリンタードライバーや PPD) のローカルマシンの導入なしで CUPS ローカルキューを完全に自動化するために私が作業していたのはこのためです。ユーザーは単にネットワークからプリンター一覧を得て、アプリケーションのプリントダイアログで選んで「印刷」ボタンを押すだけで済むようになるべきです。


In addition, I am splitting up the printing-related Ubuntu packages so that the big printing stack with tons of printer drivers, PPDs, and printer setup tools can be replaced by a light-weight one for mobile devices.

加えて、Ubuntu の印刷関連パッケージを分離しているところです。印刷スタックは大量のプリンタードライバーと、PPD と、印刷設定ツールからなっており、これはモバイルデバイス向けの軽量なものに置き換えられるはずです。


The RIP on mobile will be Poppler, as Poppler is already there for the PDF viewer, mobile apps will never send PostScript jobs, color management is not yet implemented on mobile, and the PostScript generated for PostScript printers from Poppler is much better than the one from Ghostscript (in terms of compatibility with buggy PS printers).

モバイル環境における RIP (訳注:Raster Image Processor つまり描画処理を行うところ) は Poppler になるでしょう。Poppler はすでに PDF ビューアーとして使われていますし、モバイルアプリケーションは PostScript のジョブを生成することはないでしょうし、カラーマネジメントはモバイルではまだ実装されていません。そして PostScript プリンター向けに Poppler が生成する PostScript は Ghostscript よりずっとよいのです (GS はバグを持った PS プリンターとの互換性を持たなければいけないので)。


About all this I have talked in my UDS session today. See
http://summit.ubuntu.com/uds-1303/meeting/21685/client-1303-printing-stack-with-mobile-in-mind/
There is a recording (video) and a write-up.

以上、今日の UDS セッションで話したことでした。
http://summit.ubuntu.com/uds-1303/meeting/21685/client-1303-printing-stack-with-mobile-in-mind/
に録画 (ビデオ) とまとめがあります。


See also the Ubuntu Blueprint related to the session:
https://blueprints.launchpad.net/ubuntu/+spec/client-1303-printing-stack-with-mobile-in-mind

このセッションに関連する Ubuntu Blueprint は以下のとおりです。
https://blueprints.launchpad.net/ubuntu/+spec/client-1303-printing-stack-with-mobile-in-mind

面白かったのは Red Hat のデスクトップチームで colord の開発者である Richard Hughes が「Poppler のカラーマネージメントは Canonical がやるって理解でいいのかい?」って突っ込んでて、それに対して Till が「うーん、Canonical には色の専門家がいるわけじゃないし、Poppler にも今カラーマッチングのパッチがいくつか提案されてるけど、Poppler のメンバーにもカラーマネジメントがわかる奴がいなくてレビューできてないんだ。手伝ってくれるとうれしいんだけどな」って返してたとこでした。

想像通りだったかどうか?

んー、思った以上に当たり前というか真面目に考えてますね。正直、「印刷なんか俺らのユースケースじゃ考えないよ、知らないよ」ってなっても不思議ではないから。ただもちろん UDS で Till だけがやりたがってるという可能性は否定しないので、詳しくはまだちゃんと見てない UDS のページを見たり、Blueprint*1 を継続的にチェックしていくことになるでしょう。

想像通りだった部分としては、基本 IPP Everywhere、つまり:

  • Bonjour によるデバイスディスカバリー
  • IPP 2.0 によるドライバーレス印刷、つまり
    • プリンター情報の取得
    • 標準化された Semantic Model による Job Ticketing
    • 印刷と結果確認
  • プリンターのサポート言語を限定しドライバーレス印刷を目指す

ということで、ただ IPP Everywhere だとディスカバリーBonjour だけ、印刷データ形式は PDF と PWG-Raster だけなのでそれじゃ辛いから、CUPS ブラウジング (UDP: 631 のスキャン) も対応した上で、言語も PS と PCL を追加するという感じ。まあ現実解といえば最大限の現実解、だと思います。

で、我々はその恩恵を受けられるの?

ただ、インクジェットや、価格帯にして1万円から3万円(カラーならもう一息)ぐらいのレーザープリンターのように、いわゆるコントローラーボードという部分にお金がかけられなくて自分でプリンター言語を解釈できないプリンターの場合、どないすんねんということになります。

新しいプリンターであれば、Apple AirPrintと同じやりかたが使えるでしょう。つまり、プリンターがネットワークとつながることを前提にしてしまって、コントローラ側は受け取ったPDFをネット上のPDFレンダリングサービスに投げ、その結果としてビットマップ情報を受け取って印刷するという仕組みです。HPさんやBrotherさんはたしかこのやり方をやってるはず。

もちろん、PWG Rasterという、IPP Everywhereで定義されたビットマップデータ形式を利用する方法もありますけど、まあどちらにしろ、「IPP Everywhere対応のプリンター」が増えてくることは一つの条件になります。

ということで問題はIPP Everywhereは本当に普及するのか? というところになります。「iOSから印刷できる!」はカタログスペックで売りになりますが、「標準のモバイル印刷技術に対応!」では売りにならないからです。Ubuntu Touchがある程度の市場規模を確保すれば同様の効果は期待できますが、どうなんでしょうね。

「え、さっきあんた IPP Everywhere 以外にも使えるように工夫してるって書いてなかったか」って? そうですね。なので、彼らは頑張って CUPS 1.6 ではドロップされた CUPS Browsing のサポートを復活させ、PS および PCL のレンダラーを載せるつもりなのでしょう。
が、PS または PCL が乗っている日本市場で買えるプリンターって、皆さんかぞえ上げることできますか? 実はないこともないんですが、ほとんど無理ですよね。PS オプションとかだいたいクソ高いのが普通です。

はっきりいって、この問題困るの日本だけなんです。日本のベンダーだけが、PS または PCL が載ってないのに数十万もするプリンターを売って商売してるんです。しかも彼らも、海外市場ではやはり PS や PCL が乗ったプリンターを売っています。それはそうだ、ビジネスですから。
残念ながら、Till の努力は日本市場における Ubuntu Touch のプリンターサポート拡充にはあまり繋がらないというのは厳然たる事実です。

ではどうする?

えーと Blueprint をチラ見した感じだと言及してありましたが、一番簡単な方法は、一台 Linux マシンを用意して踏み台にすることです。CUPS 印刷システムは IPP 2.0 しゃべれますし、PS も PDF も受けられます。Avahi 立てておけば IPP 2.0 的には立派な印刷サービスですから、プリンターと区別がつきません*2

しかし残念ながら国内市場のプリンターだと、そもそも ARM のビルドがなかったりするので、Raspberry PiみたいなARM省電力小型PCだと使えませんね。しょぼん。ARMのビルドがあるプリンタードライバーってHPLIPとGutenprintぐらい? まあ、余ってる x86 なマシンを使うのが現実的なんですかねえ。

Just Ideaですけど、ARM ベースのソリューションだとすると、知らん顔して受け取っておいて、バックエンドでネットの向こう側にぽいっと投げる。んでネットの向こう側で処理して、結果を受け取ってそれをループバックで自分のキューに押し込んで印刷、なんてやりかたはあるかもしれませんねえ。なんか、ちょっとプログラミングできる人ならささっと作れそうなんで、誰か作りません? え、私? うーん、誰もやらんのなら検討してみてもいいかも。

ところで、そもそもモバイルから印刷したい?

これ私自身がとっても不思議なんです。モバイルから印刷したいってユースケースって、いったいどんなのなのだろう?

伝統的な印刷シナリオは、ローカルに作ったデーターを、ローカルに接続された (有線か無線か、ネットか直接続かはおいとくとして、少なくともプリントキュートして固定されている) プリンターに打つ、というものだった。これは非常にわかりやすい。

一方で、モバイルから印刷したいものって何? PictBridge と同じレベルならわからんでもないですが、それ以外は?
iPad + KeyNote は割とよくできているので*3、もしかしたら「KeyNote で作成したスライドをお客さんの所に持っていくため印刷する」というシナリオはあるかもしれません。うーん、でもそんぐらいしか思いつかない。

ので Ubuntu Touch の印刷を頑張るというのは、もちろんカタログスペックとしてマルを付ける行為として意味はあるんですけど、それで例えば自分が Ubuntu Touch 使ってて印刷したいかというと疑問だな、というのが正直なところ。

モバイルを窓としてクラウドから印刷?

私がありそうだな、とおもっているのはこのシナリオ。いろんなサービスがクラウドの向こう側にいってしまい、モバイルは結局クラウドの一部を切り取って「窓」から覗いているというイメージが私にはあります。

ならば、「今窓から覗いているこの文書、もっと多くの人と同時に見たいし、高い解像度で大きく見たいから印刷したい」というのはあるのではないかな、ということです。

で、ここで「それもうあるじゃん」と思ったあなたは鋭い。そう、Google Cloud Print です。
リンクめんどくさいから省略。Google のアプリ、つまり Google ドライブGmail なんかから直接、予め登録したプリンターに投げ込む仕組みです。

でも実のところ私は GCP はあんまり気に入っていません。いや、ないよりはあったほうがいい。けど、やっぱり自分の思ったようなののではない。
というのは、さっき書いた「予め登録したプリンター」というところです。

例えばですよ、私が東京と名古屋と大阪と福岡に拠点があるそこそこ大きな会社の営業かなんかやってたとします。
あのお客さん向けの提案書も、このお客さんの見積書も、なんとかという商品の説明資料も、全部クラウドにおいてあって、それを新幹線の中でタッチアップしたり、なんだかんだってやるわけです。
で、じゃあ印刷しようかってなったときに、まあ普通、オフィスの各フロアに一個ぐらいプリンターありますよね。多いところだと、複合機がフロアーに一個あって、プリンター単体機が島ごととか、そういう数であっても不思議でない。会議中に印刷したいなって思ったときのために、会議室近くにプリンターが用意されてる会社さんもあるでしょう。東京と名古屋と大阪と福岡に拠点があるってことは、それぞれの拠点に自分が使えるプリンターがあるはず。仮にワンフロア10台とすると拠点ごとに40台、ですねえ……。
で、そういう「自分が使う可能性があるプリンター」を、全部予め登録しておいて、使えるように設定して、いざ印刷するとき、自分の近くにあるプリンターはこれ……って間違いなく選んで、印刷するの? 正気?

データーがクラウドの向こうにあってどこででも見られるし触れるのに、印刷するとなると、自分がどこのプリンターを使うか、手で選ばなきゃいけない。しかもそれは「予めの登録」が必要で、「あ、ここにプリンターがあるならこれ使いたい」ってできない。

正直、ありえなくないですか? 私は許しがたいと思います。
だって自分が今どこにいるかなんて知る手段いっぱいあるわけですよ。GPS だってあるし、どのネットワークにぶら下がってるかもわかる。なんで「あなたの今使えるプリンターはこれです」っていえないの? 意味不明です。

つかさっきも書いたとおり、モバイルプリントならデバイスディスカバリーで「予め登録しないで」サービスを列挙できるわけです。だったら、クラウドで管理してるデータをモバイルで触ってるなら、モバイルでプリンターを指定して印刷したい、それが自然な流れですよね。そこに分断が生じているのが、私としてはとても納得がいかないわけで。

多分ですけど、Google 側の考えとしては、「俺達はプリントキューを定義して登録さえしてくれればそこに印刷するわけで、プリントキューがリアルなプリンターに紐付いてる必要はなくない? プリントキューを工夫して作れば良くない?」というところにあるのかもしれません。
例えば、セブンイレブン富士ゼロックスの「ネットプリント」というサービスがあります。あれに投げ込める仮想プリンターというのを作って、それを GCP に登録しておけば、GCP で印刷した結果は日本中のセブンイレブンで取り出せるわけです。こういう手法をロケーションフリー印刷っていうんですけど、企業内ロケフリサービスは事務機器ベンダーなら大抵提供しています。問題はそれがWindowsベースだったり、ADにロックインされてたりすることなんですけどね。

話がそれた。モバイルの話でした。ということで、Ubuntu Touchもおんなじことで、GCP とつないでいくなら GCP の仮想プリンターとして登録可能な仮想キューを予め生成しておき、それと、リアルタイムでディスカバリーしたプリンターをその場でがちゃこんとつなぐことで、ソリューションが提供できたら面白いだろうなって思ってます。

で、実は Google Cloud Print は次のステージに向けて、PWG の Cloud Imaging Working Group で標準化が進んでいます。もしかしたらこういうことも考えているのかもしれないけど、今んとこセマンティックモデルの定義をしこしこしてる感じなので、ちょっと実務的な姿が見えてくるのは先かなあと思ってます。まあのんびり見てましょう。

そもそもプリンターベンダーはプリンターのコモディティ化を望むのか?

という話を書こうと思ったけど、長くなるので略。答えは「望まないに決まってるじゃねーか」「でもそれなくして標準化はあり得ない」「じゃあロックインなしでコストで殴り合いすることなしにお金を儲けるビジネスモデルを提案しないと、みんな標準化なんてやりたがらないよ」に決まってるんですがね。その答えがわかるほど頭が良かったら、ベンダーに売り込んでコンサル料せしめてますってば。

結論:Ubuntu Touch の印刷ってどうよ?

  • まだ「こんなふうにしたいなー」って Till が妄想してるレベルだと私は認識してるのですが、妄想としては筋がいいです。
  • けど、このままだと日本市場はほぼ確実に置いてけぼりになります。
  • 自分の身を守るためとしたら Linux Box を一個立てるのが現実的かなー
  • モバイルとクラウドの組み合わせこそが本当に面白いとぼくは思ってるんだけど、そこちゃんと議論してる人があんまいないのはなんでだろう
  • 本文中には書かなかったけど、クラウドと印刷を組み合わせるとコンテンツ変換がクラウドの向こうに行くので夢が膨らみますな

まあそんな感じ。
対して面白くないのに長くなっちゃってすんません。

*1:関係ないけどSubscriberにUJTの村田さんがおりましたな。

*2:Bonjour はデバイスディスカバリーではなくサービスディスカバリーであって、印刷を提供しているプリンターと、印刷ジョブを受け付けてプリンターに投げ込むPCと差はありません。

*3:Android 陣営はここでは明らかに劣っているので、Impress を移植するとかいう方法ではなく、ODF を使ったタブレット向けスライド作成ソフトって展開があるといいかもしれないなあと思ったりしてます。