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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs