OpenPrinting Summit/PWG Meeting Cupertino 2013参加レポート

昨年に引き続き、OpenPrinting Summit/PWG Meeting Cupertino 2013に参加して来ました。

序文

会場はApple本社

今年もみなさまご存知のシリコンバレーはCupertinoのApple本社であるInfinite Loop Oneの、道を挟んで隣にあるDe Anza Threeというキャンパスの会議室で、2013年5月14日～5月17日の4日間に渡って行われました。

前回と同じく、今回もまた、印刷に関係する2つの標準化団体の合同ミーティングという形です。

OpenPrintingとPWG（Printer Working Group）

OpenPrintingはLinuxの普及、保護、標準化を進める非営利団体Linux Foundationの下部組織で、おもにLinuxなどのUnix系OSからの印刷の標準化を行なっています。たとえばPDF印刷パスやベクター印刷プロトコルOPVP、最近だとモバイル関係の印刷プラットフォームの構築などがOpenPrintingの活動です。なお、OpenPrintingには日本のサブチーム (OpenPrinting Japan) があって、筆者はそこのメンバーでもあります。

PWG（Printer Working Group）はIEEEの標準化部会の1つで、プリンタや複合機について、プリンタベンダーやOSベンダー向けの標準化を行なっています。たとえばCUPSがおもに用いているIPP（Internet Printing Protocol）が馴染み深いのではないでしょうか。なおPWGの議長は、CUPSの開発者であるMichael Sweet氏です。

両者それぞれに電話会議やFace to Face Meetingを行っているのですが、昨年「年に1回は一緒にやったほうがいい」ということで合同でやったところ、普段片方の議論にしか出ていないメンバーが外部の目からコメントをするため、非常に良いミーティングになりました。そこで、今年も同じスタイルで行うことになったとのことです。来年も多分同じ時期に同じApple本社でミーティングが行われる予定だそうです。

本レポートについて

なお本レポートはあくまでも一参加者である筆者が議論を聞きとって書いたものであり、PWGやOpenPrintingの意見を代表するものではありません。とくに、筆者はOpenPrinting側の人間であり、PWGのトピックについてはあまり事前知識がないので、その点あらかじめご容赦ください。

以下、すべてのセッションを紹介することをせず、時系列にもあえてこだわらないで、筆者がとくに興味を持ったものを紹介したいと思います。すべてのプログラムと資料はPWGによるミーティングの公式Webページにありますので、詳細が気になる方はぜひご覧ください。

前提：なぜ今印刷なのか？

印刷について語るたびに、以下のような声を耳にします。

「印刷なんてレガシーな技術でつまらない」
「どうせ印刷なんて収束していく技術だ」
「プリンタベンダーとOSベンダーにまかせておけばいいだろう」

たしかに、オフィス文書の印刷、たとえば会議資料を人数分印刷して、会議が終わったらゴミ箱行きというようなユースケースは確実に減少します。実際、今回の会議においても、印刷関係の会議にも関わらず紙資料の配布は一度も行われませんでした[1]⁠。図1はこのような印刷シナリオを図示したものです。

しかし、これは筆者が繰り返し主張していることですが、「⁠印刷技術はプリンタベンダーとOS屋にまかせておけばいい」という牧歌的時代はもうすでに終わろうとしています。逆に、そういう牧歌的な印刷については標準化活動としては地道な作業（と政治的な話）しか残っておらず、今のホットトピックではありません。

では一般の技術者は印刷に無関心でいいのでしょうか？　いいえ。それは違います。

たとえば筆者の本業はSIerでありますが、とあるシステムで印刷機能を提供しているとします。今まではサーバは顧客のネットワーク内に置かれ、プリンタも同一ネットワーク上に存在しているのが普通でしたから、PDFを生成してOSに印刷ジョブとして投げるような構成を作るのはさほど難しくありません。

しかし、そういうサービスが顧客の要望（たとえば災害時対応など）でクラウドに移動したとき、依然としてプリンタは顧客の閉鎖的ネットワーク内にあるわけです。そういうときにどうすればいいのか？　サービスベンダーは、クラウドベンダーやプリンタベンダーが提供するサービスを適切に呼び出してサービスを構築しなければなりません。ところで、適切かどうかは誰がどう決めているのでしょうか？　それにはシステムベンダーの意向は反映されているのでしょうか？

また逆にすでにWebベース、クラウドに存在するアプリケーションにおいても、紙に出すことでサービスが広がることは必ずあるはずです[2]⁠。そしてWebにはWeb、モバイルにはモバイルの適切なUIがあり適切なコンテンツの見せ方があるように（いわゆるレスポンシブデザインですね⁠）⁠、紙には紙に最適なコンテンツの出し方があるはずです。そしてそれはコンテンツホルダーであるエンドユーザとサービス事業者にしかわからないことで、プリンタベンダーはただ「材料を提供する」ことしかできません。

