cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Corda, Ugo" <Ugo.Co...@usa.xerox.com>
Subject RE: Printing [Was: Re: Project Coordination]
Date Sun, 09 Apr 2000 18:25:40 GMT
Pierpaolo Fumagalli wrote:

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

If you are talking about how to get a pointer to the XML job ticket through
the pipeline, I imagine that would be done the same way it's done for other
types of information (i.e. sitemap and, possibly, some mechanism for
extracting information from the client request at run time -- this is
similar to getting printer information at run time). 

If you are talking about how to do the translation from XML job ticket to
Java Print parameters, I know there is currently work under way to define
XML encoding for print job tickets (e.g. Adobe's Job Definition Format
activity). I imagine it won't take too long to see Java code that convert
those XML job tickets into Java Print parameters (hopefully open source Java
code :-)).

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

I don't think there is much of this that need to be "implemented". In fact,
in FOP I can already do that today by using PrintCommandLine. That command
produces output for any printer that happens to be the default printer on my
platform. It can output to my local DeskJet, or even to a PDF file using the
Acrobat PDFWriter or Acrobat Distiller "printer drivers", without FOP
knowing anything about these printers or pseudo printers. Again, the current
limitation is that Java Print in JDK 1.2.2 does not allow you to specify the
printer as a parameter (but JDK 1.3 will), so you have to use the trick of
first setting a particular printer to be the default printer for the
platform where you are running.

If I can find the time, I'll try to create a new Formatter that does
printing in Cocoon 1.7.2 using existing FOP code, and see what can be
learned from that which could be applied to Cocoon 2.

Ugo


Mime
View raw message