なるひこの Linux Printing お勉強日記 RSSフィード

ご注意!

ここはあくまでも私個人のブログであり、いかなる団体や組織の立場から離れた、私個人の知見なり学んだことなり勝手な思い(妄想ともいう)を書く場所であります。それを踏まえてお楽しみいただければ幸いです。

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

2014-11-02

はじめてのLibreOfficeソースコミット

2014.11.05 追記:とても重要な参考資料を紹介するの忘れていたので後ろにくっつけます。見てくださいね。


私は口先野郎なので、「LibreOfficeの日本コミュニティに一番必要なのはコード書く人。オープンソースはコード書く人が正義*1」とか言っていながら、自分はぜんぜんコード書いてなかったんですよね。これでも元はプログラミングでおまんまを食べてた人間として、これはいかんよなーってずっと考えてた。

開発に挑戦することに対してはいろんなハードルがあるだろうけど、LibreOfficeの場合はコードベースも巨大だしコミュニティもいろんな人が関わってるのでそれなりのお作法もある。正直、どこから手を付けていいかわかんないところがあります。で、私的には、もちろん開発そのものの難しさもあるけれども、それ以前に、とにかく自分の修正のパッチを送ってレビュープロセス通してって、人が介在するところに心理的に抵抗があったわけです。英語では丁寧にドキュメント化されてるのだけど、私英語得意じゃないしね。

で、これは誇っていいことだと思うんですが、LibreOfficeにはEasy Hacksという「開発入門者のための誰でも直せそうなバグ」をタグ付けしたものがあって、もうほんっとに簡単なバグ(で、緊急性が高くない奴)とかを元に、修正してコンパイルしてレビューシステムにpushしてレビュー受けて、ってことをできるようになってる。よし、これにチャレンジしようと。

