Re: [xwiki-devs] [PROPOSAL] Use openoffice server when its enabled to do PDF/RTF export

Hi, Big +1. I also wanted to try out wiki page exporting using office importer api (well, now it's more like office converter api). The interesting thing is with openoffice we can convert html into many other formats (word, pdf, rtf etc.). It would be interesting to find out the quality of these exports. Also we should think about dividing xwiki-officeimporter into sub-modules like xwiki-officeconverter, xwiki-officeimporter and xwiki-officeexporter.

Thanks. - Asiri On Fri, Jun 18, 2010 at 4:08 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote;wrote: > Hi devs, > > Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is > a real pain, i.e. using FOP. That would need a XSLT wizard and anyway > RTF support is not very good in FOP (according to FOP documentation). > And seriously for a format like RTF it's a waste of time IMO. > > So what i propose for 2.4 is to do a small modification to PDF/RTF > exporter to use openoffice server when it's connected. There is > already everything needed for that in openoffice component which is > used for office import currently. > > That would be a good POC for the future office exporter which will > need a lot of refactoring and API to be clean. For this proposal I'm > just modifying PdfExportImpl is a as clean as possible way to have > this in 2.4. > > The only limitation currently is that OpenOffice does not really > support XHTML and parse the content as it was HTML but since we have > the same constraint with IE6 it's OK for now I guess. See > http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more. > > WDYT ? > > We should probably not show RTF export in the menu when openoffice > server is not connected since it does not work at all even with empty > content or remove the table generated by the XSLT filter for the > cover. > > -- > Thomas Mortagne