[printing-japan] Re: [printing-japan] Bi-di資料
Masaki IWATA
iwata @ axe-inc.co.jp
2003年 12月 9日 (火) 07:18:37 PST
アックスの岩田です。
> 中村です。
(snip)
> CUPS からのキャンセルが backend に影響するのは、印刷中のジョブを実行中の
> backend の場合であり、この場合、CUPS から backend に対して、SIGTERM( or
> SIGKILL)の signal が送られますので、SIGTERMの場合には、それがトリガーに
> なるかと思います(スプール中のジョブは除きます...)。
CUPS 標準の Backend のソースをみると、SIGTERM は無視して
いたり、そのまま exit() していたりしますね。
# IPP の仕様では、データの出力が開始されてしまったジョブ
# のキャンセルや停止は、実装依存となっていたように記憶し
# ていますので、これでも良いのですね。
但し、この方法では、先般 bidiCancelJob() に追加された
idJob を利用した(高度な)キャンセル処理という訳にはいきま
せんね。
# カレントの Backend が処理しているジョブ(のみ)をキャン
# セルするということになりますね。
IPP Backend の場合は、部数分のジョブに分割される場合もあ
るようですので、ちょっと複雑になりますが...(printer daemon
が複数部印刷に対応すれば良いということなのですが...)
しかも、SIGTERM を受け取ると、テンポラリファイルを削除す
るだけですぐ exit() しているので、その先ではコネクション
の切断で判断するしかないような気が...(ということは、ステー
タスを返すことができないですね...)
これまた、処理が複雑になりそうですね。
> BIDI_CAP_JOB capabilityを持っている Bidi plugin を使う backend または、
> Printer Daemonは、bidiCancelJob()を発行を実装に含める必要があるかと
> 思います。
printer daemon でも、やはり要りますかね?
CUPS からのキャンセル処理が、うまく下流に下りてくるよう
なので CUPS にキャンセル処理を投げてしまうという手があ
るのですが...どんな方法をとっても、複雑になりますね。
--
他に、bidiCtrl() で何らかの制御が行えるようになったとし
ても、CUPS 経由では利用できないということで、良いのでしょ
うか?
# Backend は SIGTERM によるジョブキャンセル以外のプリン
# タ/ジョブの制御/操作は対応できないということで良いの
# でしょうか?
--
IWATA Masaki
岩田 正樹
More information about the Printing-japan
mailing list