LibreOffic Conference 2014 Bernのときから初めて、ついついサボってたのでこれはイケナイと思い立ち、自分の尻叩きのために関東LibreOfficeHackFest(#1) with 第119回東京エリアDebian勉強会というイベントをやって*2 ようやっと目鼻がつき、こないだ送ったパッチは無事に取り込まれました。

すっごいしょぼい修正で恥ずかしいのですが一応コミッタ*3 の仲間入りをしたので、記録として残しておきます。

課題の選定

Easy HacksはAll LibreOffice Easy Hacks by required Skillというページで必要なスキルごとに分類されているんですが、今回は曲がりなりにも昔はそれでご飯食べてたC++の、超簡単レベルな奴からピックアップ。

Bug 43157 - Clean up OSL_ASSERT, DBG_ASSERT, etc.

Bug Descriptionから引用すると:

The assertion/logging functionality from osl/diagnose.h (OSL_TRACE, OSL_ASSERT, OSL_ENSURE, OSL_FAIL) and tools/debug.hxx (DBG_ASSERTWARNING, DBG_ASSERT, DBG_BF_ASSERT, DBG_WARNING, DBG_WARNING1--5, DBG_WARNINGFILE, DBG_ERRORFILE) is obsolete and needs to be cleaned up:

  • To assert invariants of the code (that can only be violated if there are programming errors) use standard C/C++ assert.
  • To log warnings about unusual events (that the code nevertheless needs to handle in some way, like malformed input or I/O failures), use the SAL_WARN... macros from sal/log.h.
  • To log other information useful for debugging, use the SAL_INFO... macros.

See https://wiki.documentfoundation.org/Development#Assertions_and_Logging, the mail thread at http://lists.freedesktop.org/archives/libreoffice/2011-November/020864.html, and the documentation in the sal/log.h header for further information.

要は古くて非推奨になったアサーション・ロギングマクロを、今のスタイルに書き直しましょう、ってだけ。機械的な置換でいけそうだからこれなら自分でもできるやろと。

ビルド環境構築

まずはgitでソースコードをまるっと取って来ます。で、ビルドに必要なライブラリをがっと取ってきて、一回ビルド通します。LibreOfficeのフルビルドは環境にも寄りますけど数時間かかるので、ビルド投入して寝ちゃうのがいいでしょう。

$ git clone git://gerrit.libreoffice.org/core LibreOffice
$ sudo apt-get build-dep libreoffice
$ cd LibreOffice
$ ./autogen.sh --enable-gstreamer --disable-gstreamer-0-10 --with-lang="ALL"
$ make

ビルド終わったらちゃんと動くことを確認します。

$ instdir/programs/swriter &

ヘルプ→LibreOfficeDevについて、を確認。

f:id:naruoga:20141102094904p:image

大丈夫そうですね。


コードの修正

今回の修正は色んなところのソースをお掃除しましょうというネタなので、どこ直してもまあいいわけです。なので直せそうなところをgrepで探しましょう。

豆知識としては、LibreOfficeビルド時に依存するライブラリのバージョンを固定するために、サーバーにおいてあるtar ballを落としてきてworkdir/UnpackedTarballというところに展開します。その他yaccの生成物とかもあるので、単にgrep -r するとそういうのがいっぱい引っかかってしまうので、git grep使うほうが100倍ぐらい賢いです。

ということで、git grep OSL_ したら、あるわあるわ。どれ直してももちろんよいのですが、一部のソースは特定のconfigureオプションをオンにしないとコンパイルされない(そして、そのconfigureオプションはほとんど誰も使っていない)とかある*4 ので、ちょっとだけ注意が必要です。今回は pyuno/source/module/pyuno.cxx というソースを直すことにしました。変更が2行しかないのでw

ターゲットが決まったらまずは作業ブランチ切りましょう。

git checkout -b work

修正はバグ票にあった他のコミットを見ながら、こんな感じに書き換えればいいのかなと*5

--- a/pyuno/source/module/pyuno.cxx
+++ b/pyuno/source/module/pyuno.cxx
@@ -66,7 +66,7 @@ void PyUNO_del (PyObject* self)
 
 OUString val2str( const void * pVal, typelib_TypeDescriptionReference * pTypeRef , sal_Int32 mode )
 {
-    OSL_ASSERT( pVal );
+    SAL_WARN_IF( !pVal, "pyuno", "pVal != NULL" );
     if (pTypeRef->eTypeClass == typelib_TypeClass_VOID)
         return OUString("void");
 
@@ -124,7 +124,7 @@ OUString val2str( const void * pVal, typelib_TypeDescriptionReference * pTypeRef
         buf.append( "{ " );
         typelib_TypeDescription * pTypeDescr = 0;
         TYPELIB_DANGER_GET( &pTypeDescr, pTypeRef );
-        OSL_ASSERT( pTypeDescr );
+        SAL_WARN_IF( !pTypeDescr, "pyuno", "pTypeDescr != NULL" );
 
         typelib_CompoundTypeDescription * pCompType = (typelib_CompoundTypeDescription *)pTypeDescr;
         sal_Int32 nDescr = pCompType->nMembers;

で、make。フルビルド済ませてあるので、今度はそんなにかからないです。本当はmake checkでユニットテストも通すべき(そもそも、このコードにユニットテスト書くべき)なんですが、私が作業したときのmasterはなぜかmake checkすると通らない(よくあることのようです ^^;)ので、うーんと悩んだ末そのまま。

とりあえず、ローカルの作業ブランチにコミットしておきます。コミットコメントはこんな感じ。バグ修正のときはバグ番号を書くのが決まりです。

fdo#43157 - Clean up OSL_ASSERT, DBG_ASSERT
    
- Clean up OSL_ASSERT

gerritの設定

LibreOfficeでは、Googleが開発したソースコードレビューシステムGerritを使用しています。gerritの持つgitリポジトリにpushすると、その上でdiffを確認しつつ、レビューコメントがついたり質疑応答したりできるシステムです。ビルドbotも走っていて、そのコミットビルドがぶっ壊れないかも確認してくれます。超便利。MLにパッチ投げて議論して、ってのもいいけど、gerritを使うほうが推奨されてる……はず。

ので、まずはgerritの設定するところから始めます。TDF WikiのGerritの解説ページを見ながら。

最初は https://gerrit.libreoffice.org にてアカウント作成ですが、これは大昔にやったことがあったので省略。Googleアカウントがあれば簡単だった記憶が。で、アカウント設定でgit push用のssh公開鍵を設定しておきます。もちろん専用の鍵ペア作ってもかまいません。

次に、解説ページによると、

You must set your username to match your freenode IRC nick (see 'Username' in your gerrit account settings).

とあるので、freenodeのNick登録しなきゃいけません。IRC技能が低い私はここでしばらく調べまわったのですが、自分 irssi 使ってるので、

/msg NickServ REGISTER <password> youremail@example.com

しといて、

/NETWORK ADD -autosendcmd "/^msg nickserv id <username> <password>;wait 2000" Freenode

でFreenodeのNickとGerritのアカウント名を合わせればいい……のかな。今んとこそうしてます。ただ、irssi常時上げてるわけじゃないし、irssiもnotify上げてくれるわけじゃないので実のところIRCマトモに使えてない。なんかいい方法ないすかね。ま、それはまた別の話。

で、先の解説ページに戻りまして、手動セットアップします。まずは.ssh/configに:

Host logerrit gerrit.libreoffice.org
       IdentityFile /path/to/your/private-key
       User <username>
       Port 29418
       HostName gerrit.libreoffice.org

を追記。秘密鍵のところは、さっきGerritに登録した公開鍵とペアになる鍵を指定しましょう。当たり前ですね。

で、LibreOfficeのソースディレクトリに移動しておいて、

$ ./loggerit test

とやって、"Your gerrit setup was successful!" と表示されればOK。

さてgitにpush先を指定しておきましょう。

$ git config remote.origin.pushurl ssh://logerrit/core

これで準備完了です。


いよいよpush……の前に

なんだかんだで、ソースコードを修正してからココらへんの設定をのたのたやってたので、まる2日ぐらい経ってたのかな?

LibreOfficeは進化が早いソフトウェアなので、2日も経つと当然masterには大量に変更が溜まってる。まあ、ビルド通らなくなるとは思えないけど、もし同じファイルを修正した人がいたりしたら悲しくなるので、念のためmasterを最新にして、自分の変更をその先頭にぶら下げるようにしたい。

私、git力低いので、ホントはこういうときってrebaseでできるのかもなあって思いつつ、悩んだ末masterをpullして最新にした後新たにブランチ切って、そこに作業ブランチの変更をcherry-pickするようにしました。いいのかなあ、こんなやり方で。

$ git checkout master
$ git pull origin master
<ぞろぞろとファイルが降りてくる>
$ git checkuout work
$ git log --oneline | head
<先頭は自分のコミットなのでハッシュ値を見ておく>
$ git checkout -b fdo43157 master
$ git cherry-pick <さっき確認したハッシュ値>
$ make
<ちゃんとmake通ってできたものが動くこと確認>

Gerritにpush

ドキドキしながらpush……してもいいのですが、いきなり投げるのはちょっと怖いので、なんか稽古場があった気がする……って読んだら、

<ローカルブランチ名>:refs/for/master の代わりに <ローカルブランチ名>:refs/drafts/master に投げるとドラフトとしてコミットできるよ

って書いてある。これはドラフトに一旦おいて議論するみたいな使い方をするところなのかなってのも思うのですが、まあ、突っ込んですぐ消すなら大丈夫かな、と……。

で、今の場合は:

$ git push origin fdo43157:refs/drafts/master

すると、「このURLに登録されたよ!」って出るので、そこを見に行くと、draftsにちゃんとコミットがあることが確認できる。

ホントは、このdraftsにadd reviewerしてレビュープロセスに移動するのが正しい使い方らしいのですが、誰をレビュアーにするとかプロセスがわかんなかったので、一度abandonして再度pushすることにしました。いいのかな。不安なので、みなさんはポリシー各自確かめてね。とにかくうりゃっとpush!

$ git push origin fdo43157:refs/for/master

すると、こんな感じで登録されます。あ、これレビューコメント色々もらって修正したやつなので最初とは変わってます。古いパッチも見られますけどね。最初にpushしたのはPatch 1。

pushしてしばらく経つと「ビルドbotが起動したよ」「ビルド成功したよ」とメールが来ます。ほっと一安心。あとは人間のレビュアーの登場を待ちます。


ライセンス宣言

おっと、ライセンス宣言もしないといけません。開発者・貢献者リストのページにあるとおり、開発者メーリングリストに:

All of my past & future contributions to LibreOffice may be

licensed under the MPLv2/LGPLv3+ dual license.

というメールを投げる必要があります。著作権譲渡や契約の締結などは不要です。めっちゃカジュアルですね。

本当は先の開発者リストWikiに自分の名前書かなきゃらしいのですが、このWiki超重要なので間違って編集したら怖いな、いわれたらやろうということで一旦保留*6


レビュー指摘反映

さて、ドキドキしながら待ってたら、コメントがつきました。まずはTakeshi Abeさん*7からの二つのコメント。

  • SAL_WARN_IFの第三引数は「こういう状態だからおかしいよ」ってものをログに残すものだから、条件逆じゃない?
  • SAL_WARN_IFの第二引数に指定するログエリアはinclude/sal/log-areas.doxに定義しないとダメだよ。

二番目の指摘は完全に見落としだったんですが、最初の指摘は……私はなにを考えていたんでしょう。まあ、勘違いとしかいいようがないですね。お恥ずかしや。

次の指摘はバグ#43157のreporterでもあるStephan Bergmannさんによるもの。

  • これ両方とも、NULLだったら後ろ死ぬからワーニングじゃなくてアサートにすべきじゃない?

……むぐ。そりゃそうだ。何を考えていたんでしょうワタクシ。

言い訳するとSAL_WARN_IFとかを定義してるinclude/sal/log.hxxにはアサートに当たるものがなかったのと、同じバグ票に対するこちらのコミットだとOSL_ASSERTをSAL_WARN_IFに書き換えているコードがあったからというのはあるんだけど、それはプログラマー的には思考停止であって言い訳にもならん。あかんわ。

で、間抜けな私はあれ、アサートのマクロってなくない?どれ使えばいいんだろ?と動揺して、日本語メーリングリストで質問したら、「いやいやC++のassert()でいいでしょう」ってCalcハッカーのKohei Yoshidaさんから教えてもらった。……あ。そうだね。そりゃそうだ。というか、バグ票にも " To assert invariants of the code (that can only be violated if there are programming errors) use standard C/C++ assert." って書いてあるじゃんかー。頭悪いな。

ということで、assert() に直した奴を再度コミット。--amend でコミットするとChange-Id:を見て、同じgerritエントリーに登録してくれるとな。素晴らしい。ので、それをpush。えいっ。これがPatch 2。


再びレビュー待ち……そして。

またビルドbotからのメールを受け取ってドキドキしながら待ってたら、「いいみたいだね、でもassert()使うなら #include <cassert> を明示的にするほうがいいと思うな。この場合は他のヘッダでincludeされてるから問題ないけどね」って指摘をもらった。けど、それは別途直しておくよってことでパッチacceptされて、無事コミットは取り込まれました。わーい!

http://cgit.freedesktop.org/libreoffice/core/commit/?id=922f2005f34589e60969be3f2bf74e4af58e2e69


感想

  • 仕組みはいろいろ良くできてる。ドキュメントが少し散らかってる感じはあるけど、ちゃんと読めばわかる。
  • Gerritすごく良くできてて感動。
  • みなさん大変親切でありがたや。お世話になりました。
  • 次はもうちょっと機能や不具合に関わる修正に挑戦したいな。


参考資料:Tomofumi Yagiさんの発表資料 (2014.11.05追記)

LibreOfficeへのコミットについては、Tomofumi Yagiさんのスライドが非常に参考になるので紹介しておきます。私が書かなかったOpenGrokなどについても説明されていて、必読です。

*1:あーもちろん、翻訳やアウトリーチプロモーションやその他の活動もやっぱり大事なんですよ。わかりやすいように極端な言い方をしてるだけで。

*2:タイトルの通り、東京エリアDebian勉強会の皆さんには大変お世話になりました。またコラボしましょう!

*3LibreOfficeはgitで管理されており、誰でも1行からコミット可能なので、例えばApache OpenOfficeのように特定のコミッターという権限を持つ人がいるわけではありません。コードが取り込まれれば誰でもコミッターです。

*4:BernのHackNightで挑戦したのがうまく行かなかったのはこれが原因。

*5:あ、間違ってるってのは知ってるので、ちょっと待ってね。

*6:結局は、後述のStephenさんがやってくれました。

*7LibreOffice日本語チームのメンバーで、アクティブにコミットされている安倍さん。

2013-04-27

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 とオプションとしていくつか)、PostScriptPDF、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:

  1. How to build the PWG Job Ticket backend.
  2. How to build the test suite
  3. How to run the test suite
  4. 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 を自動生成する仕組みです。

OpenPrintingOpenPrinting 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

Code License: GPL/LGPL/Public Domain

訳者からの補足

これ Hin-Tak が随分ご執心で、毎回 GSoC に出して毎回ボツってるという素敵なテーマです。はっきりいって元 Windows プリンタードライバーの開発者としては ddiwrapper というアイディアには割と懐疑的で、あの複雑怪奇な動きを模倣することができるわけがないと思ってます。まあでも、もし万が一うまく行っちゃったりしたら革命的なので、応募してうまく実装できちゃったらヒーローになるでしょうねえ。できたころには WIN32 が滅びてるとかなければよいですがw


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.

期待:CairoInkscape のコードが必要な変更を受けた上でアップストリームにプッシュされること。理想的なのは 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) が試みて放置されてる奴。

2013-02-24

LibreOfficeマーケティングBlogのインタビューに答えましたよ

Interview Of Naruhiko Ogasawara, A Localizer From Japan

英語が死ぬほど苦手なぼくが英語でインタビューを受けるとかありえんわーという感じなのですが、まあ、ぼく自身と言うより日本コミュニティのプレゼンス向上の一助になればいいなと思って引き受けました。まあ、載せてもらったということは、それなりに面白いと思ってもらったということでしょう。だといいな。

中学生なみの英語で恥ずかしいですし、それを逆翻訳してさらに恥を晒すのもどうかと思いますが、これも記念ということで書いておきます。

LibreOffice は人々の働きなしでは存在し続けられません。そんなわけで、あなた自身についてちょっとだけお話ください。

私はLibreOffice日本語チームのメンバーです。このチームは日本のコミュニティの裏方として働いています。翻訳を牽引したり、英語が出来ない人の代わりにバグを報告したり、日本のFLOSSイベントに参加したりです。

チーム内での私の主な役割はLibreOfficeの主にUI、たまにWikiの翻訳です。Pootle *1 の日本グループの管理人でもあります。今はアウトリーチにすごく関心があります (この点については後で述べます)。あと多分これは特別だと思いますけど、私は「プリンター人間」で、印刷の未来にすごく興味があります。デスクトップアプリケーション (LibreOffice みたいな) から印刷するだけでなく、モバイルデバイスを使ったり、クラウドサービスから印刷したり、そんな世界です。将来は LibreOffice の印刷関係の機能向上にも関わりたいです。


他に参加しているソフトウェアプロジェクトにはなにがありますか?

GNOME と Ubuntu (どちらも主に翻訳)、それから OpenPrinting という印刷技術の標準化団体のメンバーです。


どこに住んでますか?

東京のすごく東の方です (葛飾区)。


LibreOffice をやってないときは何をやってますか?

最新の FLOSS 技術についての調査が仕事です。NoSQL とか、プライベート IaaS プラットフォームとか、いろいろ……もちろん LibreOffice も。

プライベートな時間だと、本読んだり、PC の前に座って Twitter やってたり……あ、最近ヨガ始めました。あれは楽しいですね。

カヤックで川下りするのがすごく好きです。NZ と US も入れて 60 本ぐらい川を下りました。パドリングは最高です :)


