[printing-japan] Bi-di資料
Masaki IWATA
iwata @ axe-inc.co.jp
2003年 12月 5日 (金) 00:04:33 PST
アックスの岩田です。
> BBRの貫定です。
(snip)
> あくまで私の理解ですがBi-di plug-inの考え方として
> 「プリンタとの双方向のやりとりにプリンタの依存性を
> 吸収する部品があればいいな」
> というモノを感じました。
> その意味だとすると、Bi-di plug-inの役割としては、ざっと
> 以下のようなものになるかと思います。
> 1)プリンタのステータスをプリンタの固有性を隠蔽して読み出す
> 具体的には、プリンタ固有の読出方式の制御をしつつ
> 固有のデータ形式から一般的、汎用的な形式にデータを変換する。
> 2)アプリケーション印刷命令をプリンタの固有のコマンドに変換する(したい)
> これはCUPS/GSの絡みでBi-di plug-inの役割ではなくVDDの役割に
> なっていると理解しています。
> 3)プリンタのリードとライトのタイミングを制御する。
>
> で今回のCanonさんの場合は、共有ライブラリタイプで、1)の役割のみを
> Bi-di plug-inが行い、背景の機構が1Job1プロセス(常駐型でない)という
> ことから呼び出し側(backend)は、以下のようなAPIシーケンスになるかと思います。
>
> bidiNew()
> bidiStartJob()
>
> bidiStartRead() :select()を絡めてライトとタイミングを制御して繰り返し
> bidiRead() :データがなくなるまで繰り返し読出し
> bidiRead()
> ・
> ・
> ・
> bidiEndRead()
>
> bidiStartRead() :select()を絡めてライトとタイミングを制御して繰り返し
> bidiRead() :データがなくなるまで繰り返し読出し
> ・
> ・
> ・
> bidiEndRead()
>
> ・
> ・
> ・
>
> bidiEndJob()
> bidiDestroy()
>
>
> 常駐型の場合、さらにbidiStartJob()/bidiEndJob()のブロックが
> (bidiNew()で作ったコンテキストを再利用しながら)
> 繰り返すかと思います。
>
> で、プロセスタイプの場合は、selectのためにプリンタのFDではなく
> Bi-di plug-inプロセスとのパイプを利用しなければいけないので、
> bidiGetReadFD()を設けてあると思っています。
>
> backend(またはprinter daemon)は、ライブラリタイプ/プロセスタイプを
> 意識せずBi-di plug-inを呼び出して、盲目的にbidiGetReadFD()で取得した
> fdをselect()に利用することになるのではないかと思います。
> (Bi-di plug-inとしては、
> ライブラリタイプは結果的に、bidiNew()で与えられたfdと同じものを返しますし、
> プロセスタイプは、作ったパイプのfdを返します。)
ありがとうございます。
私が間違っていたのは、backend や printer daemon とプリンタとの
データの授受には、必ず全て Bi-di Plug-in を介して行なわれると
(勝手に)思い込んでいた点です。
お騒がせ致しまして、申し訳ありません。
ただ、read 系に関しては、backend や printer daemon が fdRead
に対して read() を行なうことは、やめておいたほうが良さそうで
すね。
ところで、bidiStartRead() と bidiEndRead() の間では、bidiRead()
以外のコマンドは、一切禁止なのでしょうか? それとも、bidiCtrl()
等は、実行可能なのでしょうか?
また、ここで、fdWrite に対して write() を行なうとどうなるので
しょうか?
(やってもいいけど、保障しないよ。ということかな...)
印刷データ出力中に、ステータス取得の依頼があった場合は、BUSY
(があるのか?)を返してしまって良いのかな...?
でも、大きなデータだと、ずっと BUSY のままになってしまいます
ね... すみません、このあたりの制御規定は、何を見れば解るので
しょうか?
--
IWATA Masaki
岩田 正樹
More information about the Printing-japan
mailing list