[Printing-architecture] Re: [Desktop_printing] Re: Trying out sample implementation of japanese OpenPrinting efforts

TORATANI Yasumasa toratani.yasumasa at canon.co.jp
Mon May 15 22:26:16 PDT 2006

On Mon, 15 May 2006 19:48:23 +0200
Till Kamppeter <till.kamppeter at gmx.net> wrote:
> Now the glue code could check the presence and the linkability of the
> driver library. If it succeeds to link it, it works with directly linked
> driver. If it does not succeed, it looks for the driver's server
> executable and runs it. If there is no server executable but a driver
> library which the renderer cannot link with or is not allowed to link
> with, it calls its own generic server executable and lets this one with
> the driver library.
> Please tell me whether these suggested improvements are feasable and if
> not, why not. Especially I would appreciate very much if we could do
> away with the /usr/lib/opvp_rpc_<driver>.so.0.0.1.

I'm really appreciate your great effort! I will suggest to the Japan side
development team to apply your patch into the opvp code stuff.

> >>I also would like to know whether the OpenPrinting vector driver has a
> >>way to cleanly cancel jobs. Is the job cleanly shut down when sending
> >>SIGTERM to GhostScript?
> > 
> > Currently, it depends on the driver side implementation.
> > If the driver needs the signal handing feature for particular signal code, driver
> > has to prepare the signal hander for doing it. If the driver is a RPC type one
> > and needs to deal with some kind of signal, both the client and server driver
> > may have the signal handler.
> Can we add a function for this into the API (which is called by the glue
> code when the renderer receives SIGTERM)? It would be very useful if the
> driver runs in a separate process. So a SIGTERM to the renderer could
> call this function in the glue code and then an appropriate command gets
> via RPC to the driver. And if the driver is linked directly nothing else
> than the function being called directly happens, as with any other
> driver function. This way the driver shuts cleanly down without any
> extra code with renderer wrapper (CUPS filter) needing to find out what
> the driver process is.

We will discuss this issue on the japan side mailing list.
I guess you need a single job cancellation, and do not have to support
multiple StartJob/EndJob/CancelJob, is it correct?

Software Engineering Dept.22
Platform Technology Development Headquarters, CANON INC.

More information about the Printing-architecture mailing list