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..

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 Ludovic Vincent Massol wrote: -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Yes but I like the idea of having a convertor based on the open office code. The PDF output of OO is very nice. BTW, it would be great to have a plugin that runs the OO conversion in the same machine but also a plugin that would call into a REST api to a server that would manage a conversion queue.

You will need the conversion queue anyway because you might have problems if you run multiple conversions at the same time

Vincent Massol wrote: 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.

+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/

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.

On Wed, Jun 4, 2008 at 8:37 PM, Vincent Massol <vincent(a)massol.net> 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.

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: His wrote: -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi all, I'd certainly be happy to add XWiki to the list of other open source projects that use JODConverter and provide suggestions if needed. I see you mention xhtml... well the OOo xhtml filter is quite limited currently. For one it doesn't export embedded images[1]. But it's going to see big improvements with OOo 3.0. You may also be interested to know that there's a new major version of JODConverter[2] in development. Cheers Mirko -- [1] http://qa.openoffice.org/issues/show_bug.cgi?id=22012 [2] http://jodconverter.wiki.sourceforge.net/v3.0 2008/6/5 Luis Arias <kaaloo(a)gmail.com>om>: > Cool ! I'm glad I could be of help ! Mirko will be happy to know > you are > working with his code. Putting him on copy. > > Luis > > On Wed, Jun 4, 2008 at 11:13 PM, Ludovic Dubost <ludovic(a)xwiki.org> > wrote: > >> >> 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 <vincent(a)massol.net> >> 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

I have a few questions about JODConverter.. - I see you already have a web service. How about a nice REST api for that web service, including username/password ?

- Do you have caching of your conversions ?

Ludovic Mirko Nasato wrote: to are wrote: service. and of that etc). the OOo -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

dare I candidly ask how math is processed?

Le 06-juin-08 à 00:34, Mirko Nasato a écrit : > Hi all, > > I'd certainly be happy to add XWiki to the list of other open source > projects that use JODConverter and provide suggestions if needed. > > I see you mention xhtml... well the OOo xhtml filter is quite limited > currently. For one it doesn't export embedded images[1]. But it's > going to > see big improvements with OOo 3.0. > > You may also be interested to know that there's a new major version > of > JODConverter[2] in development. > > Cheers > > Mirko > > -- > [1] http://qa.openoffice.org/issues/show_bug.cgi?id=22012 > [2] http://jodconverter.wiki.sourceforge.net/v3.0 > > > 2008/6/5 Luis Arias <kaaloo(a)gmail.com>om>: > >> Cool ! I'm glad I could be of help ! Mirko will be happy to know >> you are >> working with his code. Putting him on copy. >> >> Luis >> >> On Wed, Jun 4, 2008 at 11:13 PM, Ludovic Dubost >> <ludovic(a)xwiki.org> wrote: >> >>> >>> 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 >>>> <vincent(a)massol.net> >>> 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/

Hi Wang, On Jun 4, 2008, at 7:04 PM, Wang Ning wrote: cool :) What do you mean by plugin? Do you mean xwiki plugin (probably not)? You need to find out and propose how to integrate the import feature into xwiki both in term of UI and in term of code. The best right now is probably to add a button in the tiny MCE editor. I think we can do it in 2 steps: Step 1: get clean HTML. Since XWiki is able to display HTML it should work fine. This also means that the imported doc will be edited through the WYSIWYG editor (tinyMCE) Step 2: convert the HTML into wiki syntax wherever possible. This is indeed a job for the new rendering module and you'll need to write an HTML Parser (i.e. implementing the org.xwiki.rendernig.Parser interface). You should have a look at the 2 existing parsers: WikiModelXWikiParser and DoxiaConfluenceParser. In this case though you should use an XML parser to parse the XHTML instead of wiki model or doxia. Thus it's important that in step 1 you get clean XHTML (probably run JTidy on it).

You need to follow all the coding conventions and best practices described at dev.xwiki.org You need to provide a maven build yes. Plenty of examples in the xwiki source tree. The best is maybe that you package your code as a xwiki plugin for now. check xwiki-platform-plugins for examples of plugin and how they are packaged/built. Thanks -Vincent

It's probably not very difficult to add another HTML to XWiki converter[1] to the my Java Wikipedia API [2]. You can try the converter online at [3].

[1] http://plog4u.svn.sourceforge.net/viewvc/plog4u/info.bliki.wiki/src/info/bl… [2] http://matheclipse.org/en/Java_Wikipedia_API [3] http://jtidy.de/

On Thu, Jun 5, 2008 at 9:35 AM, Vincent Massol <vincent(a)massol.net> wrote: > > On Jun 4, 2008, at 7:21 PM, Vincent Massol wrote: > >> Hi Wang, >> >> On Jun 4, 2008, at 7:04 PM, Wang Ning wrote: >> >>> Hi, >>> >>> I have built a standalone plugin to convert MS Doc, MS excel to >>> html. >> >> cool :) >> >>> This >>> plugin can run as a jar through command line or as a web >>> application through >>> url. >> >> What do you mean by plugin? Do you mean xwiki plugin (probably not)? >> >> You need to find out and propose how to integrate the import feature >> into xwiki both in term of UI and in term of code. The best right >> now is probably to add a button in the tiny MCE editor. >> >>> Next, how to convert the html to xwiki syntax document? use xslt? >>> Do the new >>> rendering code have any influence? >> >> I think we can do it in 2 steps: >> Step 1: get clean HTML. Since XWiki is able to display HTML it >> should work fine. This also means that the imported doc will be >> edited through the WYSIWYG editor (tinyMCE) >> Step 2: convert the HTML into wiki syntax wherever possible. This is >> indeed a job for the new rendering module and you'll need to write >> an HTML Parser (i.e. implementing the org.xwiki.rendernig.Parser >> interface). You should have a look at the 2 existing parsers: >> WikiModelXWikiParser and DoxiaConfluenceParser. In this case though >> you should use an XML parser to parse the XHTML instead of wiki >> model or doxia. Thus it's important that in step 1 you get clean >> XHTML (probably run JTidy on it). > > Just found that some wikimodel guy is working on converting xhtml to > wiki syntax: > http://code.google.com/p/wikimodel/issues/detail?id=5 > > Might be worth talking to him to see how he's progressed since we > might want to use his work and possibly even help him. > > Thanks > -Vincent > >>> Now I can't handle the clipboard format. I think clipboard is at >>> the second >>> priority. >>> >>> My another question: how to add my code to xwiki code sandbox? Do >>> I need to >>> build ,test and distrubut my plugin by maven way? If yes, please >>> tell how. >> >> You need to follow all the coding conventions and best practices >> described at dev.xwiki.org >> You need to provide a maven build yes. Plenty of examples in the >> xwiki source tree. >> The best is maybe that you package your code as a xwiki plugin for >> now. check xwiki-platform-plugins for examples of plugin and how >> they are packaged/built. >> >> Thanks >> -Vincent