cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Corda, Ugo" <>
Subject RE: Printing [Was: Re: Project Coordination]
Date Sat, 08 Apr 2000 03:26:04 GMT
I am not up to speed with the latest details of Cocoon 2, but I think I
understand enough of the filter and serializer concepts to say that your
proposal sounds good to me. Let me just add some comments and

The printer value parameter should be defined at run time by the requester
(is it possible to do that without hardcoding it in the sitemap?).

In step 4 I would not talk about a fop serializer, because I understand that
as something that generates a PDF stream. Let's instead talk about a
fop-print serializer being invoked by the printer filter. This fop-print
serializer has the same effect as the "main" method in the PrintCommandLine
class recently introduced in the FOP code (except for the fact that the
latest FOP code cannot handle a parametrized printer value yet because it is
only supported in JDK 1.3 Java Print). In other words, the fop-print
serializer takes the printer value from the printer filter and does a Java
Print operation on that printer using the Java2D formatted areas it
generates from the FO data it gets from step 3. (All the details about
opening a connection to the printer, rendering the formatted areas to the
format expected by the printer, streaming data to the printer, etc. are
handled by the Java Print operation invoked by the fop-print serializer. In
reality, most of this is handled by the underlying native printer driver
that implements the Java Print mechanism -- e.g. in Windows it would go to
the GDI interface and then to the Windows native printer driver for the
particular printer selected).

When the fop-print serializer is done with invoking the print operation, it
returns information about the print operation itself to the printer filter,
which in turns passes it over to the next component in the pipeline. Then it
is step 5, etc.

To make things a little more complicated, a realistic print operation would
involve some "job ticket" information (number of copies, monochrome/color,
orientation, etc.). Let's assume this job ticket information is provided in
the form of an XML file. Again, the printer filter should get a pointer to
this file from some previous step in the pipeline, and it would pass that
information down to the fop-print serializer. It would be up to the
fop-print serializer to parse the xml job ticket and translate that
information into Java Print parameters.

With this type of approach we should be able to handle XML printing requests
to any printing device, as long as there is a printer driver available on
that platform for the specified printer (either statically or brought in
dynamically by things like Jini). All the complexity of rendering the Java2D
objects generated by FOP to the format required by the printer, be it
Postscript or anything else, is handled transparently by the Java2D
implementation for the platform and by the printer driver.

By the way, this approach should also automatically handle any "pseudo"
printing device like fax drivers, etc. Just provide the "pseudo" printer
value, and everything else should fall into place.


		-----Original Message-----
		From:	Pierpaolo Fumagalli []
		Sent:	April 07, 2000 5:56 PM
		Subject:	Printing [Was: Re: Project Coordination]

		Stefano Mazzocchi wrote:
		> "Corda, Ugo" wrote:
		> >
		> > I would like to make sure that Cocoon 2 will include
support for XML
		> > printing (as I discussed last month on this list).
		> >
		> > Just to summarize, here is what I was asking. I would
like to be able to ask
		> > Cocoon that a particular XML document be rendered to a
printer, as opposed
		> > to the browser client. This could be achieved by
appropriate use of the
		> > sitemap mechanism to specify the request, and by taking
advantage of FOP's
		> > capability to render to a printer the formatted areas
derived from the
		> > XSL-FO tree.
		> >
		> > Maybe this capability is already implied by one of the
items in the list
		> > below. I just wanted to mention it explicitly so that it
doesn't get lost in
		> > the end.
		> Great, I like that feature... now I need you to make a
solid proposal
		> that we can discuss on.
		> Something like "add this method to this interface" or

		I was thinking about that... And I believe that no
architectural changes
		are nedeed... Just let's consider to have a filter, in the
		wich is configured to basically "nest" as serializer...

		Let's have this example:

		<process uri="test" source="test.xml">
		  <generator name="file"/>
		  <filter name="xslt">
		    <parameter name="stylesheet" value="test2fo.xsl" />
		  <filter name="print">
		    <parameter name="printer" value="" />
		    <parameter name="serializer" value="fop" />
		  <filter name="xslt">
		    <parameter name="stylesheet" value="print2html.xsl" />
		  <serializer name="html">

		What happens here?

		1) the client requests ""
		2) the file generator parses the "test.xml" file
		3) the xml data gets translated into FO using XSLT and the 

		4) the printer filter gets the "fop" serializer thru the
		   manager. it opens a network connection to the printer
		   8100 is HP JetDirect's RAW DATA port, I can send
Postscript there).
		   The printer filter streams the XML data using the
configured "fop"
		   serializer to the printer (so it sends a PDF...) and
sends in the
		   pipeline, to the next component configured in the sitemap

		   <printer name="">
		     <job number="100" size="100000"/>
		     .... blablabla queue status, balbalba...

		5) we get the printer queue data, whatever the filter
generates and
		   we translate it into nice HTML with the given
		6) we serialize that document to the client (HTTP)...

		Using such a mechanism, we can, for example, send faxes,
send print
		jobs, send emails, and have the status of that operation
sent back to
		the client...
		It's kinda stretching the "filter" idea, but I believe we
can do it...
		Comments :????? :)

			Pier (going home...)

		pier: stable structure erected over water to allow docking
of seacraft

View raw message