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.
Anyway I suspect that's an off-topic detail that may distract others from the initial intent of this thread. Cheers Daniel On Wed, Jun 8, 2011 at 6:04 PM, <robert_w...@us.ibm.com> wrote: > dsh <daniel.hais...@googlemail.com> wrote on 06/08/2011 10:37:46 AM: > >> >> On Wed, Jun 8, 2011 at 3:58 PM, <robert_w...@us.ibm.com> wrote: >> > A sufficiently complex business application based on OpenOffice is > going >> > to involve document manipulations at both tiers. For example, we > recently >> > (at IBM) made an insurance solution that involved using Symphony, > extended >> > with a Plugin, submitting documents into a workflow, where they were >> > introspected and validated using the ODF Toolkit. >> > >> >> Of course the ODF Toolkit isn't a golden fleece for server side ODF >> processing. I would rather call it a good compromise offering some >> room for improvement. If we would have had a choice we would have >> preferred a headless OO runing on either AIX or z/OS ;) For instances >> you still have to code a comprehensive amount of XSL stylesheets if >> using the ODF toolkit. One drawback we faced was that customers >> created their ODF documents during design time using Symphony and >> during runtime while mass-producing business correspondence documents >> the ODF Toolkit generated documents which were not 100% formatted >> equal to what has been created in Symphony earlier on. Thus our >> preference to use the same formatting engine (i.e. Symphony/OO) during >> both design time and run time. >> > > The ODF Toolkit Union has several projects. It sounds like you have been > using the XSLT Runner component? > > We also have ODFDOM. This is a Java API that uses a code generation > approach, giving a typed DOM that is 1:1 with the ODF schema. So this can > read and write documents and preserve 100% of the its contents, > formatting, metadata, etc. > > On top of that (we all need layers, right?) we have the Simple Java API > for ODF, which is a high level API for manipulating the document. So > things that might be a complex operation touching many ODF elements, like > deleting a column in a table, are done in a single function call in the > Simple API. We also took a set of "navigators" to select interesting > content in the document. So you can do a regular expression search and > replace. But also search for all text with style = "header 3" and then do > something on it. You can extract the text of a document in one line of > code. You can copy a presentation slide from one presentation and put it > into a another in one line of code, etc. The cool thing, in my opinion, > compared to other ODF API's, is because the Simple API is based on ODFDOM > and ODFDOM is generated from the ODF schema directly, then the Simple API > manipulations preserve all of the existing document content. > > You can see the details here: http://simple.odftoolkit.org/ > > We also have a validation component, with tools for validating conformance > of ODF documents, > > And we have a C# ODF API, which I don't know so much about. > > > Regards, > > -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
