[Desktop_printing] Re: Trying out sample implementation of
japanese OpenPrinting efforts
toratani.yasumasa at canon.co.jp
Mon May 15 20:22:24 PDT 2006
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?
On Mon, 15 May 2006 23:14:42 +0200
Till Kamppeter <till.kamppeter at 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.
> Desktop_printing mailing list
> Desktop_printing at lists.osdl.org
Software Engineering Dept.22
Platform Technology Development Headquarters, CANON INC.
More information about the Printing-summit