いつこのプロジェクトに時間を費やしてますか?

翻訳と Facebook ページの管理についてだと、平日のオフタイムが多いですね。私が主催してる LibreOffice 勉強会 (このあと出てきます) も平日の夜に行なっています。多分週に 10 時間ぐらいですかね。


LibreOffice の名前をどうやって知りましたか?

友達*2LibreOffice の (そして昔は OpenOffice.org の) キーパーソンだからです。


なぜプロジェクトに参加しようと思ったんですか? LibreOfficeはあなたの母語 (日本語) では普及してますか?

上で述べた友達に頼まれたからです。そのとき、このコミュニティの人間はなんてアクティブで、LibreOffice への愛にあふれているんだろうということに驚きました。「うわ、すごいいいコミュニティじゃないか!」って思いました。だから今でもこのコミュニティに時間を割いているんです。

日本では、LibreOffice も大きな地位を占めるようになってきたとは思います。けれど依然として「オープンオフィス」という名前が LibreOffice よりも大きいです。無償のオフィススィートがほしいなあと思ったら、まずその人は「オープンオフィス」でグーグル検索するでしょう。


最初に LibreOffice にした貢献はなんですか?

私は「プリンター人間」なので、印刷関係の UI メッセージをチェックして、改善提案を送ったのが最初です。


