dare I candidly ask how math is processed? thanks in advance
paul 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 limitedcurrently. For one it doesn't export embedded images[1]. But it's going tosee 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 <[EMAIL PROTECTED]>:Cool ! I'm glad I could be of help ! Mirko will be happy to know you areworking with his code. Putting him on copy. LuisOn Wed, Jun 4, 2008 at 11:13 PM, Ludovic Dubost <[EMAIL PROTECTED]> wrote:Thanks Luis,This is indeed exactly what we need.. a web service and a java API atthe same time Wang you should use this.. expose it as an XWiki plugin with aconfiguration 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 serverthat 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 andJODReports: http://www.artofsolving.com/If not I thought it might be useful in the context of your discussion.Hiscode 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: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 workingVincent Massol wrote:On Jun 4, 2008, at 7:30 PM, Ludovic Dubost wrote: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 agree,First you need to package your code as an XWiki plugin that can becalled. This plugin should have as many conversion possibilities. doc or office -> xhtml xls -> xhtml doc -> openoffice openoffice ->doc doc -> pdf html -> pdf 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 througha 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 wikidocuments, though.fine. Thanks -Vincent+1 to this one, too. I think that direct data manipulation through OOoConcerning xls I think we should look into having an import thatdoes not go through html We might want to write xls to wiki tableis 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-- Luis Arias +33 6 14 20 87 93 skype : kaaloo_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
