Thanks Luis, This is indeed exactly what we need.. a web service and a java API at the same time Wang you should use this.. expose it as an XWiki plugin with a configuration option to run embed or connect to an existing web service.
My idea is that we ship XWiki configured by default to talk to a server that we would host on our platform. Ludovic Luis Arias wrote: > Hi everyone, > > Sorry to pop in, but I imagine you are aware of Mirko's JODConverter and > JODReports: > > http://www.artofsolving.com/ > > If not I thought it might be useful in the context of your discussion. His > code is used by Nuxeo, Alfresco, and others and is very simple to use. > JODCOnverter plugs into OO running in server mode. > > Good luck, > Luis > > On Wed, Jun 4, 2008 at 8:37 PM, Vincent Massol <[EMAIL PROTECTED]> wrote: > > >> On Jun 4, 2008, at 8:33 PM, Sergiu Dumitriu wrote: >> >> >>> Vincent Massol wrote: >>> >>>> On Jun 4, 2008, at 7:30 PM, Ludovic Dubost wrote: >>>> >>>> >>>>> I agree, >>>>> >>>>> First you need to package your code as an XWiki plugin that can be >>>>> called. >>>>> This plugin should have as many conversion possibilities. >>>>> >>>>> doc or office -> xhtml >>>>> xls -> xhtml >>>>> doc -> openoffice >>>>> openoffice ->doc >>>>> doc -> pdf >>>>> html -> pdf >>>>> etc.. >>>>> >>>> hmm not sure. We only need xhtml I think since it's then the role of >>>> the XWiki HTML Parser to generate an internal DOM. Once we have that >>>> DOM we benefit from all the renderers (PDF, XHTML, RTF, Latex, etc). >>>> >>>> >>> I second Vincent, for the moment the priority is to have wiki >>> documents. >>> But then I agree with Ludovic, that it would be better to convert >>> attachments to different formats using the OOo codebase. The pdf >>> export >>> done now affects only wiki documents, not attachments, and going >>> through >>> a long chain of conversions (.doc -> wiki -> xhtml -> xsl-fo -> pdf) >>> will only introduce possible problems at each conversion, while a >>> direct >>> conversion doc -> pdf using the (better) OOo code is simpler and >>> easier. >>> We can (and should) keep the current PDF export mechanism for wiki >>> documents, though. >>> >> I think we should make the PDF export a secondary priority and get the >> rest working for now. Let's revisit it when all the rest is working >> fine. >> >> Thanks >> -Vincent >> >> >>>>> Concerning xls I think we should look into having an import that >>>>> does >>>>> not go through html >>>>> We might want to write xls to wiki table >>>>> >>>>> >>> +1 to this one, too. I think that direct data manipulation through OOo >>> is better than reverse-engineering html, and not just for >>> spreadsheets, >>> but other types of documents. >>> -- >>> Sergiu Dumitriu >>> http://purl.org/net/sergiu/ >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> >> > > > > -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