それからどんな活動をしてきましたか?

翻訳に関しては、印刷関連からそのエリアを UI 全体に広げ、さらに Wiki やその他の翻訳もやるようになってきました。

今私が一番重要だと思っている仕事は、私たち自身の (LibreOffice というタイトルのついた) イベントを日本で企画し、それをグローバルに伝えることだと思っています。

最初に、毎月一回の LibreOffice の集まり「関東 LibreOffice 勉強会」を始めました (関東というのは東京周辺の地域のことです)。この会では使い方のハウツーの交換から、開発者入門的な内容まで広いテーマを扱いたいと思っています。

それから、二つの Facebook ページの管理人をしています。「Facebook(日本語)」は LibreOffice に関わるすべての人々向けのページで、LibreOffice について日本語で話しあうためのところです。もうひとつの「LibreOffice勉強会の会」は日本で LibreOffice に関するイベントを主催している人たちが互いにイベント主催のノウハウやその他を交換するページです。

あとこれはとても重要だと思ってるんですけど、日本のコミュニティはグローバルに対して自分たちがどれだけアクティブか、うまくいったことはなんで問題はなにか、ということをシェアすべきだと考えています。


LibreOfficeの翻訳に参加してみたいという人に一言、忠告やアドバイスはありますか?

英語を恐れないでください。もしよくわからないUIがあったら、その翻訳は多分間違ってます。それを教えてください。私達の仲間入りの第一歩です。査読はいつでも歓迎です。

