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

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

[TORATANI Yasumasa]

On Mon, 15 May 2006 11:49:53 +0900
TORATANI Yasumasa <toratani.yasumasa@canon.co.jp> wrote:
(snip)
> > Is there anything Canon-specific in the "pstocanonopvp" CUPS GhostScript
> > wrapper filter? Or can it be used as a generic wrapper to use the
> > OpenPrinting vector interface?
> 
> This code was not written by Canon people, so, I'm not sure it's depends
> on Canon specific, I'll check it soon.

I checked it, and found that it can be generic, though, the code includes
a few bugs, so we need to improve the code for generic use, and as I mentioned
in the previous email, we have a skeleton driver "opvpnull", I think the Japan side
developer should prepare the essential cups filter code for opvp like "pstoopvp"
from "pstocanonopvp" or other vendors code.

I'll suggest it on the Japan side developers mailing list.

-----------------------------------------
TORATANI Yasumasa

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

[Michael Sweet]

Till Kamppeter wrote:
> Here is a way to print with a real PDF workflow and without GhostScript
> at all:
> 
> Now I have also tried to compile the pdftoopvp package from the CVS of
> the opfc project on SourceForge.jp
> (http://sourceforge.jp/projects/opfc/). One needs these two patches:
> 
> http://www.linuxprinting.org/till/tmp/xpdf-3.00-gcc401.patch
> http://www.linuxprinting.org/till/tmp/pdftoopvp-gcc401.patch
> 
> After compiling there is a CUPS filter xpdf-3.00/xpdf/pdftoopvp which
> has to be copied into /usr/lib/cups/filter and the PPDs into
> /usr/share/cups/model. In addition, the OpenPrinting vector drivers for
> the desired printers need to be installed. Then PDF files sent to a
> queue created with the new PPDs should be directly rendered with
> pdftoopvp, without GhostScript detour. pdftoopvp is a real CUPS filter
> which does not need any wrapper. the driver library to be used it
> determines by reading the PPD file.
> 
> The PPD files need to be edited to comply with cupstestppd.

It is important to note that this is NOT a complete solution.  We
still need to implement a pdftopdf filter which does page selection,
imposition, page labeling, and so forth before we can use this in
CUPS...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com

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

[TORATANI Yasumasa]

Hi,

I think the common statement that we will shift to PDF as a new printing
spooling format is reasonable.

On the other hand, when a CUPS filter handles the PDF data, I think the
filter needs to access the entire PDF file, so, in case of long page document,
for instance over 100 pages document, does pdftopdf convert 100 pages PDF
into layouted 100 pages PDF, and save it into disk, and after completion of
saving 100 pages PDF data, pdfto* filter starts to read the saved PDF data
from the disk, and converts it into raster, PDL, etc?  Or, does pdftopdf send
some header including some PDF table info. to pdf* filter via stdin/stdout,
before sending the PDF document body data?

TORATANI.

On Mon, 15 May 2006 23:14:42 +0200
Till Kamppeter <till.kamppeter@gmx.net> wrote:

> Michael Sweet wrote:
> > Till Kamppeter wrote:
> > 
> >> Here is a way to print with a real PDF workflow and without GhostScript
> >> at all:
> >>
> > 
> > 
> > It is important to note that this is NOT a complete solution.  We
> > still need to implement a pdftopdf filter which does page selection,
> > imposition, page labeling, and so forth before we can use this in
> > CUPS...
> > 
> 
> And there are more things missing or better to be made differently:
> 
> - The PDF renderer should not be a patched XPDF, but it should be linked
>   against libpoppler, as well as the pdftops which ships already with
>   CUPS, so that there is no repeated code which causes full hard disks
>   and maintenance neightmares.
> 
> - A pstopdf filter is needed to handle incoming PostScript jobs
> 
> - Also an imagetopdf and texttopdf filter is needed.
> 
>    Till
> _______________________________________________
> Desktop_printing mailing list
> Desktop_printing@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/desktop_printing

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

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

[Michael Sweet]

TORATANI Yasumasa wrote:
> Hi,
> 
> I think the common statement that we will shift to PDF as a new printing
> spooling format is reasonable.
> 
> On the other hand, when a CUPS filter handles the PDF data, I think the
> filter needs to access the entire PDF file, so, in case of long page document,
> for instance over 100 pages document, does pdftopdf convert 100 pages PDF
> into layouted 100 pages PDF, and save it into disk, and after completion of
> saving 100 pages PDF data, pdfto* filter starts to read the saved PDF data
> from the disk, and converts it into raster, PDL, etc?  Or, does pdftopdf send
> some header including some PDF table info. to pdf* filter via stdin/stdout,
> before sending the PDF document body data?

Those are implementation details - we're a bit too early in the
process set those in stone.  In general, we *will* need to save the
printer-specific PDF file (application/vnd.cups-pdf, already
registered with IANA) to disk in the pdftops/pdftoraster filter,
however the document filter (pdftopdf) can probably stream the
objects through the use of indirect objects to hold the stream
lengths.

That said, an alternative solution would be to put the job filtering
in pdftops/pdftoraster themselves, in which case pdftopdf will only
be necessary when printing to a PDF-capable printer.  The current
Xpdf/poppler APIs are insufficient for this right now, but if
implemented properly it would provide a highly efficient filtering
solution.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com

[Printing-architecture] Re: [Desktop_printing] Deprecate IJS? GhostScript with only "opvp" as output device?

[Michael Sweet]

Till Kamppeter wrote:
> ...
> IJS is separate-process-only, raster-only, and not under active
> development any more. There are also only three projects using it:
> HPLIP, Gutenprint, and the Epson-EPL-"L"-series driver. So I think it
> can be deprecated soon and be replaced by the OpenPrinting vector
> interface. Or are there things which IJS provides but OpenPrinting
> vector not.

Both Gutenprint and HPLIP have CUPS native interfaces that are better
suited to pure-raster printing.

> And with the OpenPrinting vector interface one would even be able to
> modularize out all the GhostScript output devices and leave GhostScript
> with "opvp" as the only output device. So also the problem of the X11
> output drivers in the GhostScript implementation of distributions and
> using GhostScript on X-less servers would get nicely solved.
> 
> WDYT?

We still need to ensure that the new interface is compatible on all
of the current operating systems; for us that means: AIX, HP-UX, IRIX,
Linux, MacOS X, Solaris, and *BSD.

Also, the X11 problem is already solved by the dynamic module support,
right?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com

[Printing-architecture] Re: [Desktop_printing] Deprecate IJS? GhostScript with only "opvp" as output device?

[Michael Sweet]

Till Kamppeter wrote:
> Michael Sweet wrote:
>> Both Gutenprint and HPLIP have CUPS native interfaces that are better
>> suited to pure-raster printing.
>>
> 
> I do not want to deprecate CUPS raster (CUPS raster is probably the
> second reason to deprecate IJS), it is probably the better choice in
> terms of color management and clean job canceling than OpenPrinting vector.
> 
> When will HP's rastertohplip be published?

You need to ask HP about that.  I do owe them a .drv file against
the latest release...

>>> And with the OpenPrinting vector interface one would even be able to
>>> modularize out all the GhostScript output devices and leave GhostScript
>>> with "opvp" as the only output device. So also the problem of the X11
>>> output drivers in the GhostScript implementation of distributions and
>>> using GhostScript on X-less servers would get nicely solved.
>>>
>>> WDYT?
>>
>> We still need to ensure that the new interface is compatible on all
>> of the current operating systems; for us that means: AIX, HP-UX, IRIX,
>> Linux, MacOS X, Solaris, and *BSD.
>>
> 
> If an OS does not provide any possibility for dynamic linking like libdl
> under Linux, we must fall back to a separate process, where the driver
> library is statically linked to the server executable.
> 
>> Also, the X11 problem is already solved by the dynamic module support,
>> right?
>>
> 
> Yes, but this solution seems not to be overtaken by upstream (AFPL/GPL)
> GhostScript.
> 
>   Till


-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com

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

[TORATANI Yasumasa]

On Mon, 15 May 2006 19:48:23 +0200
Till Kamppeter <till.kamppeter@gmx.net> wrote:
(snip)
> 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?

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

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

[TORATANI Yasumasa]

On Tue, 16 May 2006 10:49:50 +0200
Till Kamppeter <till.kamppeter@gmx.net> wrote:

> TORATANI Yasumasa wrote:
> > 
> > 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?
> > 
> 
> As far as I understand, a regular job is started with StartJob and ends
> with EndJob, no multiple calls of these functions. And I understand a
> job cancel as being done by sending a SIGTERM to the renderer and then
> the renderer catches the signal, calls CancelJob, closes the connection,
> and exits. The CancelJob function implemented in the driver library
> should close down the job in a way so that the printer gets back to
> accepting new jobs.
> 
> I do not know where multiple StartJob/EndJob/CancelJob would be needed.
> 
>    Till

Thank you so much for your comment.
We also think that we don't have to handle multiple printing jobs at the
driver level. We will discuss it on the mailing list as well as at the f2f
meeting next week.

-----------------------------------------
TORATANI Yasumasa