From: "Bertrand Delacretaz" <[EMAIL PROTECTED]>
> On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote:
> >. . .
> > -------------------------------------------------------------
> > FOP uses iText as a PDF generation library
> > -------------------------------------------------------------
> >. . .
>
> Maybe the following scenario could help making FOP more
> "pipeline-oriented", making it easier to plug in various renderers,
> layout engines, debugging tools, etc.
>
> I'm just making up component names, hopefully understandable
>
> 1. FopParser parses and validates the input XSL-FO document
Not needed if using Cocoon as a pipeline.
> 2. FopPropertyResolver does its job, attributes inheritance, etc.
>
> Then two options:
> 3a. FopLayoutEngine (existing code, API-coupled as now) computes layout
> and produces PDF
>
> 3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the
> XSL-FO vocabulary but with all attributes explicity specified (as far
> as possible, I know there are some issues here).
3b
> After 3b, various XSLT transforms and/or XML-to-something converters
> can be plugged in using the well-defined and loosely-coupled SAX/XML
> interface.
>
> I think using XML/SAX to interface between future pipeline components
> (ParsingAndPropertyResolving -> Layout -> Serialization) opens up much
> more options than using java APIs for this, and could help keep FOP
> small and focused.
>
> If using Cocoon, being able to just resolve properties and pass the
> result on to various transforms opens up new horizons for XSL-FO
> processing.
This is the proposal I made, and I think it stands even stronger now.
If FOP is pipeline driven, any renderer can be quite easily plugged in.
AFAIK, the pipeline architecture is one of the major design differences that
in some way has been agreed on.
What I would like to see, is that FOP stops discussing about the logging,
resolving, pipelineing and stuff and starts to focus on the core
functionality.
IMHO, the best way to get this thing going *quick* is to use Cocoon as a
pipeline. Cocoon gives you all these features, and gives you a solid
framework to work on.
When it works on Cocoon, we can see if performance for stand-alone
processing is good enough. If not, we can *then* talk about the structure
around FOP, and break eventually free from Cocoon.
> At the other end of the pipeline, what about an XML-to-MIF
> converter, for example, much more generally useful than a
> tightly-coupled MIF renderer for FOP.
>
> Implementing 3b should be fairly easy (isn't that a serialization of
> the FOTree?), and we can go from here to reuse important parts of FOP
> as individual components.
I agree.
This can big opportunity also for other projects to collaborate in the
rendering.
JFor, for example (I don't remember who maintains it ;-P)
And POI. At POI, we are going to do a Word .doc format writer. It could fit
easily in this picture.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
