On Thursday 18 October 2001 23:06, Art Welch wrote: <snip> > My concerns are that if jfor excels at speed at the expense of > presentation. > > 1. Are jfor users going to be happy with jfor integrated with FOP > which seems to favor presentation over speed? > > 2. Would FOP users be happy with the RTF generated if it loses > presentation information? <snip>
Thanks for putting this up - the thing with RTF is that there is a fairly strong similarity between XSL-FO and RTF constructs, that does not need any layout work in the FO->RTF transformation (we had a good discussion about this earlier this year on this list). The layout is done later by the wordprocessor when the RTF file is opened. Hence jfor being called an XSL-FO to RTF *converter* and not *formatter*. jfor does a fairly simple mapping of XSL-FO elements to RTF constructs, hence the speed and small code size. So, technically I think the initial merging might see jfor sharing only some infrastructure with FOP (command-line and Cocoon invocation mechanisms, configuration, logging, parser, etc.), with a "-rtf" option that would more or less "switch" between jfor and FOP for processing of the XSL-FO elements. This is of course going to be discussed with the FOP community, I'm only thinking outloud here. As Stefano rightly mentioned in the private discussion that lead to this merging proposal, such a "side-by-side" merging would already be a big advantage for *users* of FOP who would get RTF output for free, without needing separate downloads and configuration. Not to mention increased visibility for both projects. Later on, we will have to refactor the jfor code to use more of the the FOP codebase where it makes sense. This might lead to new interfaces between FOP and its renderers (post-processors?), where a renderer could be plugged in at an earlier stage of the FOP formatting chain, not necessarily after the layout stage. So, IMHO jfor would not be a FOP renderer per se initially, but might become one later in the integration process. -- -- Bertrand Delacrétaz, www.codeconsult.ch -- jfor.org lead developer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
