GSoC 2013の印刷ネタを荒っぽく翻訳してみた
Linux デスクトップのソリューションについてデベロッパーがほとんど関心をもっていないように見えるのはなぜだ！ と愚痴っていてもしょうがないので（お前やればいいやんって言われそうだけど、私はエンジニアとしてあんまり有能な方じゃないのよん）、Linux Foundation の下部組織である印刷標準化団体 OpenPrinting が Google Summer of Code (以下 GSoC; 外人さんはジーソックと発音してる) の課題として提出している内容をざくざく訳してみようと思う。「へーこれは面白そうかも」って思ったらぜひ応募してみてね。
GSoC についてはカーネル/VM方面で有名なsyuuさんの素晴らしい記事があるからそれ読んだほうがいいと思う。
Google Summer of Code 2013: OpenPrinting projects
前振りは大したこと書いてないので翻訳省略。
軽量なモバイル印刷スタック実現のため、cups-filters に MuPDF サポートを追加 (Add MuPDF support to cups-filters for a lightweight mobile printing stack)
The cups-filters project at OpenPrinting (included in all Linux distributions using CUPS 1.6.x or newer) provides the filters needed to convert the print job output of desktop applications (usually PDF) into the printer's native language or into the universal CUPS/PWG-Raster format as input for a separate printer driver. It also provides the pdftopdf filter to apply page management (N pages per sheet, selected pages, even/odd pages for manual duplex, mirror for iron-on sheets, ...) to the PDF data stream.
OpenPrinting の cups-filters プロジェクト (CUPS 1.6.x を採用しているすべての Linux ディストリビューションで利用されている) は、デスクトップアプリケーションの印刷ジョブ出力 (通常は PDF) をプリンターが解釈できる言語、あるいは、汎用的な CUPS/PWG Raster フォーマットを中間形式として利用するプリンタードライバーのために、これらのフォーマットを生成するために必要とされます。このプロジェクトはまた PDF データストリームに対してページ管理 (N ページの集約印刷、ページ選択印刷、奇数ページ／偶数ページのみの印刷、アイロンプリント用の鏡面印刷など) を行う pdftopdf フィルターも提供します。
A central part to make this work is a PDF renderer and many of the filters are simply wrappers about a PDF renderer. Currently, cups-filters supports Ghostscript and Poppler as PDF renderer. With this project we want to add support for MuPDF as it is a more lightweight renderer made by Artifex, the printing specialists who already made Ghostscript. This is especially interesting for mobile devices with limited meomory, mass storage, and CPU resources.
この作業の中心となるのは PDF レンダラーであり多くのフィルターは PDF レンダラーのただのラッパーです。現在では、cups-filters は Ghostscript および Poppler を PDF レンダラーとしてサポートしています。このプロジェクトでは、Artifex によるより軽量なレンダラーである MuPDF のサポートを追加します。Artifex は Ghostscript の開発で知られる印刷のスペシャリストです。このプロジェクトは特にメモリーや二次記憶、CPU リソースが限られているモバイルデバイスで興味を持たれるでしょう。
The student will have to modify all filters which need a PDF renderer (pdftops, pdftoraster, pdftoijs, pdftoopvp, perhaps also pdftopdf) to add support for MuPDF without dropping the existing support for Ghostscript and Poppler. Switching between the renderers should be able at run time, to make binary packages of cups-filters suitable for systems of different form factors.
このプロジェクトを選んだ学生は PDF レンダラーを必要とするすべてのフィルター (pdftops, pdftoraster, pdftoijs, pdftoopvp, それから多分 pdftopdf も) を変更して、現在の Ghostscript および Poppler のサポートを落とすことなしに、MuPDF サポートを追加する必要があります。レンダラーの切り替えはランタイムで行える必要があります。cups-filters のバイナリーパッケージが違う種類の構成*1 を持つシステムに適したものになるためにです。
Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), Tobias Hoffmann (smilingthax at googlemail dot com), MuPDF developers TBD
Desired knowledge: C and/or C++ programming
Code License: MIT, GPL
訳者からの補足
これってはっきりと Ubuntu Touch 狙いですよねえ。Canonical のビジネスで必要な物を OpenPrinting でやるってのはなんか色々混同してないか？ って思うんだけど、まあ、そんなもんです。
技術的難易度はそれほど高くないので（多分）、プログラミングはものごっつ得意ってわけじゃないけど、GSoC には参加してみたい、って人にはいいかも。
ただ、こないだちょっと OpenPrinting Japan の会合で調べた限りでは、MuPDF はカラーマッチングがちゃんと機能していないように見えるのと、UTF-8 または UTF-16 で指定した文字の縦書きがうまくいかない (PDF の仕様外ではあるらしいですが、Poppler も Ghostscript もちゃんとレンダリングできる) のが気になるところ。まあ、このテーマ自体は MuPDF「も」利用可能にする、であって、MuPDF 自体をどうこうするわけではないし、問題があれば GS や Poppler を使い続ければいいわけですけど、「テスト回してみたら MuPDF 周りでいっぱい問題が出て、結局なんの評価やってんだかわかんなくなった」ってのはありそうでいやーですね。
まあそれをいうともっと大きく気になるのは、Artifex という会社があんまりオープンな開発体制をとってるとはいえなくて、昔、「gs-devel って全然メール流れてないけど、技術的ない質問ってここでいいの？」「あー、Artifex の連中は Bugzilla しか見てないから、直接レポートしたほうが早いかもよ」ってやり取りをみたのが印象的。CJK について詳しいコミッターが要るとは思えないし、そこら辺の展開はさてどうなりますか。そういう意味では MuPDF (Artifex) のメンターがまだ決まってないってのがちょっと不安かも。
MuPDF にプリンター用のバックエンドを追加 (Add printer output backends to MuPDF)
MuPDF is a lightweight PDF renderer made by Artifex, the company behind Ghostscript. In contrary to Ghostscript, MuPDF is a pure PDF renderer. It does not contain a PostScript interpreter nor parts of it are written in PostScript. This makes it smaller, faster, and less resource-consuming, the ideal solution for mobile devices like tablets or smartphones.
MuPDF は Ghostscript の開発企業である Artifex による軽量 PDF レンダラーです。Ghostscript とは異なり、MuPDF は純粋な PDF レンダラーです。PostScript インタプリターも持っていませんし、内部の一部が PostScript で作られているわけでもありません*2。したがって小型で、高速で、少ないリソースで動作しますので、モバイルデバイス、タブレットやスマートフォンなどに適しています。
On mobile devices printing will not be done with having tons of printer-model-specific drivers on the system. Once, they consume the limited mass storage space, and second, one uses the mobile device in several different local networks with different printers: At home, in the office, in a copy shop, ... and one wants to use the printers which are available there, without installing drivers and setting up queues.
モバイルデバイスでの印刷は、それぞれのプリンター向けのドライバーを大量に抱えたような形では実現されないでしょう。まず、外部記憶が小さいことを考えなければなりませんし、一つのモバイルデバイスはいくつかの異なったローカルネットワークに接続され、それぞれ異なったプリンターに接続されることを考える必要があります。家庭、オフィス、コピーショップ*3、などなど……利用者はそこで利用可能なプリンターを、ドライバーをインストールしたりキューをセットアップして利用することなく使いたいでしょう。
Therefore we want to have a system which automatically detects network printers and makes them available for local apps. To do so we restrict ourselves to printers with known, common languages: IPP Everywhere (Upcoming standard, PWG Raster and optionally some others) and PostScript, PDF, PCL 5c/e/6/XL (legacy standards). So MuPDF has to generate raster output for these languages, meaning raster embedded in the specifics of the language, and to avoid exhausting printer resources raster in small bands and no high-level output, even if the printer language is high-level.
したがってシステムはネットワークプリンターを自動的に検知し、それをローカルのアプリケーションで利用できるようにしなければなりません。そのため、プリンターはよく知られた、共通の言語をサポートしていると仮定します： IPP Everywhere (じき標準化予定、PWG Raster とオプションとしていくつか)、PostScript、PDF、PCL 5C/e/6/XL (古い業界標準)。そこで MuPDF はこれらの言語形式のラスターフォーマット、つまり言語で指定された形でラスターを埋め込んだ形式を生成できるようになる必要があり、またプリンターのリソースを使い果たさないようにラスターを小さなバンドに分割し、プリンター言語が高水準なものであっても高水準な形式を出力しないようにするべきです。
Artifex will also work on this, but to get additional man power we are also opening this project for students.
Artifex もこの作業を行なっていますが、より多くのマンパワーが必要なため、このプロジェクトに学生さんを招くことにしました。
Note that you have to assign copyright on your code to Artifex, as otherwise the code cannot be integrated in MuPDF.
コードを Artifex の著作物にすることに同意しなければならないことに注意してください。さもなくばコードを MuPDF に取り込むことはできません。
This project can be split to be worked on by more than one student.
このプロジェクトは一人以上の学生によって分担して行うことができます。
Mentors: MuPDF developers TBD, Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)
Desired knowledge: C and/or C++ programming
Code License: GPL
訳者からの補足
あーやっぱり MuPDF にコードコミットするには Artifex に著作権譲渡しないといけないんだ。うむむ。
MuPDF の内部構造は知らないですけど（これを機会にドライバープラグインの部分をオープンにしてくれないものか）、基本的には内部からラスターデータをガバっと受け取って各プリンター言語のラスターイメージ形式にするのは多分そんなに難しくない。めんどくさいのはバンディングで、バンディングってのはなにかってのは説明するのはちとめんどうなんで詳しくは省略しますが、要はプリンター側のメモリがしんどいから、イメージを短冊切りにして順繰りに送って一回の処理単位を小さくするってこと。たいしたことなさそうでしょ？
でも、これとディザリングとかそういう話が絡むとめんどくさいんだなー。単純に短冊で切ると、切り目のところでディザリングが不連続になって見た目が汚くなる。まあ、ここらへんは先人がみんな苦労してるところなので、多分プリンター言語レベルで「これはバンディングしたデータだよー」とかそういうことを言えるようになってるはず。そこら辺を忘れなければ大したことはない。
ちょっと MuPDF と Artifex の内情があんまり透明じゃなないところが気になるけど、基本的に「絵が出るテーマ」はできたときの喜びが大きいので、チャレンジしてみてほしいな。
pdftopvp フィルターを向上。Poppler のソースコードおよび内部 API のコピーを不要にする (Improve the pdftopvp filter to not need copying Poppler source code or unstable APIs)
The cups-filters project at OpenPrinting (included in all Linux distributions using CUPS 1.6.x or newer) provides the filters needed to convert the print job output of desktop applications (usually PDF) into the printer's native language or into the universal CUPS/PWG-Raster format as input for a separate printer driver. It also provides the pdftopdf filter to apply page management (N pages per sheet, selected pages, even/odd pages for manual duplex, mirror for iron-on sheets, ...) to the PDF data stream.
OpenPrinting の cups-filters プロジェクト (CUPS 1.6.x を採用しているすべての Linux ディストリビューションで利用されている) は、デスクトップアプリケーションの印刷ジョブ出力 (通常は PDF) をプリンターが解釈できる言語、あるいは、汎用的な CUPS/PWG Raster フォーマットを中間形式として利用するプリンタードライバーのために、これらのフォーマットを生成するために必要とされます。このプロジェクトはまた PDF データストリームに対してページ管理 (N ページの集約印刷、ページ選択印刷、奇数ページ／偶数ページのみの印刷、アイロンプリント用の鏡面印刷など) を行う pdftopdf フィルターも提供します。
One of the filters is pdftoopvp which is the interface between PDF (the standard print job format under Linux) and the OpenPrinting Vector high-level printer driver interface standard. This standard is currently used by several Japanese-market laser printers which do not use PostScript as it is usual in Europe and the US.
フィルターの中の一つ pdftopvp は PDF (Linux における印刷ジョブ標準フォーマット) から OpenPrinting Vector 高水準なプリンタードライバーインタフェース標準に変換するものです。この標準は現在、いくつかの日本市場のレーザープリンター向けに利用されています。US やヨーロッパとことなり、これらのプリンターは PostScript をサポートしていないからです。
This filter currently only supports Poppler as PDF renderer and the connection between the filter and Poppler is rather awkward, copying parts of Poppler's source code and using unstable APIs of Poppler which change with newer Poppler versions. This makes maintaining the filter difficult for the Linux distributions.
このフィルターは現在のところ PDF レンダラーとして Poppler だけを利用していますが、フィルターと Poppler の結合は少々野暮ったく、Poppler のソースコードの一部をコピーして、新しいバージョンではもう使われなくなった 内部 API を呼び出しています。このやり方は Linux ディストリビューションでのメンテナンスを難しくしています。
The task for the student is here to once improve the interface with Poppler if possible and also add support for Ghostscript (would improve color management a lot) and MuPDF (would improve integration with mobile and embedded devices).
学生へのタスクは Poppler とのインタフェースを改善し、もし可能なら Ghostscript (こちらのほうがカラーマネージメントにおいて優れています) と MuPDF (モバイルや組み込みデバイスにふさわしいものとなるでしょう) のサポートを追加することです。
Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), Koji Otani, BBR Inc. Japan (sho at bbr dot jp)
Desired knowledge: C and/or C++ programming
Code License: MIT
訳者からの補足
これはまあなんというか、意味がないとは言わないけど、あんまりオススメできないかなーと。
というのはなぜかというと、pdftoopvp ってフィルター、現状誰も使ってないんですわ。
確かに上で書いてあるとおり、OPVP という標準は「いくつかの日本市場のレーザープリンター向けに利用されて」いるんですけど、実はみんな Ghostscript の OPVP ドライバー (後述) を利用しているのですね。で、pdftoopvp に移行する旨を表明しているベンダーは現状存在しない。そして多分皆さんご存知のとおり、日本のベンダーというものは「すでにうまくいっている仕組みを変えるということは奇跡に近いほどありえない」わけですわね。
ので、はっきりいうとこのテーマ、やっても報われない可能性が高いです。
なお、こんなこと書いちゃっていいのかわかりませんが、メンターにオリジナルの pdftoopvp の作者である BBR の大谷さんの名前が上がってますが、「私、そんなオファー受けてないですよ」だそうです :)
libJTAPI への PWG Job-Ticket バックエンド (PWG Job-Ticket backend for libJTAPI (Job Ticket API))
後述の理由で訳は省略。
Job tickets are extended descriptions for print jobs. They tell which documents should be printed, on which type of paper, which resolution and quality, whether there should be sheets inserted between the documents, ..., and even information like delivery address, payment, ... A job ticket accompanies a print job from its submission to its delivery. Job tickets come from the professional printing world. In former times they were a paper form with instructions what everyone involved in the printing process has to do. Nowadays they are standardized files which are used by print servers, printers, and production printing machines.
IPP Everywhere is a next generation printing protocol by the Printing Work Group (PWG) and uses job tickets for all printing metadata. This makes job ticket handling vital for IPP Everywhere support. For IPP Everywhere the PWG has created the PWG Job Ticket format.
Libjtapi is OpenPrinting's reference implementation of the FSG's JTAPI standard. The FSG (Free Standards Group) was a predecessor to the Linux Foundation. The JTAPI standard defines an abstract api for producing and consuming job tickets. Thus Libjtapi can create Job Tickets and translate between job ticket formats provided a backend has been developed.
This project is to develop a Libjtapi backend for the PWG's job ticket format. This backend should be able to consume PWG tickets and produce PWG tickets.
Proposed Tasking:
Objective: Develop a Libjtapi backend for accepting, parsing, interpreting and translating PWG Job Tickets to LibJTAPI objects/attributes.
Approach: As Libjtapi is written in C89 this backend should be as well. PWG Job Tickets can come in either XML or JSON flavours and only one of these flavours must be supported. A JSON or XML parsing library written in C89 and relicensable under the EPL should be used. The backend may be written using internal Libjtapi helper functions or against the more verbose jtapi apis.
Code License: EPL
Coding Language: C89
Coding Document: In-line commenting must be sufficient to understand the flow and any section requiring extended understanding.
Operating System: Student’s choice – Linux, Windows, Mac, ... (non-gui for either)
Interface: Command Line
Document: Minimum:
- How to build the PWG Job Ticket backend.
- How to build the test suite
- How to run the test suite
- Three example PWG job tickets that can be consumed and produced without data loss.
Mentor: Glen Petrie, Epson (glen dot petrie at eitc dot epson dot com)
Desired knowledge: C Programming
訳者からの補足
JTAPI なんてもう誰も期待してないってのは正直なとこなんだけど概略だけ。詳しくは原文読んでね。
CUPS のジョブ情報ってどうやって渡されてるかって言うと、実のところ CUPS フィルターへのコマンドライン引数なんすね。
- o Pagesize=A4 -o Duplex=LongEdge -o number-up=4 -o number-up-layout=tblr
とかこんな感じ。ダサくて死ぬ。しかもこれフィルターパイプラインの中で全部同じ値が渡されるんですよね。なおかつ「どのオプションがどのフィルター/プリンターの責務」ということを知るすべがないし、コントロールもできない（例えば number-up をプリンター側でサポートしてたとしても、常に pdftopdf で処理することしかできない；まあ、ごく一部は「このオプションはプリンターに渡す」って指定があるけど)。
なお Windows の場合、古典的な GDI 印刷の場合は DEVMODE という構造体 (共通部分と、機種ごとの拡張部分がある) を経由してやったりとったりして、OS X の場合は Job Ticket*4 という XML フォーマットで渡してた気がする。OS X の場合は印刷システムは CUPS なんだけど、CUPS の PPD の形式から Job Ticket にどう変換するかは OS X の中で機械的に変換できるようにしてるんだと思ったなあ。
ともかくコマンドライン引数で渡すってのはありえないわけで、かといって今更構造体を渡したりするのはちょっと近代的じゃない（扱いミスると保護違反とか起きて大変なことになるし）。そんなわけで、Windows の新しい印刷フレームワークである WPF も Print Ticket (プリンターそのももの性質を表すチケット) と Job Ticket (印刷ジョブ自体の性質を表すチケット) を渡すようにしてる。今のモダンな印刷システムは Job Ticket を使うことになってるというわけ。
けど Linux においては、JTAPI ってぼくが関わりはじめた頃からずーーーっとプロジェクトに名前を連ねていて、でも結局誰も使ってないという寂しい状態。
一応補足しておくと、PWG (Printer Working Group) という団体で策定している IPP という印刷プロトコルにおいても、プリンター自身を表現するデータスキーマや、ジョブに対するスキーマが存在します。今回のテーマは JTAPI のスキーマを後者の PWG Job Ticket というのに合わせ込もうという話で、スキーマ自体が林立するのは意味がないことだからこのテーマそのものには意味なしとは言わないんだけど、JTAPI 自体が……ふぅ。まあ、いいです。気になる人は申し込んでみてもよくってよ。
foomatic-rip: 汎用プリントフィルターをメンテが楽な CUPS フィルターに置き換え (foomatic-rip: Replace the universal print filter by an easy-to-maintain CUPS filter)
foomatic-rip is a universal print filter to work as a wrapper around Ghostscript to make the use of Ghostscript-based printer drivers with arbitrary printing systems simple. In the times back when the Foomatic project started there were many printing systems available for Linux: LPD, GNUlpr, LPRng, CUPS, PDQ, PPR, CPS, ... and they were all supported by Foomatic. Currently practically only CUPS is used and CUPS is also the only printing system with ongoing development and solid maintenance. The other systems are not maintained and developed any more (only very little activity on LPRng) and only rarely used.
foomatic-rip は Ghostscript のラッパーとして動作する汎用プリントフィルターで、Ghostscript ベースのプリンタードライバーを任意の印刷システムにシンプルに提供できるためのものです。Foomatic プロジェクトが始まったときには、Linux には様々な印刷システムが存在しました：LPD, GNUlpr, LPRng, CUPS, PDQ, PPR, CPS, ... そして、Foomatic はそれらすべてをサポートしていました。今や CUPS だけが使われており、また現在開発が進行して強固にメンテナンスされているのもまた CUPS だけなのです。他のシステムはメンテナンスされておらずすでに開発もされていません (LPRng だけはほんの少し活動しています) し、ほとんど使われてもいません。
The idea is to make a replacement for the foomatic-rip filter which supports only CUPS and drops all the code for the other printing systems which gets only rarely used and therefore very difficult to maintain and test. The remaining code should also simplified as much as possible to get best maintainability.
このアイディアは foomatic-rip フィルターを CUPS サポートだけとし、めったに使われない他の印刷システムに対応するすべてのコードを破棄するというものです。これによりメンテナンスとテストの手間が軽減されます。CUPS 用に残したコードはメンテナンスを考えて可能な限りシンプルにすべきです。
Mentors: Lars Uebernickel, printing software developer (lars at uebernic dot de), Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)
Desired knowledge: C and/or C++ programming
Code License: GPL
訳者からの補足
これは筋が良さそうなテーマ。基本的にはソースコードをバサバサ切っていく作業になるんだけど、現場の foomatic-rip は Perl から C にポートされてあんまり綺麗じゃないって聞いた記憶があるんで、汚いコードを綺麗にするのが快感だぜ俺！って人におすすめ。
Foomatic: PPD 生成の能力向上: オプション競合とプリンター互換性クラス (Foomatic: Improving the PPD generation capabilities: Option conflicts and printer compatibility classes)
Foomatic serves now well for more than 10 years for integrating Ghostscript-based printer drivers with the printing environment under Linux (usually CUPS). Based on an XML database of printers, drivers, and user-settable driver options PPD (Postscript Printer Description) files are generated and used together with the universal print filter foomatic-rip. This way the user has access to all the driver's (and printer's) capabilities and Ghostscript is correctly called by the printing system to execute the print job.
Foomatic は 10 年以上の間、Ghostscript ベースのプリンタードライバーを Linux で動作する印刷環境 (通常は CUPS) に統合するのに役立ってきました。プリンター情報、ドライバー情報、そしてユーザーが設定可能なドライバーオプションが記載された XML ファイルにより、PPD (Postscript Printer Description) ファイルが生成され、汎用印刷フィルター foomatic-rip と共に用いられます。このやり方ではユーザーはすべてのドライバーの（そしてプリンターの）能力にアクセスでき、印刷ジョブを実行するために Ghostscript は印刷システムから正しく呼ばれることができます。
This worked principally very well. One can really control all options of the printer drivers and even more sophisticated techniques, like CUPS' custom options (arbitrary numbers and strings as parameters) are supported.
これは基本的に非常にうまく動いていました。プリンタードライバーのすべてのオプションを制御でき、さらに洗練されたテクニック、例えば CUPS のカスタムオプション (数値や文字列をパラメータとして入力できる) もサポートできました。
But there are still two problems which did not get addressed due to the lack of manpower for implementing them:
しかしながら、実装のマンパワーが足りないために次の二つの問題が依然として存在します：
オプション設定の衝突 (Option setting conflicts)
Often option settings do not work together, like printing double-sided on transparencies. PPD files use the "*UIConstraints: ..." keyword to mark these conflicts so that in print dialogs and printer setup tools one cannot choose conflicting settings.
しばしば複数のオプション設定は同時に指定できません。例えばOHPシートは両面印刷できません。PPD ファイルは "*UIConstaraints: ..." キーワードによってこれらの衝突を表現し、プリントダイアログやプリンター設定ツールはこのように衝突する設定をできないようにしています*5。
Foomatic has no functionality to define option setting conflicts and generate appropriate "*UIConstraints: ..." keywords in the PPD files.
Foomatic は現在、オプション設定の衝突を定義する機能を有しておらず、PPD に "*UIConstraints: ..." キーワードを正しく生成することができません。
プリンター互換クラス (Printer compatibility classes)
The other problem is that it is rather awkward to assign drivers and options to printers if there are very many similar, compatible models. Often one has to mention each printer explicitly in the driver and option XML entries.
もう一つの問題は、非常にそっくりなプリンター、互換機に対して、ドライバーとオプションを割り当てるうまいやり方がないことです。こういうときには、個々のプリンターに明示的に同じドライバーとオプションの組み合わせを XML エントリーに書かなければなりませんでした。
Instead of needing to add many compatible printers to the drivers and to the constraints of options one could introduce compatibility classes. A compatibility class contains absolutely compatible printers, which means printers which work with the same drivers, the same options, and the same choices for the options. Then one can put the class name into the list of supported printers of a driver and also into the constraints of the options and so one avoids needing to insert tenth of printers everywhere. Especially there are many HP inkjets which are absolutely compatible to each other (around ten classes instead of 100 printers) and there are many clones of HP LaserJet printers.
たくさんの互換性のあるプリンターを追加する代わりに、「互換性クラス」という新たなオプションへの制約を持つドライバーを考えます。互換性クラスは完全に互換なプリンターのリストを含みます。つまり完全に同じドライバーで動き、同じオプションを持ち、同じオプションの選択肢を持つということです。互換性クラスはクラス名と、一つのドライバーがサポートしているプリンターのリスト、そしてオプションの制約などを持ち、同じプリンターの情報を10回繰り返す必要をなくしてくれます。特に HP のインクジェットは相互に高い互換性を持ちます (100 個のプリンターの代わりに大体 10 個程度のクラスで済むでしょう) し、また HP LaserJet のクローンプリンターについても同じ事が言えます。
What is needed for solving both problems is an extension to XML database, to the SQL representation of the database (for accelerated database access), and to the PPD file generator.
両方の問題を解決するには XML データベースへの拡張、データベースの SQL における表現 (データベースのアクセスを加速するため)、そして PPD ファイル生成系を変更しなければなりません。
Mentor: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)
Desired knowledge: Perl programming
Code License: GPL
訳者からの補足
この場合の Foomatic というのは Foomatic DB という、プリンターの諸元を書いた XML から PPD を自動生成する仕組みです。
OpenPrinting の OpenPrinting Database のバックエンドなんですが、私自身はあんまり使っていないので UI Constraints すらサポートしていなかったのは知らなかった。これ使っている人には良さそうに見えますねえ。
ドライバーデータベースには PPD を直に上げることもできたので、私はそっちしか使ったことなかったんですな。
内蔵された Ghostscript ドライバーを OPVP ドライバーにモジュール化 (Modularization of built-in GhostScript drivers into an OPVP driver)
In the free software world there are often several different projects for fulfilling the same task. For rendering (rasterizing) PDF (the standard format for print jobs) there are Poppler and Ghostscript. Both have there advantages and disadvantages, for example Poppler is completely written in C++ whereas the PDF interpreter of Ghostscript is written in PostScript (note that PostScript is a full-featured programming language), which makes Poppler smaller and faster. Ghostscript's advantage is having better color management and being better optimized for printing.
フリーソフトウェアの世界ではしばしば同じ目的を達成するために異なるプロジェクトが存在することがあります。PDF (印刷ジョブの標準フォーマット) のレンダリング (ラスタライジング) のためには Poppler と Ghostscript があります。それぞれに利点と欠点があり、例えば Poppler は完全に C++ で書かれているのに対し、PDF インタプリタとしての Ghostscript は PostScript で書かれています (PostScript は完全な機能を持つプログラミング言語であることを注記しておきましょう) ので、Poppler のほうが小さくて高速です。Ghostscript の利点はより優れた色管理と、印刷に向けてより最適化されていることです。
Unfortunately, one cannot freely choose between the two yet as Ghostscript has many important printer driver, especially "pxlcolor"/"pxlmono", built in and so dropping Ghostscript in favor of Poppler would lead to a loss of important functionality, like PCL-XL printer support.
残念なことに、二つの中から一つを完全に自由に選ぶことはできません。Ghostscript はいくつかの重要なプリンタードライバーを内蔵しており、とりわけ "pxlcolor" / "pxlmono" ですが、そのために Ghostscript を放棄して Poppler を採用することはいくつか重要な機能、例えば PCL-XL プリンターサポートを落とすことになってしまうのです。
To avoid this we need to make all printer drivers working with arbitrary renderers. This is easy to implement for most modern drivers which are IJS plug-ins, separate filters, CUPS raster drivers, and OpenPrinting Vector drivers, but for the drivers built into Ghostscript this is not yet possible.
この問題を回避するため、すべてのプリンタードライバーを任意のレンダラーで動作するようにしなければなりません。IJS プラグインや、分離されたフィルターや、CUPS ラスタードライバーや、OpenPrinting Vector ドライバーなどのモダンなドライバーについては簡単に実装できますが、Ghostscript に内蔵されたドライバーについては依然不可能です。
Therefore we want to modularize the built-in Ghostscript drivers into something which plugs into the renderer. A side effect of this is also the easier maintainability of Ghostscript and of the drivers, especially of built-in drivers from third parties.
したがって Ghostscript 内臓のドライバーをモジュール化してレンダラーへのプラグインとしたいと考えています。副作用として、この作業を行うと Ghostscript 自体とドライバーのメンテナンスが容易になります。とりわけサードパーティから供給されたドライバーについては。
As there are some high level/vector devices the suggested interface is the OpenPrinting Vector framework. The implementation should be some kind of glue code module which has on one end the OPVP interface to get the data from the renderer and on the other end the internal API of GhostScript to couple to the original GhostScript driver code. Compiling this should result in one or more OPVP drivers with the same functionality as the built-in GhostScript drivers.
高水準のベクターデバイスについて推奨されるインタフェースは OpenPrinting Vector フレームワークです。実装はいくつかの種類のグルーコード群からなるべきで、片側は OPVP インタフェースによってレンダラーからデータを受け取り、もう片側は Ghostscript の内部 API からオリジナルの Ghostscript のドライバーコードを受け取ります。コンパイルした結果、Ghostscript の内蔵ドライバーと同じ機能を持つ一つまたは複数の OPVP ドライバーが生成されるべきです。
Goal of this project is to implement and test this framework and it would be a plus to also do the needed modification of the Foomatic data to generate the PPDs for the modularized drivers.
このプロジェクトの目的はこのフレームワークの実装およびテストで、追加としてモジュール化されたドライバー向けの PPD を生成するために Foomatic データの変更も必要になるでしょう。
Mentor: Hin-Tak Leung (HinTak dot Leung at gmail dot com), author of several drivers for printers with proprietary protocols; Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)
Desired knowledge: Knowledge in C programming is required. Great is also knowledge in PostScript and the Linux/Unix printing workflow.
Code License: GPL
訳者からの補足
これ、私が OPVP-RPDL として構想を暖めたままもう100年ぐらいになる (とっとと実装しろよ……) 奴を、PCL 5 とか XL についてやりましょうってことですね。これが実現すると GS をポイできる可能性が高まるので、ぜひ実現して欲しいですなあ。
でも日本の OPVP ドライバーはみんな GS 使ってるので、GS をポイできる日は本当に来るんでしょうか……。pdftoopvp に移行するには何より政治的問題が大きいもんなぁ。「Linux 印刷みたいなシェア小さいもののために、別にそれで機能が増えるわけでもないのに、再評価するとかありえんやんか」ってとこでしょうからねえ。
ベンダー製 WIN32 ドライバーを Linux アプリケーションで利用可能に (Vendor WIN32 driver made available to Linux applications)
There was a Google Summer of Code 2007 project under wine to use WIN32 drivers to print from wine, and some adaption of that idea in some limited fashion in ddiwrapper. It would be quite interesting and useful to properly integrate this into the more general printing workflow:
Google Summer of Code 2007 のプロジェクトで WIN32 ドライバー wine 上で動かし、wine からの印刷に使おうというものがあり、このアイディアを部分的に ddiwrapper*6 に適用しようというものです。これは興味深い試みで、より一般的な印刷ワークフローに効果的に統合されることで便利になるでしょう。
- make it possible to print from linux applications through cups or other spoolers with more(all?) WIN32 drivers
Linux アプリケーションが CUPS や他のスプーラを通じてより多くの (すべての？) WIN32 ドライバーから印刷できるようになるかもしれません。
Currently there are two(?) frameworks which are usable for loading binary-only closed-source vendor driver modules, OPVP and IJS. There are a few other FOSS projects which uses some part of wine to load binary-only WIN32 modules for accessing data in proprietary format quite successfully - e.g. ndiswrapper (for wireless network hardware), mplayer (for multimedia playback).
今のところ二つ(?)、バイナリーのみのクローズドソースのベンダー製ドライバーモジュールを読み込めるフレームワークが存在します。OPVP と IJS です。わずかな FOSS プロジェクトが wine の一部を用いてバイナリーのみの WIN32 モジュールを読み込みプロプライエタリフォーマットからデータをアクセスすることに成功しています - 例えば ndiswrapper (無線ネットワークハードウェア向け)、mplayer (マルチメディア再生) などです。
Some background information is in here
背景となる情報はリンク先をご覧ください。
Mentor: Hin-Tak Leung (HinTak dot Leung at gmail dot com), author of several drivers for printers with proprietary protocols; Detlef Riekenberg from the Wine Project, who was the mentor for the Gsoc 2007 wine project for print proxy, has agreed to be involved.
Desired knowledge: C programming
訳者からの補足
これ Hin-Tak が随分ご執心で、毎回 GSoC に出して毎回ボツってるという素敵なテーマです。はっきりいって元 Windows プリンタードライバーの開発者としては ddiwrapper というアイディアには割と懐疑的で、あの複雑怪奇な動きを模倣することができるわけがないと思ってます。まあでも、もし万が一うまく行っちゃったりしたら革命的なので、応募してうまく実装できちゃったらヒーローになるでしょうねえ。できたころには WIN32 が滅びてるとかなければよいですがｗ
OpenPrinting Webサイト: プリンターとドライバーの管理のためのWebアプリケーション (OpenPrinting web site: Web application for printer and driver administration)
Since four years the OpenPrinting web site uses a PHP/MySQL based web application to administer a growing printer and printer driver database. Currently the site supports searching and listing of printers and drivers, download and submission of PPD (Postscript Printer Description) and drivers and a rudimentary backend interface for moderation of submissions.
4年の間 OpenPrinting の Web サイトは PHP/MySQL ベースの Web アプリで、どんどん増えるプリンターとプリンタードライバーデータベースを管理してきました。現在このサイトはプリンターとドライバーの検索と一覧表示、登録された PPD (Postscript Printer Description) およびドライバーのダウンロード、登録をモデレートする基本的なバックエンドのインターフェースをサポートしています。
While all basic functionality is given, there are a lot of areas to improve. The long forms related to driver and printer submission could be shortend and moved to an assistant that allows for an easier and faster submission process. The moderation process could be simplified to allow an even faster overview for moderators and administrators. There are a lot of small issues where usability could be enhanced, for example links to create a similar printer, duplicating an existing record.
基本的な機能はすべて提供されているとはいえ、まだまだ進化の余地はあります。ドライバーおよびプリンター登録のための長いフォームは、もっと短くなるべきですし、簡単かつ素早い登録プロセスの手助けとなるべきです。モデレーションプロセスはモデレータおよび管理者に素早く概要を示すようにシンプルになるべきです。使い勝手の細かな向上の余地はたくさんあり、例えば似たようなプリンターへのリンクや、すでに存在するレコードのコピーなどです。
The backend processing is another part that should be improved. Currently all scripts and build routines of the project are mostly tight to server environment that serves the web site. Beside building more generalized scripts, the student could also automate the import and update process of Printer Description files in the exisiting BZR repository.
バックエンドプロセスもまた改善されるべきです。今のところこのプロジェクトのすべてのスクリプトおよびビルドルーチンは Web サイトを供給しているサーバー環境と蜜に結合しています。より一般化したスクリプトを作成することで、学生は Printer Description ファイルをすでにある BZR リポジトリからインポートしてアップグレードするプロセスを自動化できるでしょう。
Basic email notifications for administrators and moderators exist, but optional notifications for uploaders are still missing.
管理者とモデレーターへの基本的な電子メール通知は存在していますが、ファイルをアップロードした人へのオプションの通知機能は未だ欠落しています。
There is still a lot of manual work involved, that could be simplified or automated to leave more time to contributors and administrators to work in drivers and printer descriptions itself.
今は手作業でやっていますが、単純化したり自動化したりすることで、貢献者や管理者にドライバーやプリンターの記述自身についてより時間を割けるようにすることはたくさんあります。
Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), Jeff Licquia, The Linux Foundation (jeff at licquia dot org)
Desired knowledge: PHP, MySQL, web interface programming, (Bash) scripting, basic usability experience Code
License: GPL
訳者からの補足
これも毎回上がっているような気がする。Linux Foundation のサイト自体は確か Drupal なんですけど、OpenPrinting のサイトはフルスクラッチで書かれているのかしら。
Cairo のカラーマネジメントのコードを upstream へ (Get the cairo color management code upstream)
Adrian Johnson did a lot of the work needed to make cairo color managed. Finishing this work and getting the code upstream would allow us to simplify a lot of applications that use cairo. See http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space for the branch. Adrian has also patched Inkscape to use the new features, and that needs cleaning up and pushing upstream http://cgit.freedesktop.org/~ajohnson/inkscape/log/?h=color-space Also see http://lists.cairographics.org/archives/cairo/2012-July/023353.html and https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html for more details.
Adrian Johnson は cairo をカラーマネジメント対応にするためにたくさんの作業を行いました。この作業が終わり、upstream に取り込むことで、cairo を用いている多数のアプリケーションに対する作業をシンプルにしてくれます．http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space ブランチをご覧ください。Adrian はまた、Inkscape にこの新しい機能を利用するパッチを書きましたが、これは整理して upstream に上げる必要があります。http://cgit.freedesktop.org/~ajohnson/inkscape/log/?h=color-space 詳細については以下も参照してください。http://lists.cairographics.org/archives/cairo/2012-July/023353.html, https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html
Expectations: The cairo and inskcape code is pushed upstream with any required modifications. Ideally someone familiar with the cairo community would take this on, as Adrian found it hard to get the code approved upstream.
期待：Cairo と Inkscape のコードが必要な変更を受けた上でアップストリームにプッシュされること。理想的なのは cairo コミュニティに詳しい誰かが、Adrian が彼のコードが upstream に受け入れられるのは難しいとわかった部分を手助けしてくれること。
Skills: Understanding of basic color management, basic use of bzr and git, proficient in C.
Contact: Richard Hughes
訳者からの補足
なんかこれだけ非常に実務的で GSoC のテーマっぽくないですね。Richard Hughes は Red Hat のデスクトップチームでカラーマネジメントの専門家なのですが、彼が自分でやれない程度にはめんどくさいんでしょうか。メールの方は読んでないんですが……。
まとめ
まあ OpenPrinting のテーマというのはだいたいこんな感じだったりします。JTAPI とか WIN32 Driver みたいな何年も放置な奴もあれば、「それ明らかに Ubuntu の都合だよね」みたいなのがしれっと入っていたりするのがおかしいですが、それは OpenPrinting のマネージャーの Till Kamppeter が Canonical の社員だからというのもあるとはいえ、標準化団体としては「全体最適になるテーマを出して、その一部がどこかのためになる」ということは決して悪いことじゃないですからね。
これは私は何度も何度も何度も繰り返してきたように、印刷についての諸問題というのは技術的にはそれほど難易度の高いものではありません。チャレンジングな課題がお好みな人にはつまらないかもしれませんが、「この程度のことが人手がないからといって放置されてきた」という事実は歴然としてあるわけです（まあ、私も手を動かしてないので、偉そうなことは言えないんですが）。
ということで技術面というより、海外のコミュニティとガチでやりあってモノづくりをする、という経験として、OpenPrinting の GSoC を選んでみてはいかがでしょうか？
……原稿の息抜きで始めたのに随分時間かけちゃった。原稿が終わったら、LibreOffice 編をやる……っていったら読む人いる？
*1:訳注：原文 form factors。英辞郎によると「ハードウェアの寸法や形状などを決定付ける要因」だそうですが。
*2:訳注：つーことは Ghostscript は一部が PostScript で書かれているということなんですけれども。
*3:訳注：キンコーズやコンビニのようなものを想像してくださいな。
*4:もともと Job Ticket というのは商業印刷のように工程間がオフラインで分かれているときに、この工程ではどの処理を、この工程ではどの処理をやります、ということを指定して、記録する「チケット」のことをいうらしいです。
*5:訳注：とはいえ、この「衝突する設定をできないように見せる」やり方があまりよくないというのは別の問題としてあります。これは今、日本のワーキンググループで議論中です。
*6:DDI というのは Windows のグラフィックモデル GDI とプリンタードライバーの間のインタフェース (Device Driver Interface) で、ddiwrapper というのは名前の通り DDI を Linux 上でエミュレーションしようという試み。大昔に Novell (現 SUSE) が試みて放置されてる奴。
