Open Standards

How to free yourself from Microsoft Office dependency in three easy steps

The Objective

When you save a document in your word processor, your work is encoded in a particular file format. You often have a choice of formats that you can use, with names like DOC, DOCX, RTF, WPD or ODT. Your choice of format will influence whether others can easily read your document today, whether you yourself will be able to read your document ten years from now, and whether you will be able to migrate painlessly to another word processor or operating system if and when you choose to do so.

Although many users simply click “Save” and give no thought to which format is being used under the covers, this unthinking use of the word processor’s default settings is a recipe for vendor lock-in. In fact, several vendors intentionally set their default format to be ones which will only work well with their own software, fostering dependency on that vendor’s software and lessening the user’s ability to take advantage of other options in the market. The more documents you save and accumulate in a vendor’s proprietary format, the harder it will be for you to consider any other choices.

The objective of this paper is to show you, the user, how to extricate yourself from this cycle of dependency and take control of your documents. Specifically, we show how you can, in three easy steps, free yourself from a Microsoft Office dependency. In the end you may, of course, choose to remain on Microsoft Office. You may decide to migrate to an alternative word processor. That, in the end, is your choice. But by following the three steps outlined below, your freedom of action will be preserved, and your choice of word processor will be based on your priorities and your needs, and not forced on you by your current application vendor.

Step 1: Take control of the default format

The older versions of Microsoft Office, Office 97-Office 2003), by default save documents in a family of binary formats with the extensions DOC (Word), XLS (Excel) and PPT (PowerPoint). Although these formats are proprietary Microsoft formats, over the past decade 3rd party applications have developed the capability to read and write these formats.

However, starting in Office 2007 Microsoft suddenly switched the default format to something called Office Open XML (OOXML). This format is not widely supported outside of Office 2007. So if you save a document in the OOXML format you make it harder for anyone else to read your document unless they are also using Microsoft Office 2007. In almost all cases, the same document, if saved in the legacy DOC format will be more interoperable. Staying with the default choice, OOXML, only restricts your choices and make you more dependent on Microsoft Office. Of course, that is why Microsoft made OOXML the default format.

The first step to liberate yourself from Microsoft Office dependency is to change the default format in Microsoft Office 2007 away from OOXML and back to the early binary formats supported by Office 97-2003, which are widely supported by 3^rd party applications. This is a neutral step that preserves the status quo. By making these changes you will still be able to read and edit any OOXML documents that are sent to you, but all new documents you create will be saved in the more widely supported DOC/XLS/PPT formats.

If you are using Microsoft Office 2003 or earlier, then you should skip this Step and move on to Step 2, since OOXML is not the default format in those earlier Office versions.

To change the defaults, you will need to load Word 2007, Excel 2007 and PowerPoint 2007 and follow the following steps.

Word 2007

Click the Office Button (the unlabeled logo button in the upper left of the program).
Click “Word Options” at the bottom of the dialog.
Go to the “Save” section.
For the “Save files in this format” setting, choose “Word 97-2003 Document(*.doc)”.
Click OK.

Excel 2007

Click the Office Button (the unlabeled logo button in the upper left of the program).
Click “Excel Options” at the bottom of the dialog.
Go to the “Save” section.
For the “Save files in this format” setting choose “Excel 97-2003 Workbook (*.xls)”.
Click OK.

PowerPoint 2007

Click the Office Button (the unlabeled logo button in the upper left of the program).
Click “PowerPoint Options” at the bottom of the dialog.
Go to the “Save” section
For the “Save files in this format” setting, choose “PowerPoint Presentation 97-2003”.
Click OK.

Administrators should also note that these settings may be made directly in the Windows Registry, and automatically pushed out to a work group via a login script or group policy. The registry settings corresponding to the above changes are:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Options Add String DefaultFormat=Doc

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Options
Add DWORD DefaultFormat=38 (Hexadecimal)

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\PowerPoint\Options
Add DWORD DefaultFormat=0 (Hexadecimal)

Step 2: Enable OpenDocument Format Support

Now that you’ve made the first steps towards taking control of your documents by preventing the lock-in effects of the OOXML default, it is time to take further control. You’ll now want to enable OpenDocument Format (ODF=ISO/IEC 26300) support in Microsoft Office, so you can save and exchange documents using the free and open International Standard while remaining in the familiar Microsoft Office interface.

ODF is an XML-based, open document format standard, designed to be platform- and application-neutral and support interoperable use across applications, eliminating vendor lock-in. ODF is supported by many applications, including office suites from Sun, IBM, Novell and Google, as well as open source projects like OpenOffice, KOffice and AbiWord. Additional applications supporting ODF are listed on Wikipedia.

Microsoft Office does not currently support ODF “out of the box”, but you can enable ODF support in Office by installing a “plugin”, sometimes called an “add-in”. A plugin will add additional options or menu items to the Microsoft Office UI, allowing you to open and save documents in ODF format. In some cases you can even set ODF as the default format for new documents.

There are three main choices for adding ODF support to Microsoft Office:

Sun Microsystems has published an “ODF Plugin for Microsoft Office” which supports Office 2000, XP, 2003 and 2007 SP1.
Microsoft has sponsored an open source project on SourceForge for an “ODF Add-in for Microsoft Office”, which supports Office 2007, and also Office 2003 and Office XP if the Microsoft Office Compatibility Pack is also installed
Microsoft has announced that Office 2007 Service Pack 2 (SP2) will enable ODF support in Office 2007, but this code is not yet available.

Step 2 is to evaluate and adopt a plugin to add ODF support to Microsoft Office. Start using ODF now, saving your documents in the open standard document format. This allows you to remain in Office, for now, while building your familiarity and comfort level with ODF.