そして、LibreOfficeコミュニティはとても活発で、愛に満ちた、ステキな人たちがたくさんいる、とても参加しやすいコミュニティですよ。


LibreOffice の将来に対する展望、あるいはこういうことに関わってみたいということはありますか?

今一番関心があるのは、どうやって日本において、FLOSS を知らない、ギークでない人たちに LibreOffice の素晴らしさを伝えるかということです。そういう人達はほとんど MS Office しか知りませんし、たまには「オープンオフィス」を知っている人はいますが、LibreOffice を知っている人はとても少ないです。そういう人たちとつながりを持って、彼らがオフィススィートに必要としているものはなんであるかを知り、それをグローバルに伝えられればと思います。

大企業や地方自治体での MS Office から LibreOffice への移行ももちろん大事で、そのためには日本の LibreOffice のエコシステムの中にちゃんとしたサポート企業が必要だと思いますが、これはコミュニティの人間としての私の範囲外ですね……

さておき、関心がある別の視点はコードを書くことです。というのは日本ローカルの要求を LibreOffice に入れ込むのに一番簡単な方法はコードを書くことのはずですが、日本においてはコードが書ける人がとても少ないからです。なので私自身開発者になりたいですし、若い開発者の育成もできたらと思います。

*1:訳注:LibreOfficeの翻訳プラットフォーム

