[printing-japan] Bi-di資料

Yasumasa TORATANI toratani.yasumasa @ canon.co.jp
2003年 12月 4日 (木) 21:35:18 PST


虎谷です。

On Fri, 05 Dec 2003 12:43:30 +0900
Masaki IWATA <iwata @ axe-inc.co.jp> wrote:

> アックスの岩田です。
> 
> > 虎谷です。
>   (snip)
> >>で、質問の意図したかったことは、--output-fd に相当するプリンタ
> >>ポートのファイルディスクリプタを渡す方法は、どのようになってい
> >>るのでしょうか? ということです。
> > 
> > 共有ライブラリ型の Bi-di Plug-inの場合、文字通り共有ライブラリ
> > なので、上記引数によって fd を渡すことはないのですが。。?
> 
> +--------------+
> |   backend    |               +-------+         +--------+
> |    又は      |---(fdWrite)-->| Bi-di |<--(*)-->|プリンタ|
> |printer daemon|<--(fdRead)----|Plug-in|    ?    +--------+
> +--------------+               +-------+
> 
> という構図を想像していたのですが、違っていますか?

大体この通りです。
もう少し正確に書くと、bidiNewを実行後は。。。

<プロセス型のBi-di Plug-inの場合>
+--------------+
|   backend    |                +-------+             +--------+
|    又は      |--(fd1)--(fd2)->| Bi-di |--(fdWrite)->|プリンタ|
|printer daemon|<-(fd3)--(fd4)--|Plug-in|<-(fdRead)---|        |
+--------------+                +-------+             +--------+

上記fd1, fd2, fd3, fd4は、backend or printer daemonにリンクする
Bi-di Plug-in用ライブラリが、bidiNew関数内で生成する4つのパイプ
のうちのデータ送受信用のパイプの両端のfd。パイプ生成時にpipe関数
より取得。

fd1は、bidiGetWriteFDによって取得可能。
fd3は、bidiGetReadFDによって取得可能。

fdRead, fdWriteは、backend または printer daemonがデバイスや
ソケットをオープンした際に取得するfd。bidiNewの引数に与える。


<共有ライブラリ型のBi-di Plug-inの場合>
+--------------+
|   backend    |+-------+             +--------+
|    又は      || Bi-di |--(fdWrite)->|プリンタ|
|printer daemon||Plug-in|<-(fdRead)---|        |
+--------------++-------+             +--------+


> >>この質問で最終的にお訊きしたいのは、CUPS を経由せずにジョブの
> >>キャンセルができるような構造も*あり*だということになると、ア
> >>プリケーションから出力されたデータが、一連の処理の流れの中の
> >>どこの段階でスプールされているのか、逆に辿る必要がでてくるの
> >>で、このようなお考えをお持ちなのかどうか、ということなのです。
> >>というか、これは*なし*にして下さいませんか? というお願いです。
> > 
> > *なし*にするかどうかは、私は決められないのですが。。(^^;
> > 多分に、printer daemonの仕様に掛かってるように思います。
> > 
> > 現時点で見えている処理の流れでは、
> > Type Bのステータスユーティリティは、printer daemon と繋がって
> > printer daemon に含まれる特定のプロセス(出力プロセス)が
> > Bi-di Plug-inを起動することになっていたと思います。
> > 
> > このような系で、Type Bがキャンセルを実行する場合、その要求は
> > 先ずprinter daemonに伝えられ、最終的に上記出力プロセスに
> > 伝えられて、そのプロセスが bidiCancelJobを呼ぶことになると
> > 思います。この場合、キャンセルはCUPSを経由しないことになります。
> 
> ジョブがまだ printer daemon に届いていない段階では、ジョブの
> 存在自体を認知していませんので、その問い合わせから行なう必要
> が生じます。

その通りですね。

> > さらにこの場合、キャンセルに関する情報を backend側に伝達する
> > 必要があると思います。(printer daemonがスプールしない、かつ
> > backendが、まだprinter daemonと繋がっている=印刷データの
> > 転送が完了していない)
> > 
> > 伝達方法については、backendとprinter daemonの間のプロトコル
> > に依存すると思います。
> 
> IPP backend は、IPP クライアントですから、このような用途には
> 利用できないような気がします。
> もしこれを行なうとすれば、CUPS 本体に直接アクセスしなければ
> 無理だと思いますが...まだ、よく解っておりませんので...

できると思うのですが。。。?
IPPクライアントであるbackendに、printer daemonからジョブの
中断か何かを返せばよいのでは?ソースを細かく追った訳では
ないので、定かではありませんが。

> > 共有ライブラリ型の場合、bidiWriteがサポートされない Bi-di Plug-in
> > moduleは有りだと思います。(弊社のBi-di Plug-in)
> > 
> > 一方、プロセス型のBi-di Plug-inの場合には、bidiWriteのサポートを
> > 前提としていました。(EPSON KOWAさんの Bi-di Plug-in)
> > 
> > しかし、その辺りの記述がドキュメントにないですねぇ。。(^^;
> > プロセス型で、bidiWriteサポート無しの場合も、有りえないことは
> > ないのですが、当面の仕様として、「プロセス型の場合は、bidiWrite
> > のサポートは必須」を追記したいと思います。
> 
> すみませんが、先頭の構図の件が(私の中で)解決してから、改めて
> 考えてみます。
> 
> -- 
> IWATA Masaki
>  岩田 正樹
> 
> 
> _______________________________________________
> printing-japan mailing list
> printing-japan @ freestandards.org
> http://freestandards.org/mailman/listinfo/printing-japan

-----------------------------------------
Yasumasa TORATANI
Computer Technology Development Dept. 12
CANON INC. Shimomaruko Office, Japan





More information about the Printing-japan mailing list