さて、必要な材料をプリンターベンダーが提供しているかどうか、誰がチェックしているのでしょうか？

したがって、標準化動向をウォッチし、ときには議論に参加することが、システムベンダーやサービスベンダーには求められていると思っています。この記事は「どういう技術に注目したらいいのか」のガイドとなりたいと思って執筆しておりますので、1人でも多くの方が印刷標準化活動に目を向けていただけると嬉しいです。

OpenPrinting関係のセッション

先にも書いたとおり、どちらかというと「⁠（⁠オープンな）ホスト側からプリンタを眺めた」標準化活動を行うのがOpenPrintingです。同じエンドユーザコンピューティングということで、モバイルデバイスで動くプリントサービス的なものもOpenPrintingの範疇になります。

今回一番の驚きは、OpenPrintingのマネージャーでありCanonicalの印刷関係のメンバーでもあるTill Kamppeter氏が入国でトラブって会場に来られなかったとのことです[3]⁠。ということで彼は電話会議＋WebExでのリモート参加ということになりました。

OpenPrinting Plenary

Plenaryという単語は本会議とかそういう意味ですが、内容からすると「年次総括」的なものでしょうか。OpenPrinting PlenaryはOpenPrintingの現在の活動内容と今後の課題などを総括するものです。同ミーティングはいつもOpenPrinting、CUPS、PWGのPlenaryから始まります。

昨年のOpenPrintingの活動としては、かなり古いニュースですが[4]⁠、「⁠Linux上のすべてのアプリケーション、多くのデスクトップ環境に共通の印刷ダイアログを提供する」という試みであったCommon Printing Dialog（以下CPD）の開発休止が大きく話題になりました。

OpenPrintingの難点の1つはその貧弱なマンパワーにあります。フルタイムワーカーが少ないだけでなく、OpenPrintingのためにボランタリーにコードを書く参加企業もまた少ないのです。そのため多くの実装はGoogle Summer of Code（以下GSoC）に拠っているという現状があります。しかしCPDはGSoC一期でやりきるにはあまりにも野心的なプロジェクトだったため、OpenPrintingとしてはフリーなデスクトップの採用に力を入れているドイツ政府と、Ubuntuのホスト企業であるCanonical社両方から寄付を引き出してフルタイムワーカーを雇うべく活動していたのですが、結果的にはうまく行かなかったということです。

しかしこれは単純に金銭面の話ではなく、デスクトップ印刷の意味付けの変容ということになります。CPDが始まった7年前、最も一般的な印刷シナリオは、先に述べた「牧歌的な」ものでした。つまり、デスクトップ環境からアプリケーションを通して文書を開いて印刷する。印刷する先はあらかじめ登録してあり、印刷システムは当該のプリンタの情報をすべて持っていて、アプリケーションはそれを参照できる。技術的にはCUPSの管理するPPDの情報を利用する、という形です。CPDはUIの構築にPPDを積極的に利用して（スキーマも拡張して⁠）⁠、より良いユーザ体験を提供しようとしていました。

時代は移り現在になると、そもそもデスクトップがユーザの利用する一番のコンピューティング環境ではなくなってきました。スマートフォンやタブレットに触れている時間がPCよりもはるかに長いというユーザも少なくありません。そうなると、「⁠印刷先をあらかじめ登録しておきPPDをそれぞれ用意しておく」というシナリオは必ずしも最良とはいえず、「⁠そのとき使いたい印刷先の情報を取ってきて動的にUIを生成する」シナリオに対する考慮が必須となってきます。またCPDはスマートフォンなどの画面ピクセル数が小さいデバイスへの考慮がありません。CPDがドロップされたのは、悲観的に捉えるべきではなく、その知見やリソースを有効に活用して、現在のデスクトップ印刷システムをより良くしつつ、モバイルやクラウドを踏まえた新たな印刷環境に軸足をシフトするという意思の現れだと考えたいです。

またEPSON AmericaのGlen Petrie氏による、モバイル用の共通印刷クライアントを目指したCommon Mobile Print Client（CMPC）は試作ベースのまま開発休止となりました。ただし、試作版のソースコードやドキュメントはすべて開示され、今後のモバイル印刷ソリューションの議論の元となることになっています。詳しくは後述します。

CUPS Plenary

PWGの議長であるMichael Sweet氏はCUPSのメイン開発者でもあります。CUPSはOpenPrintingにおいて非常に重要なモジュールであり、1.6においてApple社が利用しない部分（おもにバックエンドやフィルター周り）が切り離されてOpenPrintingに移管されるなどして[5]⁠、CUPSコアとそれ以外という構造が明確になったというところがあります。なお立ち話で聞いた限りではApple社内のCUPSのメンテナーは4人ぐらいで、あと外部のコミッターが少々、という感じだそうです。

