● ToolBox API徒然草（2007/05/01）

今回は、HIThemeDrawTextBox()によるテキスト描画を印刷（プリントアウト）に利用してみたいと思います。印刷といっても、ウィンドウ上のテキスト描画とそれほど違いはないのですが、幾つか注意すべきポイントを解説します。

せっかくですので、まず最初にCarbonアプリケーションでの印刷手順をおさらいしておきましょう。昔から印刷作業には2種類のダイアログ、もしくはシートウィンドウを利用します。それらは、用紙設定ダイアログ（Page Setup）とプリントダイアログ（Print）と呼ばれており、ファイルメニューの「ページ設定...」や「用紙設定...」そして、「プリント...」を選択することで表示されます。用紙設定ダイアログでは、印刷のための用紙サイズや印刷方向を設定できます。その後、プリントダイアログで印刷枚数等を入力し「プリント」ボタンをクリックすれば、印刷が始まる手順となります。

昔から、このように印刷関連のダイアログが2つに分かれている点については、使い勝手の面からも議論の対象となっています。まあ用途によりけりなので、どちらかが最良と言うわけでもないと思いますが、両ダイアログを一つにまとめたオプションが存在しても良いのではないでしょうか（近々そうなるとの噂アリ）。まずは、用紙設定ダイアログ（シート）の表示方法を調べてみます。

先んじて、両ダイアログの設定内容を保持するための2つのリファレンス（PMPageFormatとPMPrintSettings）を外部変数として定義しておきます。



getDefaultFormatPrint()は、指定された印刷セッションにおける（PMPrintSessionで参照する）用紙設定のディフォルト内容（つまり初期値）を引数で渡したPMPageFormatに代入する簡単なルーチンです。具体的にはメモリ内に構造体を確保し、そのメンバーに初期値を代入します。



次が、pt_formの設定内容を変更するための用紙設定ダイアログ（今回はシート）を表示するpageSetupPrint()ルーチンです。シートを表示して「OK」か「キャンセル」ボタンをクリックすると、PMSessionUseSheets()の引数として登録しておいたpageDoneProc()（終了ルーチン）が呼ばれます。ちなみに、この処理からPMSessionUseSheets()を外せば、用紙設定シートはダイアログとして表示されます。しかし、Mac OS X 10.4（Tiger）では、モニターの変な場所にダイアログが表示されるバグが存在しますので注意してください。このバグは、Mac OS X 10.5（Leopard）で修正されるそうです。



以下が、用紙設定シートを閉じる時に呼び出されるpageDoneProc()ルーチンです。渡されてくるchkの内容により、「OK」ボタンが押されたのか「キャンセル」ボタンが押されたのかを判断可能です。もし、PMSessionUseSheets()を実行せず、シートでなくダイアログの方を表示している時には、PMSessionPageSetupDialog()が返すchkの値により、押されたボタンの種類を判断することができます。



次は、プリントシートを表示するstartPrint()ルーチンです。startPrint()を実行する時点で、まだ一度も用紙設定シートがオープンされていない可能性がありますので、先んじてpt_formに対して前記ルーチンと同様な処理を行っています。



続いて、プリントシートを閉じる時に呼び出されるprintDoneProc()ルーチンです。OKボタンが押された時のみstartPrint()ルーチンを実行し、実施の印刷作業を開始します。



最後は、実際の印刷作業を受け持つstartPrint()ルーチンです。印刷処理自体については詳しく解説しませんが、この処理中で重要な箇所は、PMSessionGetGraphicsContext()でkPMGraphicsContextQuickdrawを指定し、まずはQuickDraw APIによる描画を印刷に反映させるためのCGrafPtrを得ている所です。しかしこのままでは、HIThemeDrawTextBox()など描画環境をCGContextRefで参照するAPIは利用できません。そこで、QDBeginCGContext()を使いCGrafPtrからCCGContextRefを得て、それを引数で渡すことで初めてCoreGraphics APIでの描画を印刷に反映させることが可能となります。



上記処理のような回りくどいことをせずとも、単純にPMSessionGetGraphicsContext()にkPMGraphicsContextCoreGraphicsを代入し、ダイレクトにCGContextRefを得ることができれば、すぐにCoreGraphics APIを使えるような気がします...。

ところが、下記のようにCFArrayCreate()とPMSessionSetDocumentFormatGeneration()で行っている手続きを加えないと、この作戦は成功しません。この追加処理の部分、なんだか「おまじない」のような感じなのですが（笑）残念ながら、現状ではこう記述しないとCoreGraphics APIでの描画が印刷に反映されないのです。どう考えても、これは余分な手続きだと思いますので、Mac OS X 10.5では修正してほしいところです。



今回でテキスト関連の話題は終了し、次回からはCarbonのファイルシステムについて解説します。こちらもテキストやグラフィックスに負けず劣らず、時代と共に変貌してきた経緯があります。はたしてファイルシステムは、どの程度モダン化されたのでしょうか？