This question didn't get answered yet, I think:
> The add-in for Microsoft Office uses the same code to do the same in
> reverse, correct? To save in .odt, MSO creates a .docx as a temporary
> file, then calls the binary to convert to .odt?
It uses the same code, but not by running a separate program. Hmm, actually now that I think of it I am not completely sure if it runs the conversion in a separate process or not. But anyway, yes, the actual format conversion uses the exact same pile of XSLT as the command-line odf-converter that one can use with OOo.
> 4. The credit above mentions Sun, but I don't see Sun mentioned here <
>
http://odf-converter.sourceforge.net/>. Is all the OpenOffice.org
> development for OdfConverter, including Sun's work, going back into the
> SF.net project?
Here you are confusing the "native" OOXML filters with odf-converter. The native filter code is in C++ and written by people at Sun and Novell. odf-converter is in C# with the majority of the actual "business logic" in XSLT, and written by people at Clever Age and their subcontractors (or whatever).
> 5. The OdfConverter version from Sourceforge requires .Net framework
> 2.0, but the version from download.go-oo.org seems not to.
Do you mean the OOo build with the "native" OOXML filters included in the GoOo build of OOo in their work-in-progress state, or the odf-converter builds for Linux and Windows? The former have nothing to do with .NET at all. The latter don't require the .NET framework even if they are C# code as they are built as Mono "bundled" executables (i.e. include the Mono runtime and class libraries).
As such it is possible to use the upstream command-line odf-converter with OOo on Windows instead of the Mono-built executable.
--tml
_______________________________________________
Dev mailing list
Dev@...
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org