*2:訳注:友達とカジュアルに言わせてもらうにはおこがましいぐらい尊敬してますが、いくやさんのことです。

2011-02-28

Notes DB で Testing Framework を活用するにはどうしたらいいのかな?

以下妄想。まとまっていないので「与太話」扱いで。


前振り

えーと Notes の開発言語 LotusScript の xUnit である LSUnit ってのがあります。

同じ名前のヤツで Java から外部でゴニョゴニョする奴があるみたいなんですが、私が使ってる奴は昔 http://amano001.at.infoseek.co.jp/LSUnit/ で公開されていたヤツで、LotusScript で書かれており、フォーム二個作ってファイルインポートするだけっていう気軽さが気に入ってます *1

が、気に入っているのはいいとして、なんか上手く使えないんですよねぇ。

前に LotusScript で小さな Wiki エンジンを書くという愚かな試みをやったことがあって、そういう外界から切り離されたヤツだとテストも上手く行くんですけどね。

では一般に、なにがテストのジャマをしてるのかっていうと、

Notes の設計要素「フォーム」は文書の雛型であり、それぞれのフィールドの定義もするのだけど、同時に見え方や操作(ボタンなど)も定義するので、どうしても UI の要素が出てきてしまい xUnit の得意分野である自動テストに分離できない。

