4 Jun
2008
4 Jun
'08
11:13 p.m.
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:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On Jun 4, 2008, at 8:33 PM, Sergiu Dumitriu
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol 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 working
fine.
Thanks
-Vincent
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.
>
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/