最初にあった、技術的ではないけれども重要なトピックとしては、Sweet氏がAppleに雇用される以前から利用されてきたCUPSのWebサイトが物理的に飛んだためにあらゆるサービスがストップし、今は暫定的にApple社内にサーバを立ててWebサーバの機能だけホスティングしているとのことです。SVNリポジトリやフォーラム、MLのサービスは、やはりApple社内にサーバを確保して順次復旧する予定とのことでした。

さてCUPS 1.7についてですが、実は今回のイベント前にβ1が出ていました。例によってリリーススケジュールは明確にはされませんでした[6]が、コミュニティ向けのリリースは夏から秋にかけてのことになるでしょう。機能面については、以下ということです。

課金印刷（paid printing⁠）⁠／印刷量制限（quota）の実験的サポート
- OS側の機能拡張要
- IPPのPaid Printing Extensionsの実験実装
IPP経由の印刷における自動データ圧縮機能追加
その他種々のIPP関係のプリンター設定・管理系APIの追加
各種APIの紛らわしい仕様の整理その他

課金印刷というのは、たとえばコンビニでの印刷などがわかりやすい例です。1枚印刷するたびにコインボックスにいくら入れる、という方法です。またおもに大学などはプリペイドカードによる印刷課金を行なっているところが多いでしょうし、企業の場合、印刷時に従業員のIDカードをかざすなどして部門と紐付けし、部門に支払い請求を行うというようなソリューションもあります。

従来、こういったソリューションは各プリンタベンダーでそれぞれに実現していました。これは、課金関係の情報というのがなかなか複雑で、細かい部分がベンダーによって異なっていたからという理由が大きいと思われます。IPPのPaid Printing Extensionはこういったベンダー依存の部分をExtensionとしてベンダー間の差異を共通化しているものと考えられます。課金管理をマルチベンダーで行えるというのはソフトウェアベンダーとしてはかなりおもしろいビジネスの種ですので、まずはリファレンス実装的に出てくる次期OS Xの仕様がどのようになるか期待するところです[7]⁠。

また筆者が「IPPについては不勉強なのだけれども、IPPで取ってきたスキーマの文字列は英語なのか？　ローカライズの責務は誰が持つのか？」と質問したところ、そこのところの議論が不十分であることは承知しており、ローカライズが重要な場合はPPDベースの印刷システムがしばらくは使われ続けるだろうとのことでした[8]⁠。

あとは将来のCUPSという話でいろいろ夢のある話があり、大体は「今はOS X側でやっていることをLinuxでも実現したい」ということですが、大雑把にまとめると、以下といったところでしょうか。

ユビキタスコンピューティングへの歩み寄り
より省電力に、より高パフォーマンスに
OSと協調してネットワーク環境の変更に自動的に追随
よりハイレベルなデバイスディスカバリー
クラウド印刷への第一歩（IPPSIX）

OS Xのプランとの兼ね合いもあるでしょうが、CUPSには今後ともLinuxデスクトップ印刷の要として、そしてある程度はモバイルやクラウドでのプレイヤーとして活躍して欲しいところです。その点、Sweet氏の「CUPSは印刷ソリューションを開発しているわけではない（あくまでも部品である⁠）⁠」という言葉が印象的でした。

CUPS filters

前述のとおり、CUPSのフィルター・バックエンド群のうち、OS Xで利用されていない多くのものがApple社からOpenPrintingに移管されたものたちです。非常に大雑把にいうと、以下のようになります。最後のcups-browsedについては次のテーマで説明します。

レガシーデバイスであるシリアル・パラレルバックエンドはほぼそのまま残す
PostScriptを印刷中間データとするフィルター群は廃止され、PDFが印刷中間データとなる。利用しているミドルウェアはPoppler
HP社のPCLなどのデバイス向けにGhostScriptも利用している
CUPS 1.6でオミットされたレガシーデバイスのディスカバリーのためにcups-browsedというデーモンを追加

Printing in Mobile Mind

今OpenPrintingでホットなのがモバイル印刷についてです。もちろんこれはOpenPrintingのマネージャーであるTill Kamppeter氏がCanonical社の社員であり、Canonical社が今Ubuntu Touchという新たなモバイルソリューションを展開しようとしている活動の一環です。しかし、1つのモバイルソリューションのための印刷スタックの議論を標準化活動の場で行い、それが他のLinuxベースのモバイル環境について展開されるとしたら、それは良いことだと思います。

しかし実のところ筆者はモバイルからの印刷という機能が提供する「嬉しさ」がよくわかっていないところがあります。完成度が高いモバイル印刷を提供しているといえばiOSです[9]が、ではたとえばiPhoneから印刷したいものにはなにがあるかというと、筆者はあまり思いつきません。強いていえば懐かしのPictBridge的な使い方でしょうか。一方で、iPadぐらいの大きさになると、KeyNoteでスライド作ってそのままプレゼン、というところでオフィスアプリっぽい使い方も出てきますが、そうするとモバイル特有の問題意識であるリソースの制約とか電力消費量とか画面の狭さといったことについては考慮すべきことが減ってしまいます。これら2つを同時に議論するのが良いのかどうなのかということも含め、技術論の前にまずはユースケースとシナリオの議論が必要ではないかと筆者は考えるのですが、今回はそこまで議論できませんでした[10]⁠。

