For those of us on the Office Interoperability team, as well as our colleagues throughout Office, today is a big day. We’ve released SP2 (Service Pack 2 for Office 2007), which includes a bunch of updated features. Gray Knowlton has a roundup of what’s new in SP2, but I think the feature of most interest to readers here is probably the built-support for ODF 1.1.
I first mentioned our plans for ODF support in a blog post last year, and I’ve also blogged in the past about the guiding principles that we followed in our ODF implementation. Our decision to support ODF is just one aspect of Office's broad commitment to choice and interoperability, as covered by Tom Robertson today on the Microsoft on the Issues blog.
For today’s post, I thought I’d put together a hands-on example of a typical user experience when working with ODF and Office 2007 SP2. I’m going to focus on a typical document creation and editing scenario in Word. Specifically, I’ll go through these steps:
The starting point. As a first step, I’ll create a document we can use as a starting point to try out some things. So I select File/New in Word, add some text, insert a few of the things we all use regularly in documents (a title, headings of various levels, a numbered list, and a table), and do some simple formatting. Here's how it looks:
The next step is to save this as an ODT document. That’s pretty simple – – just click the Office Button, move your mouse to ‘Save As”, and then select “OpenDocument Text” from the menu. Before I go any further, it’s worth noting a couple of things about this step:
Now I’ll open this document in OpenOffice version 3.0.1. In a future post I’ll look at differences between various existing ODF implementations, but for today’s post I’m just going to stick to OpenOffice 3.0.1 and Office 2007 SP2.
When I open my ODT document in OpenOffice Writer, here’s what it looks like:
As you can see, the document looks essentially the same in both applications. The page break is the only obvious difference – it occurs at a different point in the document due to differences between the default line-spacing values used in Word and OpenOffice. Other than that detail, the document looks the same in both applications, with the same fonts, formatting, headings and content.
The line-spacing variation is something you can see in other ODT documents and other ODF implementations as well. For example, if you open the latest draft of the ODF 1.2 specification (OpenDocument-v1.2-cd01-rev06.odt) in IBM Lotus Symphony 1.2.0, it is 931 pages long, but if you open the same document in OpenOffice Writer 3.0.1, it’s 875 pages long. These types of variations demonstrate a fundamental difference between a fixed-layout format (such as PDF or XPS) and a flow-oriented layout like ODF or Open XML. Flow-oriented formats work well for dynamic editing activities, whereas fixed-layout formats rigidly pin down the layout of a document so that it will be rendered exactly the same on different devices. For these reasons, most people prefer to use a flow-oriented format during document authoring and editing, and a fixed-layout format for published documents that are no longer being edited.
Getting Fancier. Now let’s move on to some fancier formatting and see how that works. I’m going to open this document in Word and make a variety of changes:
As a result of these changes, my document now looks like this in Word:
And if I save that version as an ODT file and open it in OpenOffice, I see this:
You’ll notice that many things are identical in both Word and OpenOffice, and a few things look a little different in each application. Here are some things that are the same in both applications:
And here are some things that appear differently in the two applications:
If you’d like to test these sample documents yourself, they’re in a ZIP file attached to this blog post (below).
Getting more information. This demonstration was just a simple example, for those who are curious about how the new built-in ODF support works in Office. You can find more detailed information about SP2’s support for ODF 1.1, including which features are supported by Word, Excel and PowerPoint, at these links:
Going forward, I’ll be doing some blog posts that get down into more of the technical details, to help explain some of the engineering decisions that we made in our implementation. For example, tracked changes functionality is of interest to many users, so I’m working on a post to cover why we decided to not implement tracked changes in ODF.
What else would you like to understand about our implementation of ODF? Share your questions and thoughts in the comment thread, or email me (dmahugh at microsoft dot com) if you have suggestions for topics you’d like to see covered here. I’m very proud of the work my colleagues on the Word, Excel and PowerPoint teams have done to add ODF support, and I’m looking forward to discussing the details now that SP2 has been released.
PHPPowerPoint 0.1.0 was released last week, as an open-source PHP API for generating PPTX files, much
Mitch, there is no “filter” involved – it’s built-in support. What made you think that it’s a filter? (I can’t find any place I’ve ever used that word regarding our ODF support, but would be glad to correct it if I have.)
Also, your claim that docx is a proprietary format is hard for me to understand. There are many implementers who have written code to generate DOCX files by working directly with the ECMA376 spec – in what sense are the resulting DOCX files proprietary?
Regarding your questions:
- as we read the specification, tables in presentations are not allowed in ODF 1.1 – that was added in ODF 1.2, which is not yet an approved or published standard
- the tables issue was pretty thoroughly debated a couple years ago during the DIS29500 process; Open XML has three table models, each optimized for a particular document type, and ODF uses a single table model across all document types
- we store formulas in our own namespace; this is the only option available in any of the published versions of ODF. I will be writing about this in more detail in another post later this week.
- the encryption approach used by our implementation of Open XML is documented at http://msdn.microsoft.com/en-us/library/cc313071.aspx, and code samples are available at http://offcrypto.codeplex.com/
Your other comments seem to be more about OO’s plans than Office’s implementation, so I can’t add to those.
Rob Weir posted on his blog a couple of days ago an Update on ODF Spreadsheet Interoperability .
@dmahugh: reference to Office 97 installer: "additional file format filters"
if you think of a better shortcut term, please tell me :)
ECMA376 relies upon but doesn't describe formats such as VML although they are declared 'deprecated', relies upon but doesn't describe paper sizes internal to MS Office (non-compliant with ISO paper sizes), relies upon non-standard leap years and date formats. Were it really open, it would have been accepted as-is by ISO, instead of being strongly edited (1,000 modifications required for 6,000 pages, published 8 months after it 'became a standard' instead of 6 weeks). And stop me if I'm wrong, but currently no Office version complies with ISO 29500:2008.
About the rest of my comment, it was directed at Ian.
About tables: yes, it was debated for DIS29500. However, I fail to see how ODF 1.1 can't accept tables in a presentation, as there are no differences between ODT, ODS, and ODP apart from the last letter: their XML manifests and contents are identical, so like a text document can include a table, so does a presentation - Impress couldn't add a table to an ODF 1.1 presentation but Kpresenter could, and so can OO.o 3, even when setting the ODF compliance to 1.0/1.1.
ODF 1.1 thus supports tables in presentation documents.
There is NO reason Powerpoint would scrap a table added to an ODF presentation, since the currently standardized format accepts it, except to artificially limit the export filter. It's not because an (now outdated) application didn't support that particular feature that it can't be done.
Doug, I 100% agree to Rob that SP2 is a step BACKWARD on the road of interoperability. That's because it simply destroys the de facto interoperability that exists between all other suites - it creates spreadsheets that can be manipulated with MS Office ONLY.
Of couse, OpenFormula is not an official standard yet, but why has Microsoft chosen to break this de facto alignement ? Hopefully, OpenFormula WILL BE an ISO standard in a few months. What then ?
How will you explain that to European countries that are now fully commited to ODF in their public administrations ?
On a short term, it will be good for Microsoft business & monopoly. But for medium & long term, it's suicidal. People - even non-technical - ARE INFORMED on your moves.
We keep an eye on Microsoft...
When I blogged about the release of SP2 with ODF support two weeks ago, I mentioned that I was planning