という一点に尽きるんじゃないかと思うのでする。

じゃあそこを何とかするには、どういう DB 設計をすればいいか、と妄想してみた。


アクションを「見た目」に書かない

まぁこれは xUnit がどうこう以前に基本中の基本ですが……。

Notes においては「フォーム」とか「ビュー」という設計要素に「ボタン」とか「アクション」というのが配置できて、そのクリックイベントのハンドラを埋め込めるわけですが。

ここに処理をいきなり書いてしまうと、LSUnit による自動テストができない。

だってそのテストを発火させるためには「ボタンクリック」という操作を必要とするわけだから。当たり前ですよね。

だからイベントハンドラには関数/サブルーチン呼び出しだけ書き、関数/サブルーチンの呼び出しは「スクリプトライブラリ」という設計要素に追い出す。

これならファイルにエクスポート/インポートできるから、バージョン管理システムも使えるし嬉しいよね。


コンテキストに依存するもの (workspace / session / ……) の扱い

んで、Notes には「今のコンテキストに依存する」ものがたくさんあります。

例えば今の表示要素(ワークスペース)を意味する NotesUIWorkspace (以下 ws) とか、今のセッション情報を表す NotesSession (以下 session) とか。そしてその要素として ws.CurrentDocument (:= NotesUIDocument) とか session.CurrentDatabase (:= NotesDatabase) とかあって、さらにその要素として……とかあるわけで。

で、この手の「今のコンテキストに依存する」巨大なデータ構造を受け渡しして処理を回していると、どこでどのデータを弄ったのか訳が分からなくなる。副作用の固まり。あーもうやだやだ。

ということで、入り口はしょうがないとはして、最終的に末端の関数/サブルーチン群は本当に必要なパラメータを取り出して、それを元に呼び出すようにしないと。

関数/サブルーチン内部で、

  Dim ws As New NotesUIWorkspace

したり、それをずるずると持ちまわるのは止めないとダメですね。

これは関数/サブルーチンの再利用性向上にもつながるし、自動テストの観点からしても、「同じコンテクストを作ってあげる」より「同じパラメータだけ用意する」方がはるかに楽ですからね。


モデルとビューの分離

Notes でテストを書こうと思うと割と悩むのがこれ。あ、この「ビュー」ってのは下で出てくる Notes の設計要素じゃなくて、一般に MVC でいうところのビューを指します。

Notes の文書って持つべきデータとその見た目を両方持つのが設計思想なんですよね。そして、制御にしか使わない情報を非表示属性で隠すと。

また、文書の選択に使われる「ビュー」っていう設計要素 (以下 Notes ビュー) も、SELECT 文を Notes ビューごとにハードコードしちゃうし、見た目も規定するんでイロイロとテストで使うにはめんどいことがある。

つーことで、きっぱり「見た目に使う文書」と「制御に使う文書」を分離したらどうだろう、と思ったのだ。

前者はまさしく一般的な意味としてのビューとして用い、例えば「内部情報の最終更新時刻を分かりやすく表示する」とかそういうロジックはこっちに押しこむ。さっき書いたボタンとかの設計要素もこちら。値をテキストボックスで見せるのか、プルダウンメニューで選択するのか、チェックボックスにするのか、とかいうのもこっち。

後者は情報をただ情報として持つ。どう見せるかは意識しない。

実現の方法だけど、多分サブフォームを一個作って、そっちに「モデル」側の情報を全部押しこむ。

モデル側のフォームにはサブフォームをぺったん貼るだけ。

ビュー側のフォームはサブフォームを貼るのは同じだけど非表示属性にしておいて、実際に見せる/値を設定するフィールドについては、サブフォームのフィールドから値をもらってきてゴニョゴニョする。

んで、両者の値の交換 (アップデート) はそれぞれの PostSave() イベントでやる、とかそんな感じかなぁ。

