Actually I evaluated XSL-FO rendering engines quite excessively including Apache FOP. At that point in time (2009) Apache FOP still had performance issues in scenarios where you would generate thousands of business correspondence documents to be sent to clients on a daily basis. In the end we decided to go with a commercial XSL-FO rendering engine vendor where we had been using Apache FOP initially. Additionally at that point in time the most recent Apache FOP version did not have an open source approval which is of course an IBM-internal detail.
The reason why we picked a commercial XSL-FO rendering engine was it's stability, some proof records such as clients already using this particular commercial XSL-FO rendering engine and it's feature richness such as AFP and 2D barcode (e.g. data matrix) support which is essential if you want to directly print to commercial printers. IIRC besides those issues one issue that probably applies to any XSL-FO rendering engine at least to a certain degree is that depending on how much time you spend on the XSL stylesheet it might be pretty expensive (in terms of man hours) to reassemble the layout of the original ODF document in the PDF document (e.g. the final document generated during runtime does not look the same to what has been defined by the business user during design time either using Symphony or OO). Hence my statement that it would have been nice if the core Symphony/OO ODF->PDF transformation would have been available as a separate library/module which could have been run on the server (AIX or z/OS). That way the business user would have been using the same transformation engine as the one used on the backend. These days, if I would be in a position to redo the design I would be tempted to figure out whether the whole transformation process could be off-loaded to a self-contained appliance such as datapower XA35 or even XI50. The datapower blade extension unit would even offer to off-load MIPS from the mainframe, something that illustrates that efficient ODF transformation is key in commercial environments where MIPS are expensive. But anyway I guess this scenario is a pretty advanced scenario cause it involves a distributed server infrastructure and a business application that generates large amounts of either PDF or AFP documents on a daily basis. Cheers Daniel On Wed, Jun 8, 2011 at 6:51 PM, <robert_w...@us.ibm.com> wrote: > dsh <daniel.hais...@googlemail.com> wrote on 06/08/2011 12:15:52 PM: > >> >> Of course we had been using ODFDOM but the issue is how do you get ODF >> transformed accordingly to other formats such as RTF, AFP or PDF and >> make those formats look consistent with what you would get if doing >> the transformation natively during design time in OO or Symphony. >> >> > > I think your observation is correct. The ODF Toolkit does not currently > have a good way of generating print or print equivalent output from an ODF > document. The Toolkit had no layout or rendering support. > > But I wonder if this is something that Apache FOP could help solve? > > The styling vocabulary of ODF is loosely borrowed from XSL Formatting > Objects (XSL:FO). It may be possible to generate XSL:FO from ODF much > more easily than converting from ODF to PDF or Postscript directly. But > once we have the XSL:FO intermediary, then the pipeline could continue > with Apache FOP to target formats ranging from PDF to raster images. > > Does that sound plausible? Someone needs to do the layout and rendering. > But I hate to see that code written more than once. The ODF->XSL:FO > conversion would be a great toolkit enhancement. Has POI done this with > the Microsoft formats? > > -Rob > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