さて、Ubuntu Touchで出してきた技術的な提案は、以下になります。

現状の印刷スタックを3段階ぐらいに細分化し、リソースによって使い分ける
最もリソースが小さいソリューションではCUPSサーバを踏み台にしてジョブを投げるだけに限定
ミディアムレンジのモバイルソリューションではIPP Everywhereを基本とし、PCL、PSを加える。レンダリングエンジンとしてはGhostscript＋Popplerだが、MuPDFも候補に
ブラウジングにはcups-browsedを用いる
印刷UIはIPP経由で取得したプリンタの諸元を用いて動的に生成

cups-browsedについてはピンとこない人も多いでしょうから簡単に説明しましょう。平たく言うと「CUPS 1.6で機能的に落とされた、あるいはAPIが変更になったネットワークプリンタのブラウジング方法を、過去と同じにするためのデーモン」です。CUPS 1.6は印刷サービスディスカバリーの方式をBonjourに一本化したうえ、ユーザが目にする（デスクトップ環境上で利用される）APIをBonjourに合わせて最適化したため、Linux環境下ではすべてのデスクトップ環境が足並みそろえて変更しなければいけなくなりました。これはディストリビューターにとっては現実的ではないですし、そもそも機能的にも、Bonjour未対応なプリンタは世の中にたくさんあります。そこでOpenPrintingは「今までCUPSが行なっていたブラウジングサービスを行う」専門のデーモンを開発することにしました。それがcups-browsedです[11]⁠。

しかし、CUPS 1.6で既存のブラウジング機能を落としたのは、そもそもがモバイル環境などでWi-Fiを通じてディスカバリーを繰り返すと電力消費量が大きくなるという理由であって、CUPS開発者のMichael Sweet氏は「この方法は暫定策としてはうまく行くけれども、根本的な問題を解決していない」ということでcups-browsedに対しては否定的です。

実際のところ、Ubuntuが提供しようとしている新たなモバイル用プラットフォームであるUbuntu Touchでは、印刷スタックについては完全に作り直すわけではなく、機能を限定したり使っているモジュールを入れ替えたりすることで軽量化やCPU負荷の軽減、省電力などを目指しています。それを考えると現状のcups-browsedをそのままモバイルに持っていくのは筋が悪いのは確かで、ここのところは現在Printing-Architecture MLで議論されて行くでしょう。

なおモバイルにおいては、スプーラー機能を持たない、セッション指向（常駐せずに、印刷開始時に起動され、印刷終了とともにプロセスが落ちる）ような、ダイレクトプリントに特化した印刷サブシステムが必要という認識は各自が持っています。Ubuntuは現状のCUPSのモジュールを部分的に利用することでそういう印刷スタックを作るという一種の現実路線なわけですが、昨年のOpenPrinting Summitで提案されたRed Hat社のTim Waugh氏によるprinterdはダイレクト印刷時代の新たな印刷スタックを作ろうという提案の1つで、Printing-Architecture MLで「事情があって止まっていたけれどもセッションベースの印刷システムはやるつもりだ」と、このやりとりの中でコメントしていました。Michael Sweet氏も「CUPS自体がそういう風になることももちろん検討している」と言っています。

また印刷UIについては、ご存知のとおりUbuntu TouchはQtベースであり、OpenPrintingとしてすでに試作レベルにあったCommon Mobile Print Clientの知見やコードが利用できそうということで、こちらを参照しながらUbuntu側で議論することになったようです。またiOSの印刷ダイアログはパラメータとしてドキュメントタイプを渡すことで表示するUIをいくつかのバリエーションで切り替えられるのだそうで、そういったポリシーも参考にしてはどうかという意見もありました。

それからMuPDFについては別のプレゼンでArtifex社のMichael Vrhel氏から紹介がありましたが、Ghostscriptで有名なArtifex社による非常に軽量なPDFレンダリングエンジンです。FreeDOSで動くほどの軽量さはモバイルにおいては非常に魅力的です。しかしArtifex社の開発体制はお世辞にもオープンとはいえないこと、CJK方面で実績がまだまだ足りず簡単なテストでバグがいくつか見つかっていること、カラーマッチングのサポート予定がないこと、などがあり、今後さまざまな検討が行われるでしょう。特にCJKについては積極的にテストしてバグレポートしていく必要があると感じます。

GTK+ Print Dialog／GNOME3 Printer Settings

UbuntuやFedoraのユーザが日常的に使っている多くのGNOMEアプリ、たとえば「テキストエディタ（gedit⁠）⁠」などが採用している標準の印刷ダイアログはGTK+で提供されています。こちらについて、GNOME 3.8からの拡張と、開発中止になったCPDからの機能の取り込みについて、OpenPrintingのTill Kamppeter氏、それに開発者のMarek Kasik氏によるリモートプレゼンがありました。