Step 3: Exercise your Right to Choose a Native ODF Editor

The plug-in approach is a transitional approach. It allows you to continue working in Microsoft Office while you enable ODF support side-by-side. But at some point you will want to consider your options. Maybe you find that converting back and forth to ODF format in MS Office is slow. Maybe you are using Office 2003 currently, but want to avoid paying for an Office 2007 upgrade when mainstream support for Office 2003 comes to an end on April 14th, 2009. At some point you will want to move to an application that supports ODF natively. You are free at this point and have a wide variety of choices.

You can stay on Windows or consider moving to Linux or the Mac.
You can stay with a traditional client editor, or move to a web based editor.
You can use commercial software, or use open source software.

The important thing is that you have taken control of your documents. You are no longer dependent on Microsoft Office and its file format. You have broken free of the vendor lock-in. You are free to choose an alternative word processor when you want to and if you want to. Until then, be comfortable in knowing that you are keeping your options open while remaining in control of your documents.

This paper is also available in ODF and PDF formats.

In this post, I will look at the history of Vector Markup Language (VML), how it lost out to the W3C’s SVG back in the 1990’s, but has come back from the dead, showing up in the draft Ecma Office Open XML (OOXML) specification. I offer some opinions on why this is a bad thing.

First, a bit of history. The field is vector graphics, the type of graphics composed of lines and shapes and background fills, the type of graphics that scales nicely to different sizes/resolutions, and different devices, as opposed to raster graphics which is a bunch of pixels such as a GIF or JPEG file. This is a gross oversimplification, but it will suffice.

Vector Markup Language (VML) was an XML vocabulary for vector graphics submitted to the W3C by Microsoft and others back in mid-1998. I will not comment on its quality or merits, but merely note that it was rejected by the W3C in favor of Scalable Vector Graphics (SVG) specification which became a W3C Recommendation (that’s what the W3C calls their standards) in 2001. Since then, SVG 1.0 was upgraded to SVG 1.1. in 2003 and several mobile profiles (SVG Tiny and SVG Basic) were created. SVG has native support in Firefox and Opera, with Plugins available for most other browsers. There is support on mobile phones and PDA’s. A search of Amazon.com shows 19 books dedicated to SVG. The SVGOpen Conference has been going for 5 years strong. This all adds up to SVG being an established, open standard, widely implemented with a thriving implementor/user community and signs of continued innovation. It is a standard with a past, a present and a future.

But what ever happened to VML? VML has been a dead-end, from a standards perspective, for 8 years now, an eternity in web time. I was not able to find any VML books on Amazon. I could not find any VML conferences (unless one counts the Virgina Municipal League’s get-together at Virgina Beach in October). However, there is some lingering VML support in Internet Explorer and Office. Developers still use VML to target those applications, but I wonder, is it done out of preference or out of necessity? Although it is the users who are portrayed as dinosaurs for not upgrading to Office 2003, doesn’t it seem like Microsoft Office and Internet Explorer are the ones in need of an upgrade? They should join the rest of the world and start using SVG rather dragging along a dead spec.

But it is worse than this. I wouldn’t have bothered writing this just to point out something you already know, that Internet Explorer slowly or never adopts relevant web standards. The thing I wish to bring to your attention is that VML, the same VML rejected in 1998, is now being proposed as part of the draft Ecma Office Open XML. Take a look for yourself (warning, 25 MB specification download!).

Section 8.6.2 of the spec (Ecma Office Open XML, Working Draft 1.3) says:

VML specifies the appearance and content of certain shapes in a document. This is used for shapes such as text boxes, as well as shapes which must be stored to maintain compatibility with earlier versions of consumer/producer applications.

How should one parse “earlier versions of consumer/producer applications”? Is this a circuitous way of saying “MS Office and Internet Explorer”?

Now take a look at Chapter 23, VML, pages 3571-3795 (PDF pages 3669-3893). We see here 224 pages of “VML Reference Material”, which appears to be a rehash of the 1999 VML Reference from MSDN, and in this form it hides itself in a 4,081-page OOXML specification, racing through Ecma and then straight into ISO. Is this right? Should a rejected standard from 1998, be fast-tracked to ISO over a successful, widely implemented alternative like SVG?

Why should you care? It is all about reuse.

If a standard reuses an already successful standard, it reuses the collective community wisdom that went into making that standard. It also reuses the considerable editorial effort in writing, editing and reviewing a technical specification. Reusing this effort lets the TC focus their time on on truly innovative aspects of their specification, and leads to a higher quality standard.
When you reuse a standard, you allow implementors to reuse the experience and knowledge they have already developed around that standard. Remember the 19 books dedicated to SVG? There is a lot of SVG knowledge out there. Why waste it?
Reusing an existing standard, especially a popular one like SVG, allows implementors to reuse the various code bases, both commercial and open source that support it. Why reinvent the wheel? Do you really want to rewrite a vector graphics engine? SVG has several good open source libraries including Apache Batik and librsvg.

Use SVG and you get reuse on three fronts. Stick with VML and the only thing that is reused is Microsoft’s legacy code. Using SVG is clearly the better choice.

I suggest that Ecma TC45 investigate this issue and consider moving off of VML and move to SVG, or at least demonstrate why it is impossible to do so. Why does the world need yet another XML vector graphics standard? If there is something missing in SVG (which I doubt) then why not work with the W3C to propose a enhancement for SVG rather than re-proposing the VML standard which was rejected back in 1998?

Again, I make no technical argument why SVG is or isn’t superior to VML. I merely note that SVG has been an adopted W3C standard for 5 years now and should have a presumption of suitability for the task, especially over a specification which were rejected 8 years ago.