ククログ
名古屋Ruby会議03：Apache ArrowのRubyバインディング（6） #nagoyark03
前回はGObject Introspectionでのオブジェクトの寿命の扱いについて説明しました。今回は戻り値のオブジェクトの寿命について説明します。実際に動くバインディングはkou/arrow-glibにあります。
戻り値のオブジェクトの寿命
一般的に戻り値のオブジェクトの寿命には次のパターンがあります。
- 所有権は関数実行側にあるパターン：戻り値のオブジェクトが必要なくなったら戻り値を受け取った側が責任を持って解放する。
- 所有権は関数側にあるパターン：戻り値を受け取った側は解放してはいけない。
話を単純にするために、戻り値のオブジェクトとして文字列（char *）を考えてみましょう。
strdup(3)（引数の文字列をコピーして返す関数）は前者（所有権は関数実行側にあるパターン）です。strdup(3)の戻り値はstrdup(3)を呼び出した側が責任を持って解放しなければいけません。
char *copy;
copy = strdup("Hello");
free(copy); /* 呼び出し側がfree()する。 */
getenv(3)は後者（所有権は関数側にあるパターン）です。getenv(3)の戻り値はgetenv(3)を呼び出した側が解放してはいけません。
char *path;
path = getenv("PATH");
/* free(path); */ /* 呼び出し側がfree()してはダメ！ */
これが基本です。
ただし、前者の「所有権は関数実行側にあるパターン」にはもう少しパターンがあります。それは戻り値のオブジェクトがコンテナーの場合です。コンテナーというのは配列・リスト・ハッシュテーブルなどのように複数のオブジェクトを格納するオブジェクトのことです。
コンテナーの場合は、次のパターンがあります。
- コンテナーの所有権のみ関数実行側にあるパターン
- コンテナーの所有権もコンテナーの中のオブジェクトの所有権も関数実行側にあるパターン
コンテナーの所有権のみの場合はコンテナーのみを解放します。
GObject Introspectionでの戻り値のオブジェクトの寿命の指定
GObject Introspectionではこれらのそれぞれのパターンを指定できます。指定すると後はGObject Introspection（を使ったバインディング、Rubyならgobject-introspection gem）が適切に寿命を管理してくれます。
パターンはそれぞれの関数のドキュメントで指定します。
次の関数は新しくGArrowArrayオブジェクトを作って返す関数です。新しく作ったオブジェクトの所有権は関数呼び出し側にあります。そのため、「所有権は関数実行側にあるパターン」です。
/**
* garrow_array_builder_finish:
* @builder: A #GArrowArrayBuilder.
*
* Returns: (transfer full): The built #GArrowArray.
*/
GArrowArray *
garrow_array_builder_finish(GArrowArrayBuilder *builder)
{
auto arrow_builder = garrow_array_builder_get_raw(builder);
std::shared_ptr<arrow::Array> arrow_array;
arrow_builder->Finish(&arrow_array);
return garrow_array_new_raw(&arrow_array);
}
ポイントは次の箇所です。Returns:が戻り値に関する情報のドキュメントという意味で、(transfer full)が「所有権は呼び出し側にある」という意味です。
/**
* Returns: (transfer full): The built #GArrowArray.
*/
「所有権は関数側にあるパターン」も見てみましょう。
次の関数はフィールド名を返す関数です。フィールド名はフィールドオブジェクトに所有権があるので関数呼び出し側は解放してはいけません。（gcharはGLibが提供しているchar型です。charと同じです。）
/**
* garrow_field_get_name:
* @field: A #GArrowField.
*
* Returns: The name of the field.
*/
const gchar *
garrow_field_get_name(GArrowField *field)
{
const auto arrow_field = garrow_field_get_raw(field);
return arrow_field->name.c_str();
}
ポイントは次の箇所です。戻り値の型にconstがついている場合はGObject Introspectionは所有権は関数側にあると推測します。そのため、明示的にReturns: (transfer none):と書く必要はありません。
const gchar *
「コンテナーの所有権のみ関数実行側にあるパターン」も見てみましょう。
arrow-glibでは使っていないのでGTK+にある関数を持ってきました。
/**
* gtk_print_backend_load_modules:
*
* Returns: (element-type GtkPrintBackend) (transfer container):
*/
GList *
gtk_print_backend_load_modules (void)
{
/* ... */
}
ポイントは(transfer container)です。これでコンテナーの所有権のみ関数呼び出し側にある、ということを指定します。
（(element-type GtkPrintBackend)はコンテナー内の要素の型を指定しています。）
最後に「コンテナーの所有権もコンテナーの中のオブジェクトの所有権も関数実行側にあるパターン」を見てみましょう。
/**
* garrow_record_batch_get_columns:
* @record_batch: A #GArrowRecordBatch.
*
* Returns: (element-type GArrowArray) (transfer full):
* The columns in the record batch.
*/
GList *
garrow_record_batch_get_columns(GArrowRecordBatch *record_batch)
{
const auto arrow_record_batch = garrow_record_batch_get_raw(record_batch);
GList *columns = NULL;
for (auto arrow_column : arrow_record_batch->columns()) {
GArrowArray *column = garrow_array_new_raw(&arrow_column);
columns = g_list_prepend(columns, column);
}
return g_list_reverse(columns);
}
ポイントは(transfer full)です。(transfer full)はコンテナーなオブジェクトにもそうでないオブジェクトにも使えるということです。
まとめ
GObject Introspectionでの戻り値のオブジェクトの寿命について説明しました。次回はインターフェイスについて説明します。
Groonga Meatup 2017：Groonga族2016 #groonga
2017年2月9日（年に一度の肉の日！）にGroonga Meatup 2017が開催されました。ここでGroongaとMroongaとPGroongaの2016一年間での進化の様子を紹介しました。最近のGroonga・Mroonga・PGroongaの情報をざっと把握できるのでご活用ください。
関連リンク：
内容
2016年はGroonga・PGroongaの改良が多く、Mroongaの改良は少なめでした。ただ、MroongaはGroongaを使っているので、Groongaの改良（の多く）はそのままMroongaでも利用できます。そのため、Groonga・PGroongaだけでなくMroongaも進化しています。
Groongaの大きな改良はこのあたりです。
- 検索の高速化（アップグレードするだけで、ケースによっては1.5倍から2倍速くなる）
- ウィンドウ関数をサポート（データ分析に活用しやすくなった）
- あいまい検索をサポート（オートコンプリートで便利。参考：Groongaのパトリシアトライを使って高速なあいまい検索を実装した - CreateField Blog）
- 多段ドリルダウンをサポート（データ分析・UIの作成に便利。参考：Groonga 6.0.2から多段ドリルダウンが利用可能に - CreateField Blog）
- Zstandardによるカラム圧縮をサポート（zlibと同程度の圧縮率なのにzlibより数倍速い。データのサイズに応じて動的に圧縮するかどうかを切り替える改良も入ったので、デメリットなしでカラム圧縮機能を利用できるようになった。）
Mroongaの大きな改良はこのあたりです。
- FOREIGN KEY制約をサポート
- マルチカラムインデックスの更新性能劣化を解消
*SSプラグマを追加（MATCH AGAINSTないでGroongaの検索条件を使える。Groongaの検索条件では複数インデックスを使えるのでMySQLで検索するよりも圧倒的に速くなる。）
PGroongaの大きな改良はこのあたりです。
- ストリーミングレプリケーションをサポート
- 検索の高速化（PostgreSQLがより適切な実行計画を選べるように、PostgreSQLにより精度の高い情報を提供するようになった）
- Zstandardによるカラム圧縮をサポート
- 各種便利演算子を追加（類似文書検索演算子・前方一致検索演算子・前方一致RK検索演算子）
他にもいろいろあるのでぜひスライドも確認してください。
まとめ
Groonga Meatup 2017で2016年のGroonga族の様子を紹介しました。
なお、今回のGroonga Meatup 2017は東京で開催しましたが、今月、名古屋と大阪でも開催されるので近辺の方はぜひお越しください！
- 2017-02-12（日）：Groonga Meatup名古屋2017 @ Misoca
- 2017-02-26（日）：Groonga Meatup大阪2017
他の発表については以下を参照してください。
- Groonga Meatup 2017 - Togetterまとめ
- Dockerイメージで誰でも気軽にMroonga体験 by @yoku0825
- django_pgroonga by @atsuoishimoto
- Groonga Meatup 2017 - Mroonga/Groonga SELECTイロイロ by @muratapo128
おまけみたいな書き方になってしまいますが、同日、初心者向けのMroongaの電子書籍Groongaではじめる全文検索がリリースされました！初心者の人がくじけずに始められるようにできるだけ短い内容（約30ページ！）で動くものが作れる、という内容になっています。具体的にはPHPでMroongaを使ってPDF検索システムを作っています。全文検索をしたいけどどこから始めればいいかピンときていない…という方はまずはこれを読んでみてください。
名古屋Ruby会議03：Apache ArrowのRubyバインディングをGObject Introspectionで #nagoyark03
2017年2月11日に名古屋Ruby会議03が大須演芸場で開催されました。ここで咳さんの並列処理啓蒙活動話の前座の1人として話してきました。内容は、Apache ArrowとGObject IntrospectionとRroongaを活用すれば自然言語のデータ分析の一部でRubyを活用できるよ！、です。
関連リンク：
リポジトリーには今回のスライド内で使ったスクリプトも入っています。
内容
当初は以下にいろいろまとめていた通り、Apache Arrow・GObject Introspectionはどんな特徴でどういう仕組みでそれを実現しているかといったことも説明するつもりでした。
- 名古屋Ruby会議03：Apache ArrowのRubyバインディング（1） #nagoyark03
- 名古屋Ruby会議03：Apache ArrowのRubyバインディング（2） #nagoyark03
- 名古屋Ruby会議03：Apache ArrowのRubyバインディング（3） #nagoyark03
- 名古屋Ruby会議03：Apache ArrowのRubyバインディング（4） #nagoyark03
- 名古屋Ruby会議03：Apache ArrowのRubyバインディング（5） #nagoyark03
- 名古屋Ruby会議03：Apache ArrowのRubyバインディング（6） #nagoyark03
ただ、内容をまとめていく過程で、特徴や仕組みの説明が多いと大須演芸場で話すには勢いが足りないと判断しました。その結果、詳細をもろもろ省略したストーリーベースの内容にしました。そのため、↑の内容はほぼ使っていません。
ストーリーベースの内容にしたことで「あぁ、たしかにデータ分析の一部でRubyを使えるかも」という雰囲気は伝わりやすくなったはず（どうだったでしょうか？）ですが、詳細の説明を省略したので詳細が気になったまま終わった人もいるかもしれません。そんな人たち向けに詳細がわかる追加情報を紹介します。
Apache ArrowとApache Parquet
まず、Apache ArrowとApache Parquetの連携についてです。両者はどちらもカラムストアのデータについて扱いますが、Apache Arrowはメモリー上での扱い、Aapache Parquetはストレージ上での扱いという違いがあります。この違いのためにトレードオフのバランスが変わっています。詳細はThe future of column-oriented data processing with Arrow and Parquetを見てください。2016年11月にニューヨークで開催されたDataEngConf NYCでのApache Parquetの作者の発表資料です。
ざっくりとまとめると次の通りです。
- Apache Parquetはストレージ上でのカラムストアのデータの扱いなので、次の傾向がある。
- CPUを活用するよりもI/Oを減らすほうが重要（たとえば、データを圧縮するとI/Oは減る一方CPU負荷は増えてしまうが、I/Oを減らしたいので圧縮をがんばる）
- シーケンシャルアクセスが多い
- Apache Arrowはメモリー上でのカラムストアのデータの扱いなので、次の傾向がある。
- I/Oを減らすよりもCPUを活用するほうが重要（たとえば、CPUキャッシュミスが少なくなるようなデータ配置にする）
- シーケンシャルアクセスもあるしランダムアクセスもある
データの配置や高速化の工夫なども前述の発表資料で説明しているので興味のある人は発表資料も確認してください。
Apache ArrowとApache Parquetは連携できます。具体的に言うと、Apache ParquetのC++実装にはApache Arrowのデータを読み書きできる機能があります。これを使うとApache ParquetのデータをApache Arrowのデータとして扱うことができます。
GObject Introspection
GObject Introspectionに関する情報は次の記事を参考にしてください。
- 名古屋Ruby会議03：Apache ArrowのRubyバインディング（4） #nagoyark03
- 名古屋Ruby会議03：Apache ArrowのRubyバインディング（5） #nagoyark03
- 名古屋Ruby会議03：Apache ArrowのRubyバインディング（6） #nagoyark03
GObject Introspectionに対応するとバインディングを書かなくてもCライブラリーのテストをRubyで書けるようになります。Cライブラリーの開発を捗らせるためにGObject Introspectionに対応させるというのもアリです。（これも当初は話したかったけど省略した話題です。）
GObject IntrospectionのRubyバインディングであるgobject-introspection gemについてはここで少し補足します。
話の中で、GI.loadした後、よりRubyっぽいAPIになるように一手間かけるとグッと使いやすくなると説明しました。当日は次のようにエイリアスを使う方法だけを紹介したのですが、別の方法もあってそれを紹介することをすっかり忘れていました。
require "gi"
Arrow = GI.load("Arrow")
class Arrow::Array
def [](i)
get_value(i)
end
end
実はGObjectIntrospection::Loaderには定義するメソッド名を変える機能があります。上述のケースではエイリアスを作るのではなく、最初からget_valueを[]として定義するとよいです。
class Arrow::Loader < GObjectIntrospection::Loader
private
def rubyish_method_name(function_info, options={})
# 引数が1つで、メソッド名がget_valueならメソッド名を[]にする
if function_info.n_in_args == 1 and function_info.name == "get_value"
"[]"
else
super
end
end
end
このようにGObjectIntrospection::Loaderをカスタマイズするやり方には次のメリットがあります。
- 余計なメソッドを増やさない（今回のケースでは
get_value） - 新しく同じパターンのメソッドが増えてもエイリアスを追加する必要がない（たとえば、
Arrow::Array以外にget_value(i)なメソッドが増えてもバインディングを変更する必要がない）
この実装はRed Arrow（RArrowから名前を変更、由来はRubyは赤いからというのと西武新宿線の特急列車）にあります。open {|io| ...}を実現する方法も面白いので、GObject Introspectionが気になってきた方はぜひ実装も見てみてください。
まとめ
名古屋Ruby会議03で「Apache ArrowとGObject IntrospectionとRroongaを使って自然言語のデータ分析の一部でRubyを活用する」という話をしました。（使い方を間違っていましたが）はじめて小拍子を使ったり、はじめてマクラの後に羽織（？）を脱いだりできて、楽しかったです。貴重な経験になりました。声をかけてもらってありがとうございます。名古屋のみなさん（名古屋外からの参加の方も多かったですが）に楽しんでもらえていたなら、とてもうれしいことです。
今回の話では詳細をもろもろ省略しましたが、そのあたりに興味のある方がいたらぜひお声がけください。
また、クリアコードと一緒にRubyでデータ分析できる環境を整備していきたい！という方はぜひお問い合わせください。
macOSでCocoaのAPIからPDF印刷を行うには
はじめに
macOSでは印刷をプログラマブルに行うことができます。 また、macOSではAppKit, Core PrintingのAPIを用いて印刷を行うことができます。
通常はAppKitにあるNSPrintInfoやNSPrintOperationを使えばいいのですが、より細部の設定を変更するにはCore PrintingのAPIに触る必要があります。この記事ではAppKitの範囲でmacOSの印刷について見ます。
AppKitを用いた印刷
単純な例
AppKitで印刷するにはまず、NSPrintOperationクラスを作成する必要があります。また、必要に応じてNSPrintInfoクラス を作成する必要があります。
単純にNSViewを持つCocoaアプリケーションからビューを印刷するには以下のように NSPrintOperation クラスを用いて
- (IBAction)print:(id)sender {
NSPrintOperation *op;
op = [NSPrintOperation printOperationWithView:self];
if (op)
[op setShowPanels:YES]; // If set 'NO', printing modal dialog will not be shown.
[op runOperation];
else
// handle error here
}
のようにします。ここではselfがNSViewのインスタンスであることを要求しています。
NSPrintInfoを用いたより複雑な例
- (IBAction)print:(id)sender {
NSPrintOperation* op;
// Get NSPrintInfo
NSPrintInfo* printInfo = [NSPrintInfo sharedPrintInfo];
[printInfo setTopMargin:10.0];
[printInfo setBottomMargin:10.0];
op = [NSPrintOperation printOperationWithView:self printInfo:printInfo];
if (op)
[op setShowPanels:YES]; // If set 'NO', printing modal dialog will not be shown.
[op runOperation];
else
// handle error here
}
のようにすることで、NSPrintOperationクラスにカスタマイズを施したNSPrintInfoクラスのオブジェクトを渡すことができます。
NSPrintInfoへdictionaryを渡しPDFを出力する場合
NSPrintInfoは以下のようにNSDictionary, NSMutableDictionaryのオブジェクトを渡すことにより初期化できます。
NSPrintInfo* printInfo = [[NSPrintInfo alloc] initWithDictionary:printInfoDict];
これを利用すると、例えば以下のようなコードを用いてアプリケーションのビューをPDFへ出力できるようになります。
NSPrintInfo* sharedInfo = [NSPrintInfo sharedPrintInfo];
NSMutableDictionary* printInfoDict = [sharedInfo dictionary];
NSURL* jobSavingURL = [NSURL fileURLWithPath:@"日本語ファイル名.pdf"];
[printInfoDict setObject:NSPrintSaveJob forKey:NSPrintJobDisposition];
[printInfoDict setObject:jobSavingURL forKey:NSPrintJobSavingURL];
NSPrintInfo* printInfo = [[NSPrintInfo alloc] initWithDictionary:printInfoDict];
// Then, set Cocoa application's NSView or its subclass View
NSPrintOperation* op = [NSPrintOperation printOperationWithView:self printInfo:printInfo];
[op setShowPanels:NO];
[op runOperation];
ここで注意する点は
NSURL* jobSavingURL = [NSURL fileURLWithPath:@"日本語ファイル名.pdf"];
は正しく日本語も扱えるコードとなりますが、
NSURL* jobSavingURL = [NSURL fileURLWithString:@"日本語ファイル名.pdf"];
は日本語が正しくエスケープされずにファイル出力に失敗します。
まとめ
macOSでのAppKitのAPIを用いた印刷の仕組み、特にPDFへ出力するようにするにはどうするかをざっと解説しました。 この記事では詳しく取り上げませんが、NSPrintJobDispositionへは通常のプリンターに送ったり、Preview.appに送ったり、PDFとしてファイルに出力したりという印刷ジョブの大まかな行き先を指定するために用いる定数を指定することができます。 macOSの印刷のAPIは扱いに慣れると一貫性のあるAPIとなっていることがわかります。
GeckoエンジンにmacOSでprintToFileの機能を実装してみた話
はじめに
Geckoエンジンはクロスプラットフォームを標榜して作成されています。また、できるだけそのプラットフォームの特長を生かすため、そのプラットフォーム特有のAPIを使用するように作られている箇所もあります。印刷に関連するGeckoのコードももちろんプラットフォームごとに異なるAPIを呼ぶようになっており、通常使用する限りにおいてはどのプラットフォームも一様に印刷の機能を使用することができます。
今回の記事は nsIWebBrowserPrint に紐づいているprintという印刷のためのAPIにmacOSではPDFを印刷するのに必要な情報が渡っていなかった問題を解決した、という題材について書きます。
Geckoでの印刷の流れ
Geckoでは印刷をするときにプラットフォーム固有のAPIを使用する箇所とプラットフォーム非依存のAPIの箇所があります。
プラットフォームに依存するモジュールはサービス化されており、実行時に適切なContract ID(CID)を持ったモジュールがロードされる仕組みとなっています。このCIDはJavaScript側からも見え、アドオンやXULアプリケーション上でもこのCIDを用いて適宜必要なモジュールをロードしていきます。
印刷の流れを追うと以下のようになります。
nsDocumentViewer::Print(...)
-> nsPrintEngine::Print(...)
-> nsPrintEngine::DoCommonPrint(...)
-> printDeviceContext->InitForPrinting(aDevice, ...) // プラットフォームごとに別々のDeviceContextが作成されるのでそれを用いる
-> aDevice->MakePrintTarget(..)
-> nsPrintEngine::DoCommonPrint(...) //戻ってきたら印刷プレビューか印刷ジョブを行う
macOSのCocoaのAPIでの実装はwidget/cocoa以下に配置されています。
macOSでprintToFileが動かない問題のBug
macOSではnsIPrintSettingsServiceの関数のprintToFileへtrueを渡してもPDFヘ出力されないというBugが長年に渡って未解決です。詳細はMozillaのBugzillaのprintToFile is busted on Mac | Mozilla Bugzillaを参照してください。
macOSでGeckoのレンダリング結果をPDFへ出力できなかったのはなぜか
macOSでPDFへの出力をさせるのに必要な情報が上記Bugのパッチがコミットされる前のコードで設定されているかどうかを見ます。
macOSでCocoaのAPIからPDF印刷を行うには | ククログ にあるように、NSPrintSaveJob や NSPrintJobSavingURL のような値が設定されているかを探します。
ここで、macOSでPDF印刷ができないのはnsIPrintSettingsServiceのCIDを持つ https://hg.mozilla.org/mozilla-central/file/0ca553b86af3/widget/cocoa/nsPrintSettingsX.mm にこれらの値がないかどうかを調べれば原因が分かります。
探すと見事にそのようなことをしている箇所はありませんでした。 前の記事を元にGeckoに向けたパッチを書く必要があります。
GeckoのXPCOMで生成されたクラスのAPIの振る舞いをプラットフォーム固有にする
GeckoはXPCOMの技術を用いており、インターフェースはidlファイルで定義されています。 ここではnsIPrintSettingsのidlは https://dxr.mozilla.org/mozilla-central/source/widget/nsIPrintSettings.idl です。
GeckoはC++で書かれているため、nsPrintSettings クラスに定義されているメソッドで必要なものをoverrideしてやれば目的は達成できます。
そのため、SetToFileName(const char16_t *aToFileName) をoverrideします。
diff --git a/widget/cocoa/nsPrintSettingsX.h b/widget/cocoa/nsPrintSettingsX.h
--- a/widget/cocoa/nsPrintSettingsX.h
+++ b/widget/cocoa/nsPrintSettingsX.h
@@ -51,8 +51,10 @@ public:
void SetInchesScale(float aWidthScale, float aHeightScale);
void GetInchesScale(float *aWidthScale, float *aHeightScale);
+ NS_IMETHOD SetToFileName(const char16_t *aToFileName) override;
+
void SetAdjustedPaperSize(double aWidth, double aHeight);
void GetAdjustedPaperSize(double *aWidth, double *aHeight);
diff --git a/widget/cocoa/nsPrintSettingsX.mm b/widget/cocoa/nsPrintSettingsX.mm
--- a/widget/cocoa/nsPrintSettingsX.mm
+++ b/widget/cocoa/nsPrintSettingsX.mm
@@ -270,3 +275,30 @@ void nsPrintSettingsX::GetAdjustedPaperS
*aWidth = mAdjustedPaperWidth;
*aHeight = mAdjustedPaperHeight;
}
+
+NS_IMETHODIMP
+nsPrintSettingsX::SetToFileName(const char16_t *aToFileName)
+{
+ NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT;
+
+ NSMutableDictionary* printInfoDict = [mPrintInfo dictionary];
+ nsString filename = nsDependentString(aToFileName);
+
+ NSURL* jobSavingURL =
+ [NSURL fileURLWithPath: nsCocoaUtils::ToNSString(filename)];
+ if (jobSavingURL) {
+ [printInfoDict setObject: NSPrintSaveJob forKey: NSPrintJobDisposition];
+ [printInfoDict setObject: jobSavingURL forKey: NSPrintJobSavingURL];
+ }
+ NSPrintInfo* newPrintInfo =
+ [[NSPrintInfo alloc] initWithDictionary: printInfoDict];
+ if (NS_WARN_IF(!newPrintInfo)) {
+ return NS_ERROR_OUT_OF_MEMORY;
+ }
+
+ SetCocoaPrintInfo(newPrintInfo);
+ [newPrintInfo release];
+ return NS_OK;
+
+ NS_OBJC_END_TRY_ABORT_BLOCK_NSRESULT;
+}
ここまででPDFに出力するための関数の実装です。
まだmacOS向けにはoverrideする必要がある関数が残っています：
- 用紙の単位
- NS_IMETHOD SetPaperSizeUnit(int16_t aPaperSizeUnit) override;
- 拡大縮小倍率
- NS_IMETHOD SetScaling(double aScaling) override;
- 縦横
- NS_IMETHOD GetOrientation(int32_t *aOrientation) override;
- NS_IMETHOD SetOrientation(int32_t aOrientation) override;
- 余白（GeckoではMerginに加えてUnwritaebleMerginという設定値が存在する）
- NS_IMETHOD SetUnwriteableMarginTop(double aUnwriteableMarginTop) override;
- NS_IMETHOD SetUnwriteableMarginLeft(double aUnwriteableMarginLeft) override;
- NS_IMETHOD SetUnwriteableMarginBottom(double aUnwriteableMarginBottom) override;
- NS_IMETHOD SetUnwriteableMarginRight(double aUnwriteableMarginRight) override;
これらと、印刷用紙の単位変換を行なう処理を追加したものがこちらです。
このmozilla-centralのパッチではGeckoが印刷に用いている二つの単位系の対応も入っています。
- インチ
- kPaperSizeInches
- ミリメーター
- kPaperSizeMillimeters
の両方の単位系がGeckoでの印刷ではサポートされています。
そのため、
- Inches -> Twips -> Pixels
- Millimeters -> Twips -> Pixels
の両方を取り扱う必要があります。これは
diff --git a/widget/cocoa/nsPrintSettingsX.mm b/widget/cocoa/nsPrintSettingsX.mm
--- a/widget/cocoa/nsPrintSettingsX.mm
+++ b/widget/cocoa/nsPrintSettingsX.mm
@@ -254,8 +254,13 @@ NS_IMETHODIMP nsPrintSettingsX::SetPaper
NS_IMETHODIMP
nsPrintSettingsX::GetEffectivePageSize(double *aWidth, double *aHeight)
{
- *aWidth = NS_INCHES_TO_TWIPS(mAdjustedPaperWidth / mWidthScale);
- *aHeight = NS_INCHES_TO_TWIPS(mAdjustedPaperHeight / mHeightScale);
+ if (kPaperSizeInches == GetCocoaUnit(mPaperSizeUnit)) {
+ *aWidth = NS_INCHES_TO_TWIPS(mAdjustedPaperWidth / mWidthScale);
+ *aHeight = NS_INCHES_TO_TWIPS(mAdjustedPaperHeight / mHeightScale);
+ } else {
+ *aWidth = NS_MILLIMETERS_TO_TWIPS(mAdjustedPaperWidth / mWidthScale);
+ *aHeight = NS_MILLIMETERS_TO_TWIPS(mAdjustedPaperHeight / mHeightScale);
+ }
return NS_OK;
}
diff --git a/widget/cocoa/nsDeviceContextSpecX.mm b/widget/cocoa/nsDeviceContextSpecX.mm
--- a/widget/cocoa/nsDeviceContextSpecX.mm
+++ b/widget/cocoa/nsDeviceContextSpecX.mm
@@ -49,6 +49,19 @@ NS_IMETHODIMP nsDeviceContextSpecX::Init
if (!settings)
return NS_ERROR_NO_INTERFACE;
+ bool toFile;
+ settings->GetPrintToFile(&toFile);
+
+ bool toPrinter = !toFile && !aIsPrintPreview;
+ if (!toPrinter) {
+ double width, height;
+ settings->GetEffectivePageSize(&width, &height);
+ width /= TWIPS_PER_POINT_FLOAT;
+ height /= TWIPS_PER_POINT_FLOAT;
+
+ settings->SetCocoaPaperSize(width, height);
+ }
+
mPrintSession = settings->GetPMPrintSession();
::PMRetain(mPrintSession);
mPageFormat = settings->GetPMPageFormat();
のコードにより取り扱うことができます。
ここではGetCocoaUnit は kPaperSizeMillimeters か kPaperSizeInches を返すprotectedメソッドです。また、SetCocoaPaperSizeは印刷用紙の大きさを設定するメソッドです。
まとめ
macOSでもXULアプリケーションなどから printToFile = true を設定したときにPDFへ出力するパッチについて解説しました。
このBugのレポート日時は 2011-08-01 12:35 PDT なので、このパッチで5年半越しの問題が解決されました。
mozilla-centralの該当コミットを見るとBug番号がまだ6桁であり、周辺のコミットに紐づいたBug番号は7桁なので感慨深いですね。
- ククログの記事はCC BY-SA 4.0とGFDLのデュアルライセンスで自由に利用できます。
- クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。
- クリアコードは「クリアコードをいい感じにする人」を1名募集しています。
- クリアコードはフリーソフトウェア開発で培った技術力を提供しています。特にMozilla製品（Mozilla FirefoxとMozilla Thunderbird）とRubyとGroonga（全文検索）に関連した開発を得意としています。