The premise of these articles is that the world would be a much better place if all governments would publish all of their information on the web in HTML or XML. You know what else would make the world a much better place? Unicorns.

The issue at hand is not whether governments should pick HTML or PDF. The issue at hand is whether governments are capable of publishing information at all. Show me an HTML creation tool that creates high quality, standards conformant markup from a Word document or any of the zillions of editing tools that government employees use. Now add in all the tools used by people who submit documents to the government. And all the versions of those tools released in the last 20 years. Now make sure that the HTML/XML works correctly even when the user doesn’t have the right browser or the right fonts installed. Guess what? There are no such conversion tools available. And who would pay to make sure that everyone had access to these tools and knew how to use them correctly?

Creating PDFs is trivially easy for all these cases, whether you use Acrobat or something built into your OS. It works regardless of what tool was used to create the content in the first place, and it works on pretty much every OS out there and on mobile.

HTML/XML Standards nerds should get a grip. They aren’t even in the running to compete with PDF here.

But doing a clean install also meant reinstalling my apps, and this time around, I decided not to install the old version of Microsoft Office I’ve been using for years. We don’t have a license for Mac Office 2008 here at Adobe yet, so I’m going to try living with Buzzword for word processing and Keynote/Numbers for presentations and spreadsheets. All three apps can even open OOXML documents, so I rarely get stuck with a document I can’t read. For those cases and to read Adobe email, I use a VMWare image running XP and Office 2007.

My system is a ton faster without any Rosetta-based PowerPC apps running on it, and buzzword is a lot more pleasant to use than Word.  When we do get access to the new version of Mac Office I’m going to have some interesting choices to make.

Contrast that with the process by which Adobe is submitting PDF to ISO. We’ve bent over backwards to ensure that the submission is as clean as it can possibly be, and as a result the feedback we’ve gotten has been extremely positive. If Microsoft believes their own stuff is so great, they should follow our lead and make it into a standard the right way: by proving the value of their solution, responding to constructive criticism, and building a consensus.

I’m bummed, personally – the current Mac Office just blows on MacTel. And of course it also means that all of us Mac Office users be dealing with the PITA of getting .docx, .pptx, and .xlsx files in email and not having a good way to read them for even longer. Oh well. Five months isn’t that long to wait.

[Update: Aug 2 2007 9:49 Pacific] An even better article at MacWorld. I loved this quote:

“It was my call, but this wasn’t Craig coming in and saying, ‘We need more time,’” Eisler said. The delay was not due to the addition of any new features, he added, but rather was the combination of a “perfect storm” of factors that hampered the development effort.

“We switched to Intel, and Office changed file formats,” Eisler said. “It was no one thing. This release was harder than most just because of all those things happening at once.”

So one of the main causes of the delay is the need to support OOXML, huh? Interesting.

While we wait, there is more on that front, this time from India, where the technical committee there is still considering Ecma-376 issues. Earlier, we mentioned to you some questions that Dr. G. Nagarjuna, Chairman FSF India, submitted to the Working Committee, Board of Indian Standards on Wordprocessing. In this Issue Sheet [PDF], we find answers from Microsoft’s Vijay Kapur, followed by responses from Dr. Nagarjuna.

For example, here’s one such exchange:

Backward compatibility for all vendors: Can any third party regardless of business model, without access to additional information and without the cooperation of Microsoft implement full backward compatibility and conversion of such legacy documents into MS-OOXML comparable to what Microsoft can offer?

Mr V. Kapur: Implementing backward compatibility is an application function not a file format specification requirement. The ECMA 376 specification is capable of faithfully representing information in the legacy binary file formats. This point was treated in detail in the response to the question raised by Dr. Nagarjuna. Microsoft can offer? Availability of Binary File Formats — It is to be noted that Microsoft has made the .doc, .xls, and .ppt binary file format specifications available under a royalty-free covenant not to sue to anyone who wishes to implement all or part of these specifications in their products. Anyone can get access to the specification now, using the method described in the following Knowledgebase article at the link: http://support.microsoft.com/default.aspx/kb/840817 – How to extract information from Office files by using Office file formats and schemas (relevant extract below)With both format specifications being available for a developer, a converter can be written in such a way that a DOC or XLS document can be converted into an Open XML document with content and representation intact. This point should be treated as closed as there is no contradiction.

Dr. Nagarjuna: Availability of the specification of binary formats does not solve the problem of another vendor’s ability to implement. What is required is a mapping between the existing proprietary formats and OOXML if the stated objective of OOXML, namely, to faithfully represent legacy formats in XML is to be met. The link provided by MS is not an article. It is misleading to say so. MS did not publish the specification of proprietary documents at any accessible place. They are promising to provide to those who sign an MOU with the company. This is unacceptable since, implementing this standard mandates the need for private understandings. That is not the purpose for which standards are specified. They are specified precisely to eliminate such a requirement. The question asked was a very serious and a CORE issue: the answer given is not satisfactory. A satisfactory answer to this consists in publishing the mapping between OOXML and proprietary documents. Since this is not the case, the issue is open, and forms a sufficient reason to vote against OOXML.