とはいえ3.8からの変更は内部的なことが多く、具体的にはCUPSのIPP系の新しいAPIを積極的に使うようになったとか、Avahiのライブラリを用いてDNS-SDでのデバイスディスカバリーをサポートするようになったと言った話がほとんどです。ただし、IPPではプリンタの設定項目についての情報は完全には取れないため、PPDの情報も併用しています。またN-UPなどのページ加工やファイルへの出力機能はCUPSの機能ではなく独自に実装しているとのことでした。

CPDから取り込む予定の機能としては、目立つところではリアルプレビューがあります。アプリケーションから実際に印刷する画像データを受け取って、さまざまなオプションを適用した結果をプレビューできるというものです。また現在のGTK+ Print Dialogは名前のとおりGTKの一部として組み込まれており、たとえばQtアプリから呼ぶことはできません。このインターフェースをD-BUS化することも計画としてはあるそうです。ここまでくると「CPDの置き換え」という感じがかなりしてきますね。

詳細は割愛しますが、このダイアログについてはかなり活発な議論が行われました。やはり現実的に見える議論は盛り上がりますね。

なお、LibreOfficeのLinux版も独自UIを捨ててこのダイアログに乗り換えるという話を聞いたのですが、詳しい情報はありません。今のLibreOfficeの印刷ダイアログは問題を抱えているので、もしそれが事実ならとても良いことだと思います。

またGNOME3から印刷に限らず設定画面が一新され、それに伴って印刷設定画面も新しくなったことは皆さまご存じかと思います。これがGNOME3印刷設定です[12]⁠。GNOME3の、ユーザに見せる設定項目を大胆にそぎ落としてシンプルにするというポリシーを受け、GNOME3印刷設定も設定可能な項目が大幅に減ったのですが、おかげでデフォルトの印刷オプションの設定や、プリンタ共有やサーバサイドの設定についても消えてしまいました。おかげでFedoraもsystem-config-printer（SCP）と併用せざるを得なくなり、これは「やりすぎ」ということで復活することになりました。その他SCPで計画されていた機能拡張（たとえばSambaサーバでプリンタを共有しておいてPPDを登録しておくと、キューの追加とともにPPDを引いてくる機能など）も加える検討をしているということで、これで安心してGNOME3印刷設定に移行できるようになるでしょう。なお以前聞いた話ではSCPもGNOME以外のプラットフォームで広く使われているので開発は停止しないとのことでしたが。

カラーマッチングあれこれ

カラーマッチングとはすごく乱暴に言えば「機器の特性の違いを吸収して、どういう経路で入手したどのデータでも入力出力問わず色味を同じにする」技術です。機器の特性その他をデータ化したものを「プロファイル」と呼び、いくつかフォーマットがあるなかで、International Color Consortium（ICC）の提案したフォーマットが広く使われておりICCプロファイルと呼ばれます。

Linuxのカラーマッチングはここ近年で急速に改善して来ました。進化の立役者の一つはRed Hat社のRichard Hughes氏がメインで開発したcolordと、その関連ツールであるGNOME Colorでしょう。非常にシンプルに言えばcolordは「デバイスとICCプロファイルのヒモ付を管理し、各種ミドルウェアの問い合わせに答えて返すデーモン」で、GNOME Colorは「そのヒモ付を定義するためのユーザアプリ」です。今回はHughes氏によるリモートプレゼンがあり、colordにおける残件として、とくにPDFのOutput Intentに指定されたICCプロファイルをどうするかという話が議論になりました。

PDFにはOutput Intentという一種の拡張領域があって、そこにICC Profileを埋め込むということは「色味合わせは自分で（PDFを生成するときアプリ側で）ちゃんとやって、プロファイルを付けているから、システム側の指定は無視してくれ」と言う意味になります。したがってcolordは「Output IntentにICCプロファイルが埋まっている場合は、ミドルウェアからの問い合わせに答えない」という実装になっています。

しかしながら、ユーザの操作ミスその他の要因で、Output IntentにICCプロファイルが埋まったPDFデータが外部に流出することがあります。この場合は逆に、印刷するシステム側の情報を採用し、Output Intentの情報は破棄したいわけです。これをGTK+ Print Dialogに追加するとして、各ミドルウェアはどうハンドルすればよいのか。

この点、Ghostscriptの開発者であるArtifex社のMichael Vrhel氏は「GSなら渡されたプロファイルと埋め込まれたプロファイルをそれぞれどう扱うかスイッチがあるのでそれを適切に指定すれば良い」とコメントし、IPPの仕様策定者の立場としてのMichael Sweet氏も「IPP Everywhereはドライバレス印刷なので同じ問題があるため、どちらを優先するかのスキーマを定義した。CUPSからIPPを使う場合はそれを利用すれば良い」とコメントしていました。OpenPrintingのcups-filtersで利用されているPDFライブラリであるPopplerについては関係者がいなかったので、自由でオープンなソフトウェアにおけるICCプロファイルの利用について話し合うOpenICCのMLで、Poppler開発者とHughes氏が話し合うこととなりました。

