If you’re an Office 2007 user, the image above probably looks pretty familiar. But look close, and you’ll see some Save-As options you’ve not seen before here: OpenDocument, and (unless you have the existing add-in) PDF & XPS.
This is a screen shot of a pre-release copy of SP2 (Service Pack 2) for the 2007 Microsoft Office System, showing the new document format standards that we’ll be supporting starting with SP2. We’ve made an announcement of this and several related things today, and you can get all the details in the press release, and watch for additional perspective that will be provided by Gray Knowlton and Jason Matusow on their blogs today. I’ll provide a few details here on our technical goals in implementing ODF, the planned user experience, and a few aspects that I think will be of particular interest to developers.
It’s exciting to be announcing built-in support for these standards, but I think it’s worth noting that this isn’t a new direction for Office, but rather the continuation of a long tradition of adding support for additional formats. Office supports a variety of document formats, including the legacy binary formats, the Office Open XML formats, HTML, RTF, text, and many others. Support for multiple document formats provides many benefits to Office users, including the ability to choose the format that best meets each customer’s needs, whether those needs are interoperability, archiving, performance, or standards support. The addition of built-in ODF, PDF and XPS support are logical steps to address the evolving needs of Office users.
ODF, PDF and XPS as built-in file formats. We’re making these new formats work just like the other formats Office supports, in a seamless and integrated fashion. When you click the Save As Type dropdown, for instance, you’ll see a list which includes ODT, PDF and XPS in the same list where you’ll find DOCX, DOC, and many other formats.
And of course users can set ODF to be the default format if they wish, the same way they would for other Word, Excel or PowerPoint formats.
What about the SourceForge translator projects? Microsoft has helped launch open-source translators on SourceForge that can be used for translating between Open XML formats and ODF, UOF or DAISY XML formats. We will continue to invest in these projects, because they enable scenarios that our built-in ODF support in Office doesn’t address.
For example, the XSLTs from the SourceForge translator projects can be used by developers working on any platform, in any language. This provides many benefits:
- The translators have been used to enable interoperability on multiple platforms, including Novell (SUSE Linux) and Ubuntu redistributions
- The translators enable domain-specific heterogeneous scenarios, such as batch processing through a command-line interface and web service/mail server/portal integration scenarios.
- The open-source XSLT architecture provides fundamental mapping information between ODF and Open XML that is useful for implementers.
- The ODF translator project will continue to enable ODF read/write in Office XP and Office 2003.
Third-party translators. We anticipate that some developers may want to take over the default ODF load and save paths, so that they can plug in their own translators for ODF, and we’ll be providing an API in SP2 that enables this scenario. This means that if a developer disagrees with the details of our approach and would like to implement ODF for Office in a different way, they’re free to do so and can set it up such that when a user opens an ODT attached to an email or from their desktop, it will be loaded through their ODF code path.
That’s a first look at what we’re planning for ODF support in Office, and of course we’ll have much more to say as we get closer to the release of SP2. In the meantime, I’m very interested in what other developers and implementers feel is most important in our support of ODF and other standards. How can we work together to improve document format interoperability for the Microsoft Office system? What can we do better?