Pretty compelling stuff. The article also discusses Microsoft’s recent spin on the whole ballet-stuffing issue Rob Weir brought up so eloquently recently. This is the same issue I raised obliquely a few months back, because I didn’t have the evidence to back up the rumors I’d heard, and I’m glad to see that Rob and company have managed to shine some light here.

[Updated 6-22-2007] some text in the first paragraph was inexplicably missing. Copy/paste error? Not sure, but I’ve added it back…

[Updated 7-27-2007] In related news, more shenanigans in Spain and Portugal. The article is a bit overheated in its rhetoric, but it does look like there is some basis for the accusations.

But it seems like this is the time to revisit the situation, because yesterday Microsoft announced the availability of a beta version of a tool called the Microsoft Open Office XML File Format Converter for Mac. Catchy name, huh? What this standalone 25MB download does is convert Word 2007 .docx and .docm files into RTF, which can then be imported by Word 2004 for the Mac. No support for Excel or Powerpoint, which Microsoft had previously promised for Spring 2007. Funny that it doesn’t export directly to .doc, though, since I thought the whole point of OOXML was its 100% fidelity with existing Microsoft Office document formats. Now Microsoft says conversion to RTF is “good enough” for those pesky Mac users:

Why Rich Text Format? RTF (once called the “interchange format”) is simply a highly convenient intermediate format for the beta converter to use; I’ll let one of our Word experts (like Rick) expand on the technical reasons why this is the case if there’s interest.

Seems to me that if RTF is good enough as an interchange format, ODF should also qualify since it is at least as functional as RTF! Can’t wait to hear what new rationalization Rick and company come up with for this one…

But that’s not all the bad news. Hidden in the announcement of the tool is the news that the release of Office 2008 for the Mac later this year will not include native OOXML capability – that will arrive sometime later (they say the tools for Mac Office 2004 will arrive 6-8 weeks later, but don’t specify a date for the Mac Office 2008 version). I’m not the only one who has figured out the blatant spin here, see CNET, Wired, and TUAW.

And that, of course, brings us back to Rick Schaut’s original rationales for the OOXML support in Mac Office. Wonder if he still thinks they made the right call? Sure feels to me like my “serious” estimate of 40 man years to fully implement OOXML support wasn’t far off the mark…

Today I read a post by Eliotte Rusty Harold on why VRML failed and why OpenOffice needs to make their product work better on the Mac. I was particularly struck by this part:

The real reason VRML failed is that Mac market share approached or exceeded 50% among the Web designers creating the early Web in the mid-90s. Every web shop in business at the time was just raring to jump on the next hot bandwagon, but when they looked at VRML the first thing they saw was that there weren’t any tools for them to use. So instead they looked at Java, Shockwave, Flash, HTML, Acrobat, and other things that at least ran on the Mac, even if they didn’t run well. VRML never recovered.

I think you could argue whether that was the sole reason why VRML failed, but I don’t think there is any question that the lack of support for the Mac played a huge part. And the important part was to have the tools available on the Mac too, not just the runtime. This is a lesson Adobe has always taken to heart, as did the former Macromedia. And this cross-platform support is one of the main reasons why Flash, Acrobat, Photoshop, etc. have been so successful over the years.

Separately, Joel Spolsky of Joel on Software fame has written about the recent decision to kill VBA in Mac Office. In that post, he writes:

But what’s really interesting about this story is how Microsoft has managed to hoist itself by its own petard. By locking in users and then not supporting their own lock-in features, they’re effectively making it very hard for many Mac Office 2004 users to upgrade to Office 2008, forcing a lot of their customers to reevaluate which desktop applications to use. It’s the same story with VB 6 and VB.Net, and it’s the same story with Windows XP and Vista. When Microsoft lost the backwards-compatibility religion that had served them so well in the past, they threatened three of their most important businesses (Office, Windows, and Basic), businesses which are highly dependent on upgrade revenues.

Joel writes here about the value of lock-in, but the twist is that he is arguing that the lock-in is less valuable if the Mac isn’t part of the equation.

Despite some lame attempts at arguing that cross-platform no longer matters on the part of Microsoft evangelists, Microsoft has also realized that they do need to do a better job of at least appearing open and cross-platform. That’s why they are in the process of making OOXML, HD Photo, and XPS into “open” standards, and that’s why they’re putting so much effort into making Silverlight work on the Mac. Unfortunately for Microsoft, their cross-platform tools story around these formats is pretty weak (and I’m being kind when I say weak), and thus it will be a lot harder for them to achieve the cross-platform ubiquity they so desire. I’m curious to see if Microsoft announces a better Mac tools story at MIX next week.

The wild-card in all of this is Linux, of course. Adobe has support for Reader 7 and Flash Player 9 on Linux today, and Apollo will eventually support Linux as well¹. Microsoft, meanwhile, either tries to ignore Linux or FUD it to death, and there is no support for XPS, Silverlight, etc. on Linux forthcoming. Perhaps they plan to rely on their new BFF Novell for such support. Or perhaps they’ll never be able to completely shake the “better on Windows” bias that is so ingrained in their corporate culture. Again, I’m curious to see if they have a better story to tell at MIX next week.

Bottom line, though, is that cross-platform is now more important to the industry than it has been in a long long time. And that’s good news for Adobe, a company that has cross-platform in its DNA.

¹ Disclaimer/FAQ: Yes, I’m aware that Adobe doesn’t support Linux in its various commercial authoring applications today, but no, I don’t know if or when this might change. Yes, I know there is still some anger at Adobe over its history of Linux support. Yes, I agree that as Linux grows in desktop popularity that supporting authoring on Linux will likely become equally as important as it is to support authoring on the Mac today. No, yelling at me about it won’t help. Yes, it would help if a lot of existing Adobe customers told Adobe that they would pay for those commercial authoring apps if they ran on Linux.

The whole thing is sad. Microsoft’s attempts to standardize OOXML have been handled in just about the most non-open, non-inclusive, dirty way possible. I personally think that this is caused in large part by the technical origins of the file format: developed for Office 2003 as a serialization format that was only enabled in the top end Office SKUs, then iterated for Office 2007 to make the formats more complete. If you look at it from the point of view of the engineers on Office, it made perfect sense to pursue this technical path. But making something suitable as the basis for an open, published international standard was not one of their goals, and it shows.

Given a design that wasn’t technically well-suited for standardization, Microsoft’s business folks have resorted to ramrodding the specification through the standards process in an attempt to route around all the inevitable objections. And now that they find they haven’t managed to avoid all those problems as they’d hoped, they are resorting to dirty tricks and PR mind-games. And that brings us to the current press effort, with Jean Paoli doing his very own imitation of Nick Naylor.

Contrast that with the process by which Adobe is submitting PDF to ISO. We’ve bent over backwards to ensure that the submission is as clean as it can possibly be, and as a result the feedback we’ve gotten has been extremely positive. If Microsoft believes their own stuff is so great, they should follow our lead and make it into a standard the right way: by proving the value of their solution, responding to constructive criticism, and building a consensus.

[Update 24apr07 3:00pm] Fixed the first link to point to Rob Weir’s post instead of his comment feed. Sorry about that!

Eighteen years ago, Apple and Microsoft announced a joint effort to create a proprietary replacement for PostScript known as TrueImage and a proprietary replacement for PostScript Type 1 fonts known as TrueType. Only TrueType survived to this day, incorporated into the OpenType font standard format along with the PostScript font format (in CFF guise). When Bill Gates announced the joint effort at Seybold, John Warnock gave an impassioned speech where he announced the opening of the PostScript Type 1 font format specification and said:

This standard is so important in the printing and publishing industry that I’m not going to let it fail.

That statement applies equally well to PDF today, and the stakes are even higher. In fact, virtually every government and company around the world has a stake in the future of the PDF standard. I believe that the history will view this announcement as an historic one for Adobe and even for the software industry as a whole. There are several reasons why I believe this is so:

• It shows how important the creation of vendor-neutral open standards is to the future of the tech industry. PDF has been an open standard for many, many years: anyone can implement the specification without any restriction. The specification itself was defined by Adobe, although we took input from many customers and partners over the years. Furthermore, there are a number of ISO standards that are based on the PDF specification: PDF/X, PDF/A, and so on. The openness of PDF has been sufficient to make PDF the de facto standard for document exchange, and, not incidentally, has helped make the Acrobat product family a significant source of revenue for Adobe.

  But recently an increasing number of customers have told us that they want document formats that are formally defined, freely available, and controlled by a vendor-neutral standards body. Sun and IBM deserve a lot of credit for being the first large companies to recognize this emerging trend and in response submitting ODF to OASIS (and then ISO). PDF following in ODF’s footsteps is important because the PDF format is one of the building blocks of the web.

  I hope this announcement marks a tipping point in the definition of openness for document formats, such that any future document formats that wish to get widespread industry adoption will need to be equally open.

• It helps expose, by contrast, the weaknesses of Microsoft’s own standards efforts. Like Adobe, Sun, and IBM, Microsoft has also recognized the trend towards formal standards and as a result is shepherding OOXML thru ISO via ECMA. Unfortunately, Microsoft is trying to have its cake and eat it too, using a committee charter that is rigged: the committee is required to rubber-stamp the format as defined by Microsoft’s implementation for the sake of “compatibility”. Because the standard is really defined only by Microsoft, the OOXML standard fails the vendor-neutrality test in a fundamental way. It remains to be seen whether or not Microsoft will attempt to pull the same trick with XPS.

• It makes Microsoft’s XPS format even more irrelevant and unnecessary. Why would anyone bother with a competing format this isn’t vendor-neutral, does less, and isn’t nearly as ubiquitous?

For myself, I’m proud that I got to play a small (and I do mean small) role in the process that led up to the announcement. My hat is off to the Adobe management team that made the decision and to the product teams that will have to execute on that decision.

Lastly, on an administrative note, I want to point out that Adobe isn’t announcing anything with respect to the submission of any other document formats to standards organizations, so I can’t speak towards such topics.