つづいてMichael Vrhel氏によるGhostscript（とMuPDF）についてのプレゼンがあり、Ghostscriptについては新機能を概観したあとカラーマッチングの詳細についてかなり深い説明がありました。RGB、CMYK、GrayscaleなどによってそれぞれICCプロファイルを定義できるところはさすがGhostscriptと言ったところですが、やや専門的に過ぎるので割愛します。ご興味がある方はVrhel氏の資料（PDF）を参照してください。

PWG関係のセッション

PWGはIEEEの下部組織で、「⁠プリンタの内側から外を見る」標準化を行うグループになります。つまり、外界からプリンタや複合機を制御する方法を共通化しようと言うものです。PWGで標準化された規格はIETFに提案され、最終的にはRFCになります。PWGの標準化がソフトウェアベンダー、サービスベンダーにとって重要さを増すであろうという話は先ほどしたとおりです。

しかし昨年にも同じことを書いたのですが、ときに標準化の作業というのは「文書を淡々とレビューする」側面があります。表現に誤解はないか、他の標準と整合は取れているか、などなど……。そういった議論の重要性は頭で理解はしているものの、睡眠欲はなかなか抑えがたいのはしかたがありません。そこで、今回は本当の「ホットトピック」にしぼることにして、それ以外のワーキンググループの活動については直接資料を参照いただくことにしましょう。

PWG Plenary

去年同様、初日の口切りのセッションです。進行も同じスタイルで、PWG議長のMicheal Sweet氏が全体を通し、個々の分科会活動についてはそれぞれの担当者が話すといった感じで進みました。

一番印象に残ったのはPWGロゴの変更についてです。今後、各規格の認証制度なども始めて行くとのことで、認証ロゴとしても使えるようなデザインに変更したそうですが、みなさんの感想はどうでしょうか？

図6　新しいPWGロゴ。センスが良いかはともかく、印刷・イメージングに関わるグループであることは一目瞭然

色々な分科会のサマリーも聞き、それぞれの会合も聞いた感想としては、「⁠今回のミーティングはIPP WGにつきる」です。ということで他のワーキンググループの活動報告はすべて飛ばして、IPP WGの活動を4つ紹介しましょう。

IPP Working Group: (0) General

各論に入る前にIPPについて簡単に補足しておきましょう。IPPはInternet Printing Protocolの略で、HTTP／HTTPS上で印刷その他のサービスを提供するものです。ただ印刷ジョブを流すだけでなく、プリンタの状態（正常・異常・異常だとしたら不具合原因）やプリンターの能力（カラーかモノクロか、両面印刷可能か、ステープルはできるか、など）の取得を行ったり、ジョブの印刷指定を別途スキーマとして定義しジョブチケットとして渡したり、さまざまなサービスを提供しています。またスキーマはかなり広範囲に汎用性を持って定義されているため、ベンダー透過な印刷ソリューションを構築しやすくなります。

IPPはそれほど新しい規格というわけではなく、IPP/1.0のRFC化が1999年で、Windows 2000 ServerはIPPサーバとなる機能を持っていました。翌年改定されたIPP/1.1が長らく使われていましたが、今年の4月にようやっと次世代の規格であるIPP/2.0がPWGで正式な規格となりました。もちろんこれもIETFに提案される予定です。

またIPP/2.0を印刷スタックとして、DNS-SDをサービスディスカバリー手段とし、印刷データプロトコルをPDFとPWG Raster[13]としたものがIPP Everywhereです。いわばPWG版Apple AirPrintとでも言えるサービスですが、当然標準規格なのであらゆるベンダーが実装可能です。

そんなわけで「すべての印刷ソリューションはIPPに収斂する」的な位置付けであり、IPPについて固有名詞だけでも知っておくことは印刷技術を俯瞰するのに必須だと言えましょう。可能ならばPWGのInternet Printing Protocolページをチェックしたり、そのページからMLを購読したりしておくのがオススメです。

IPP Working Group: (1) Paid Printing Extension

これについてはCUPS Plenaryのところで詳しく説明してしまったのでここでは省略します。要はこういう「周辺を固める仕様」が出てくるようになったのが、IPP本体が「もう十分に枯れた」仕様だということを意味していると感じます。

IPP Working Group: (2) IPP Shared Infrastructure Extension (IPPSIX)

このIPP拡張は今回の目玉でした。今までクラウドからの印刷サービスはCloud Imaging WGの領分と認識していたのですが、このWGはモデリングばかりやっていて一向に具体的な絵図が出てこない。そんなイライラを感じていた矢先のドラフトで、これは本当に驚きました。

