cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <>
Subject Re: Printing [Was: Re: Project Coordination]
Date Sat, 08 Apr 2000 21:43:20 GMT
"Corda, Ugo" wrote:
> 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
> clarifications.
> 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?).

I believe you can... Let me think about it...

> In step 4 I would not talk about a fop serializer [...]

I used the FOP serializer because it's the only one I know dealing with
XSL-FO. I totally agree, it must be something converting XSL-FO into a
stream that can be sent to the printer.

> 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.

I agree with you on the concept of this... I still have to figure out
"how" to make it...

> 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.

Yes... more or less yes... There are a couple of things that
"technically" I'm still not sure on how could be implemented, but...


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

View raw message