[odf-discuss] News on MS pluggin

[marbux]

On 10/14/06, Alex Hudson <alex at stratagia.co.uk> wrote:
>
> marbux wrote:
> > You're right about the error in the article, but XML-to-XML is a
> > (deliberately?) poor solution in context. The major problem with the
> > MOOX-to-ODF approach  flows from the fact that  MOOX is not processed
> > internally by the Microsoft apps. It's part of an external process
> > that requires conversion to and from the binary formats.
>
> I think you're slightly confused here - Office 12 doesn't convert OXML
> to a binary format to load?
>
> The plugins for previous versions of Office do that, I believe, but not
> the latest one.


Nope. Office 12 also converts OOXML to the binary format to load. I suspect
the old cash cow has such severe osteoporosis that it couldn't survive the
surgery necessary to process OOXML internally. :-)

Here's how Jean Paoli put it:

"The Office Open XML file formats aren't a standalone file format. Rather,
they build on the rich functionality of the binary file formats that have
traditionally been a part of Office applications." <
http://www.microsoft.com/presspass/features/2005/nov05/11-21Ecma.mspx>.


> End result? The show-stopper is that with an XML-to-XML approach ODF
> > can not be set set as the default File New or File Save format.
>
> AIUI, it's not a format issue - it's the componentry in the UI which
> makes that hard (but not impossible).
>
>
I agree to an extent. It's not a format issue, but rather an implementation
issue. But it's a pretty big barrier.  Microsoft has proposed only one
work-around:

""Heck, if you wanted to be even more hardcore, the Office object model
allows you to capture the save event. So if you wanted to you could make it
so that anytime you hit save you always used the ODF format, just by
capturing the save event and overriding it. I'm not expecting folks to do
that, but it does show just how extensible Office really is."
<http://blogs.msdn.com/brian_jones/archive/2006/07/11/661843.aspx>.

But that isn't really a workable solution, as explained by Redmonk's Stephen
O'Grady:

""As I understand it, however, having queried Microsoft on this (and they
should feel free to correct me if I got it wrong) changing the default "Save
As" behavior is not possible. Well, technically it's possible, but not
without locking virtually everything else in the File menu down; a solution
that is not likely to be acceptable to wide audiences."
<http://www.redmonk.com/sogrady/archives/001877.html>

I.e., if you intercept the save event programmatically to save to ODF, you
can't save to any other file format, at least without adding manual
user-initiated actions for other file types akin to the menu selections that
Office 12 uses via the ODF Translator to save files as ODF. So setting ODF
as the default file save format remains problematic. As stated by one of the
Microsoft ODF Translator developers:

"We currently have no way of doing this. But ideas are welcome!"
<
http://sourceforge.net/tracker/index.php?func=detail&aid=1518638&group_id=169337&atid=850000
>.

One huge advantage of the OpenDocument Foundation plug-in is that it
addresses the same interfaces in the Microsoft apps used by the OOXML
translation layer, dealing OOXML out of the process. It undoubtedly took a
pretty impressive bit of reverse engineering to implement. The Foundation
plug-in allows ODF to be set as the default file format and thus avoids the
inevitable bugs introduced by an extra translation layer.

Best regards,

Marbux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20061014/ffcc41fe/attachment-0002.htm