IPPはこれまで、クライアントとプリンタ（またはサーバ）が同一ネットワークで到達できる必要がありました。プロキシを介した閉鎖ネットワーク内のプリンタに、外部のネットワーク、たとえばモバイルデバイスの公衆回線網から印刷するといったことはできなかったわけです。クラウドからの印刷も同様です。

IPPSIXの考え方はシンプルで、Infrastructure Printerというモジュールがネットワーク境界にあり、それぞれ外と内にIPPプリンタオブジェクトを配置します。この際、内部ネットワーク側は複数のIPPプリンタオブジェクトをぶら下げてもよいです。内部向けのプリンタオブジェクトは、IPPSIXで必要な情報を受け渡すために拡張されたIPPによってプリンタと通信しますが、ほとんどのプリンタは標準のIPPしか理解できないため、拡張IPPを解釈できるためのプロキシサービスを立て、このサービスモジュールが通訳の役割をします。将来的にはこのモジュールはプリンタに内蔵されることになるでしょう。

外部からのクライアントは実際に印刷したいプリンタのUUIDを何らかの方法で取得して、それを付けて印刷リクエストをInfrastructure Printerの外に向いているプリンタオブジェクトに送ります。するとInfrastructure Printer内部で外と内のプリンタオブジェクト間、そしてプリンタオブジェクトと（プロキシを介して）プリンタとのやり取りがあり、印刷パスが成立するというわけです。

まだ2013年4月に起草されたばかりのドラフトでTBDな部分も数多くあり、リファレンス実装も存在しないので「まだまだこれから」ではありますが、かなり期待は大きい拡張です。

なお、Cloud Imaging WGで起草されていたドラフトは、IPPSIXとかぶっている概念があるため、両者で用語のすり合わせを行いました。後追いで作られたIPPSIXがCloud Imaging WGの用語に合わせないところが、IPPSIXへの期待度を感じさせるような気がします。

IPP Working Group: (3) IPP Client Best Practice

IPPの1つのポイントは、今までOSに委譲してきたプリンタとのやり取りを、アプリケーションやミドルウェアの開発者が行う機会が増えてくることであり、またそうなることが期待されています。そんな意味で「IPPのクライアントアプリをどのように書いたら良いか」のガイドが必要ではないか、ということで作られたのがこの技術文書です。ここ数年、印刷標準化の表舞台に出てくることがなかったHP社のSmith Kennedy氏がメインで取り組んでいるのも興味深いです[14]⁠。

現在のところはおもにスキーマとして何を用いたら良いかという話で、デバイスのディスカバリーから始まってプリンタの諸元の問い合わせ、印刷に至るまで、ついやってしまいそうな良くない実装から、本来ならこうやるべきという実装を丁寧に示しています。レビュー中の文書を見ていただくとかなり活発に動いているのがわかると思います。実際のレビューでも、「⁠こういう話を盛り込むべきだ」「⁠ここはIPPのこの不具合について言及したほうが良い」などとかなり白熱した身のある議論になり、なかなか読みでのあるものになりそうだと感じました。

個人的にはこの文書のレビューや改定は継続的に追いかけて行き、できたら日本語訳なんかも作れたら良いなあ……などと漠然と考えています。

IPP Working Group: (4) IPP Self-Certification Manual

昨年のレポートでも書きましたが、IPPに現在若干の難があるとしたら相互接続性です。こういった標準化活動にベンダーから参加しているメンバーは、当然自社に戻って標準をサポートすることの意義を説いているとは思うのですが、最終的に判断するのは製品事業を行なっている部門であり、彼らは当然コストに見合うメリットを求めますので、「⁠標準化に対応しました」は魅力的なアピールにならないと判断しているのはやむを得ないのかもしれません[15]⁠。現状では各社とも対応はしていますが、試験が不十分だったり規格の理解に誤りがあり、たとえば「WindowsやMacから印刷できればOK」という品質保証の方法では、そこをきちんとテストできていないのではないかと考えられています。

そこで少しでも相互接続性を向上するインセンティブを増やし、また正しいテストを行える仕組みを整備しようということで、まずは文書としてのSelf-Certification（自己認証）マニュアルの整備と、テストツールであるipptools（CUPSに付属しています）の機能向上とテストスクリプトの充実、さらにはIPP Everywhereのために印刷結果を確認できるようにPDF、PWG Raster、JPEGのドキュメントを用意してPWG側で管理するという提案が出されました。自己認証というのはMicrosoft社のロゴプログラムなどでもされている方法ですが、ベンダー自身がテストした結果を認証団体に送ると、そこが結果をチェックして認証OKを出す仕組みのことです[16]⁠。多分デジタル認証したIPP (Everywhere)のロゴビットマップのデータが送付され、PWGの認証ページにデバイス名が載る、というような扱いになると思われます。

