2008年9月 3日

[openoffice:11307] Implementation of Printing dialog of OOo

小笠原です。
どうも文字化けでご迷惑をお掛けしてるようですので、表題変更しました。

# 他のMLへの投稿だとバケないんだけど、なぜだろう?

2008-09-03 (水) の 02:39 +0900 に tora - Takamichi Akiyama さんは書きま
した:
> 少しお教えいただけませんでしょうか。


ええと、ここで書き込んでいるのは個人の小笠原ですので、「業務上得た知識を
みだりに使わない」範囲でよろしければ (^^;)。


> DeviceCapabilitiesW, DeviceCapabilitiesA, GetDeviceCaps あたりの使い方
> は
> どのようにすればよいのでしょうか。

まず現代のプログラミングにおいては -A 系は使用してはなりません。-W 系を
使用すべきです。
Windows API 全般において、文字のエンコーディングが -A が Multibyte すな
わち ASCII+ShiftJIS など、-W が UTF-16 というふうになっています。

・ユーザが設定した文字列の類に Mulitbyte で表現できないものが
 あった場合データが欠落する
・Windows の内部表現が UTF-16 なので、ミリ秒単位で早い (笑)

というのが -W 系を用いるほうが好ましい理由です。

また DeviceCapabilities と GetDeviceCaps はちょっと意味合いが異なってお
り、

・DeviceCapabilities - プリンタドライバの設定状態を返す
・GetDeviceCaps - 現在のデバイスコンテキストの諸元や能力を返す

という感じです(なおデバイスコンテキストというのは Windows において画面
やプリンタドライバの描画領域などを抽象化した概念……というのは釈迦に説法で
すね)。
ので、今回のシチュエーションにおいては DeviceCapabilities の方がふさわし
いでしょう。


> OpenOffice.org の現在のソースコードのどこらへんに、改善の余地がありそ
> うで
> しょうか。

すみません、前述の理由により、ソースコードを見て助言となるとちょっと立場
的に微妙なのでお許しください……。

> ところが、実際の動作を見ていると、DeviceCapabilities() を呼ぶよりも前
> に、
> そのメソッドの前半部分の IsQueuePrinter() の戻り値が必ず?かどうかはよ
> く
> わかりませんが、真になっているようでして、
<snip>
> 結果的に、プリンタ側の能力を調べることもなく、OpenOffice.org が自分で
> 頑張って
> 部数分ループするんだと判断してしまうようなのです。
> 上記の nCopies = 1 は、後に dmCopies に代入される値のようです。

であれば、そこをただすべきですよ、というのが私の助言ということになりま
す。


> ということは、ユーザーインターフェースについては、
>
> ・OpenOffice.org 側のダイアログの処理では、〔プロパティ〕ボタンが押さ
> れると、
>  そのハンドラ内にて、まず、現在の「部数」および「部単位で印刷」の設定
> 値を
>  DEVMODE.dmCopies および DEVMODE.dmCollate に設定してプリンタドライバ
> 側へ
>  通知し、その後、プリンタドライバ側の「プロパティ」ダイアログを表示す
> るよう
>  に指示する。

厳密に言えば、

> プリンタドライバ側の「プロパティ」ダイアログを表示するように指示する。

ときの API (DocumentProperties) のパラメータに、アプリが持っている
DEVMODE をセットする、が正解ですが、概ねそのご理解で正しいと思います。

http://msdn.microsoft.com/ja-jp/library/cc428447.aspx

をご覧ください。
基本はこんな感じです。

1. まず DocumentProperties fMode = 0 でサイズを求め (sizeof(DEVMODE) を
使ってはダメ)、
2. その大きさで構造体を一個確保し (pDM とします)、
3. fMode = DM_OUT_BUFFER でプリンタドライバの標準の設定値を pDM にコピー
し、
4. pDM の好きなパラメータをアプリ側の設定画面で設定されたように書き換え
たうえで、
5. fMode = DM_IN_BUFFER | DM_IN_PROMPT | DM_OUT_BUFFER として、pDM を in
と out の両方にセットすると、プリンタドライバの設定画面に 4. で設定され
た値が反映された形で表示され、
6. ユーザがドライバの画面で「OK」を押下すると、ドライバの設定を反映した
値が pDM に得られる
7. アプリは CreateDC または ResetDC のときにこの pDM を渡すことで、情報
をプリンタドライバに通知する

という制御になります。
なお DocumentProperties API はモーダルなので、ダイアログをユーザが明示的
に閉じるまで制御が帰って来ません。ので DEVMODE への反映などは API にお任
せです。


> というか、もしかして、それが当たり前の作りでしょうか。

当たり前、というと言い過ぎかもしれませんが、プリンタドライバ製作者(そし
て、たぶんマイクロソフトも)としてはそう作って欲しいと願っております。


> さらに DeviceCapabilities() をどのように組み入れればよいでしょうか。
> それとも、DeviceCapabilities() の呼び出しは不要でしょうか。

DEVMODE を直接見るのと DeviceCapabilities を使うのでは結果は同じですの
で、どちらでもお好きなように、というのが答えになります。
が、DeviceCapabilities では値を得ることはできてもセットはできず、セット
するには DEVMODE を経由しなければならないので、だったら最初から DEVMODE
で処理した方が簡単かと存じます。

もちろん DC_BINS などの DeviceCapabilities でしか取得できない値もありま
すので、DeviceCapabilities なんて意味はない! わけではないです。


> そもそも、DeviceCapabilities() の 「DC_COPIES デバイスが印刷できる部
> 数が返ります。」
> で返される値は、どのような値が返されるのでしょうか。

DC_COPIES の戻り値 = DEVMODE.dmCopies でしょうね。普通のドライバでは。
私も弊社の実装すら確認したことがありませんが、MS はそう期待していると思
います。
そしてこの二つは「紙の枚数」でもないし「物理ページ数」でもないので、UI
上に見える「印刷部数」と一致する値になります。


以上、奥歯にものが挟まったような物言いですが、参考になれば幸いです。

[以上]


【MLコミュホームページ http://www.freeml.com/openoffice

--[PR]------------------------------------------------------------------
:*:*: 。:*  スプーン1杯、ハリとうるおいのある毎日に♪  *: 。:*:*:
:*・…………………………………………………………………………………・*:
     通販限定 サントリー Milcolla[ミルコラ]
  2,625円(税込) 105g/1袋(約15日分)今だけ送料無料!
http://ad.freeml.com/cgi-bin/sa.cgi?id=c1AtR
------------------------------------------------------------------[PR]--
■GMO INTERNET GROUP■ GMO INTERNET www.gmo.jp


投稿者 xml-rpc : 2008年9月 3日 04:43
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/76931
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。