Notes ビューの方も、設計で使うヤツはモデル側の文書を SELECT するようにしちゃって、もう見た目は考えない、と。

xUnit の setUp() で Notes の文書を作るときって、Notes 文書って見た目の完備性を考えなきゃいけないからけっこうめんどうで、こういうやり方をすれば少しはコストが減るんじゃないかな?


まとめ?

Web アプリケーションとかも、DB にアクセスするレイヤ、HTML を生成するレイヤはテストが難しいから、その分離ノウハウとかどっかにあると思うんですが、Notes についてはどうやるんだろう、という妄想でした。


もう作っちゃったDBについてはそれこそテスト書いてないので、テストを書きやすくするためにリファクタするとかおっかなくてできないんだけど、一から設計するのであればこういうことを考えてみようかな?

*1:が、Infoseek のサービス終了に伴って上記はデッドリンクになっちゃいました。今更 LS じゃないってことなんだろうなぁ……。

2010-12-24

Windws Server 2008 R2 の Hyper-V と VMware ESXi 4.1 を一台のマシンで無理やり運用する

こんなことしたい人ってあんまりいなさそうだけど、「仮想環境を動かすことそのものが目的*1」な理由があって、そんなん簡単じゃーん、と思ったらいがいとハマったのでメモしておきます。


制約事項

  • PC は一台しかない
    • Core2Duo、メモリ2GB
    • ハードディスクも増設できない。一台だけ
  • USB スティックは手持ちの2GBを利用

結論としての手順

  1. BIOS のブート順を DVD -> USB -> HDD にしておく。
  2. USB ポートにメモリスティックを、DVD ドライブに ESXi の CD を入れてブート。
  3. ESXi のインストーラが起動するので、インストール先に USB メモリを選んでインストール
  4. インストールは無事完了するので、CD を抜いて再起動。
  5. ESXi が起動するので、とりあえず基本設定を済ませておく。
    • root のパスワードと、固定 IP の場合は IP アドレスぐらいかな。
  6. クライアント PC にインストールしておいた VMware vSphare Client*2 を起動して、仮想イメージの置き場となる datastore をハードディスク上に作る。このとき、後々 2008 Server R2 をインストールして、Hyper-V の仮想イメージを配置できるだけの容量を残しておくことが重要。
  7. 一度シャットダウン。
  8. USB メモリを引っこ抜いて 2008 Server R2 をインストール。間違えてさっき作ったdatastore に上書きしないように注意 (^^;)
  9. インストールが終わったら、「サーバーの種類の追加」(だったっけ?) で Hyper-V を追加する。
  10. これで、「USB を差して起動したら ESXi」「USB を抜いて起動したら 2008 Server R2」の環境が出来上がる。

なんか昔、BSD 256 本で、Windows と *BSD のマルチブート環境を作る方法でブート FD を作る方法が紹介されてたけど、それに似ているっちゃあ似ているな。


ハマったポイント

  • 最初は ESXi をどーんと入れて、Ubuntu かなんかの Live CD でサイズ縮めて Windwos いれればいいんじゃね? と思ったら、ESXi がプライマリパーティションを沢山作るので新たにパーティションを作ることができずに断念。
  • かといって 2008 Server R2 から先に入れると、ESXi は頑としてハードディスク一本丸々欲しがるので、これもダメ。
  • 私の調べた範囲だと、一本のハードディスクでマルチブートをする方法が見つけられなかったし、そんなことではまってるヒマがなかったので、USB ブートに逃げた。
  • USB ブートの時でも、datastore を作るときにはどうやらシリンダの先頭からをどうしたって欲しがるらしいので、先に 2008 Server R2 を入れたらダメ。
    • だから上の手順だと、datastore を作ってから 2008 Server R2 をいれているのです。

もしかしたらそんなことしないでもうまくいくヨ、という知恵があるかもしれないけど、まあとりあえず上手くいったし、「USB メモリが刺さっているか否か」でどっちが動いてるかが一目瞭然なのは却って分かりやすいかなってことで、まあこれで。

*1:例えばあるディストリビューションがある仮想環境で動作するかを確認したい、とか。

*2:ご存知のとおり http://<ESXi の IP>/ で入手できます。