ここでもやはりターゲットが見えているので、テストデータ類はPWGがホストするとしてそのコントリビューションの方法、ipptoolsのバグが見つかったときの扱い（現在はCUPSの付属物だが、CUPSのバージョンアップまで待つのか⁠）⁠、たとえば「このプリンタはこういう周辺機器が付くが、その周辺機器に付いてはIPPでは操作できない」というような場合はOK／NGどちらにするのか（OKにする、で落ち着きました⁠）⁠、などなど活発な議論となりました。こういう議論・活動を経てIPP対応機器がソフトウェアベンダーから安心して使えるようになることが強く望まれます。

日常とAppleさんありがとうの話

PWGで紹介されているホテルは2つとも会場から徒歩15分で非常に近いのですが、ちょっとした高級ホテルでお高いのです。しかしもっと安くて遠いホテルとなるとバスは本数が少なくて不便だし、レンタカーでは値段がかかりすぎます。ので、素直に近くに宿を取ることにして、今回はCypress Hotelに滞在しました。毎朝コーヒーのサービスと、夕方にはグラスワイン1杯が振舞われる、なかなかオシャレなホテルです。当然ネットワーク完備。ここらへんはアメリカはやっぱり便利ですね。最上階（9階）で見晴らしもよく、ベッドも広々で快適でした。

今は日本からサンノゼ国際空港への直行便がないので、しょうがないのでサンフランシスコ国際空港に飛び、電車でサンフランシスコまで行って2時間ほどうろついたあと、BART－Caltrainと乗り継いで、駅までは昔の同僚に電話して迎えに来てもらいました。ここらへんの交通機関の少なさはもうどうしようもないですね。どのみち、昔の同僚とご飯を食べるつもりだったので好都合ではあったのですが。

北カリフォルニアはこのころはだいたい雨期は明けているので、概ね毎日良い天気でした。青い空の中、ホテルで汲んだコーヒーを飲み飲み、音楽を聞きながらのんきに歩いて会場に向かっていると、あーシリコンバレーは良いなーと思ったりするのでした。

会場のApple社De Anza Threeキャンパスは、冒頭にも書いたとおりApple本社ビルであるInfinite Loop Oneの道筋一本隣になります。Cupertinoはこの看板だらけ、つまりApple社のオフィスだらけなのですが、リンゴが青いのと黄色いのがあるんですよね。なんか違いがあるんでしょうか？

食事は昨年と同様、朝食と昼食は毎日ケータリングが来て無償でした。ホストであるApple社の懐から出ているそうです。いやーありがたやありがたや。コーヒーとお茶は常に飲み放題、朝はフレッシュジュース、昼はソーダ類が出るという感じですね。まあ軽食の類なのですが基本的に筆者はこういう食事好きなので問題ありません。

今回は現地で仲良くなったメンバーがバス組だったりホテルがイヤに遠かったりして皆で食事にって感じにはならなかったので、晩御飯はてくてく歩いて安食堂をさすらいました。あと、ちょっと歩くのですが、地図を見たらホームセンター（The Home Depot）があったので覗いて見ました。敢えて写真は載せませんが、いやーアメリカのホームセンターはやっぱり楽しい！　みなさんもチャンスがあったらぜひ行くことをオススメしますよ。

Infinite Loop OneのApple本社も見学に行きました。カンパニーストアを冷やかしたり。

そして土曜日は面倒になってホテルでリムジンを頼んで空港までまっしぐら。早いし楽だけど高い！　120ドルにチップですからちょっと痛いです。まあでも、駅までタクシーで行ってそこから電車乗りつぐことを考えればそんなもんでしょうか。

参加してみて

今年で2年目の参加となりました。前回は元ベンダーの立場のフリーランス、今回はSIerとして印刷ソリューションに使う種がないかと探すという、ちょっと視点が違う参加でしたが、今年は昨年に輪をかけてモバイルクラウドへのシフトが高まり、デスクトップは「見えている課題を順次解決する」「⁠モバイルに展開できるようにスタックを考え直す」という作業レベルの話題となっているように感じました。

そしてIPP WGの大躍進を肌身で感じられたのは大きいです。クラウドソリューションは当然Cloud Imaging Groupだと思っていてMLは眺めていたのですがあんまりおもしろい感じがしなくて、どうなってるんだろうと思ったらIPPSIXの提案を見てびっくりしました。こっちのほうがソフトウェアベンダー的にははるかに使いやすそうなサービスです。MLだけだと温度があまり感じられないのと、やはり電話会議は時差の関係でなかなか厳しいので、こうやって注目すべき技術を見定めるためにミーティングに出るのは良い機会だなと思いました。

私自身は来年も是非参加したいと思いましたが、なかなか万人に薦められるイベントではありません。しかし本記事を通じて、「⁠あ、この技術おもしろそう」と思ったら、ぜひOpenPrintingやPWGの各WGのMLに参加し、議論に加わってみてください。あるいはOpenPrinting Japanのミーティングに顔を出していただけるのも歓迎いたします。日本の、プリンタベンダーでないところから印刷標準化への要望や提案が出てくれば、筆者としてはとても嬉しいです。ぜひ仲間になりましょう！