« Happy Passover! The Never Ending JPEG Patent Saga »
Microsoft’s Metro vs. Adobe’s PDF
Posted April 27, 2005 – 6:04 pm by Yakov Shafranovich in Standards(This post was part of a separate “Standards Blog” which has been merged into my main blog.)
Quite a few news outlets are carrying the story of Microsoft inventing a new technology called “Metro” intended to replace Adobe’s PDF format. According to Microsoft Watch ” Metro is a “new fixed document format built on top of XML”, is also referred to as a “Page Description Language (PDL)” and is even characterized “a new native (print) spool filter for Longhorn.” There is also talk about support in hardware as the article quotes a Microsoft representative stating that “printers with Metro “interpreters” and/or those which are Metro-enabled will be able to best print Metro-based documents and photos”.
According to Wikipedia, Page Description Languages include Adobe’s PDF and Postscript, HP’s PCL and an existing XML-based standard called XSL-FO made by the W3C. Given the wide variety of existing languages, at least two of which (Postscript and PCL) support printers, why is there a need for a new one? There is also glaringly very little effort to standardize this in a proper fashion or to even consult the W3C on this. Given that XSL-FO already exists, albeit not entirely suitable for this task, why not make a new open standard?
Additionally there are questions about the licensing policy for this “new standards”. According to all the news articles, Microsoft has promised to make “Metro” available royalty-free”. However, as the MARID debacle has shown royalty-free many times doesn’t mean that everyone can use it. And in this case there is plenty of what to worry about – let’s compare the existing Adobe PDF license to what Microsoft is planning for “Metro”. The Adobe PDF license states as follows:
Authors of software that accepts input in the form of the Portable Document Format must make reasonable efforts to ensure that the software they create respects the access permissions and permissions controls listed in Table 3.20 of the PDF Reference, to the extent that they are used in any particular document. These access permissions express the rights that the document’s author has granted to users of the document. It is the responsibility of Portable Document Format consuming software to respect the author’s intent.
Anyone who uses the copyrighted list of data structures and operators, as stated above, must include an appropriate copyright notice.
Basically speaking there are only two requirements: respect Adobe’s DRM and stick in a copyright notice. However, if we look at the the Microsoft FAQ on “Metro”, we find the following statement:
The Metro licensing program has not yet been finalized. The general Metro license is likely to be similar to that of the Office XML licenses which comprise a copyright license and a patent license.
The problem with the current Office XML schemas is mentioned here:
You are not licensed to sublicense or transfer your rights.
Of course not having the ability to sublicense, effectively kills any use of this license in conjunction with the GPL which requires it, a situation very similar to what happened to MARID. What is even more interesting is that while Microsoft is promising to bend on the Office XML schema license, they did not do so with MARID and there is now way to tell if they will with “Metro”.
Now we come to the interesting question as to why this was done. The first reason obviously is that just like with XAML and other parts of Longhorn, Microsoft is moving in the direction of using XML for many subsystems in Windows. Since the print path in Windows is probably pretty old in design, it was due for an overhaul anyway. However, if we take to heart what Joel Spolsky has written, it makes a lot of sense:
…suddenly, Microsoft’s API doesn’t matter so much. Web applications don’t require Windows.
It’s not that Microsoft didn’t notice this was happening. Of course they did, and when the implications became clear, they slammed on the brakes. Promising new technologies like HTAs and DHTML were stopped in their tracks. The Internet Explorer team seems to have disappeared; they have been completely missing in action for several years. There’s no way Microsoft is going to allow DHTML to get any better than it already is: it’s just too dangerous to their core business, the rich client. The big meme at Microsoft these days is: “Microsoft is betting the company on the rich client.” You’ll see that somewhere in every slide presentation about Longhorn. Joe Beda, from the Avalon team, says that “Avalon, and Longhorn in general, is Microsoft’s stake in the ground, saying that we believe power on your desktop, locally sitting there doing cool stuff, is here to stay. We’re investing on the desktop, we think it’s a good place to be, and we hope we’re going to start a wave of excitement…”
The trouble is: it’s too late.
Inventing new web-based or web-related standards and keeping them under some form of control, while not letting their biggest competitor (namely open source) to use them is the perfect tactic to combat this. I personally think that “Metro” is just one latest example of this, since a standard by definition is used by many people. One can just imagine how an XML web based standard for printing and sharing documents coupled with the very large desktop market share of Microsoft can kill both PDF and IPP at once. Instead of open and semi-open standards, we might end up locked into the Longhorn infrastructure, albeit Web-based.
Of course one shouldn’t ignore the large installed base of PDF at this point. However, at one point Netscape ruled the web and things nevertheless went downhill very quickly for them. If I were Adobe at this point, I would run with PDF and Postscript, and make them both official standards AND start supporting the open source communities. After all, this was the gambit that AOL took with Mozilla and the result is FireFox which is slowly nipping at the heels of Internet Explorer. I can easily see Adobe’s fully open, standardized PDF/XML hybrid winning with the help of governments and the open source communities. But then again, Sun has missed this chance with Java once, and “those who ignore mistakes of history tend to repeat them”.
Permalink | Trackback URL | This post has










One Response to “Microsoft’s Metro vs. Adobe’s PDF”
Adobe Systems, Inc., was named as a defendant in a lawsuit that has been pending in the United States District Court for the Northern District of California for four years. The lawsuit alleges that Adobe, in creating its InDesign product, infringed the plaintiff’s copyright and misappropriated its trade secrets. Even though InDesign is one of Adobe’s premier software products, Adobe has never disclosed this pending litigation in its public reports or filings. (please see Brookhaven Typesetting Services, Inc. v. Adobe Systems, Inc., Case No. C01-20813
(RMW)).
Adobe must be nervous….
You should take a look at Adobe’s most recent filing in Brookhaven Typesetting Services, Inc. v. Adobe Systems Inc., 5-01-cv-20813 (ND Cal.) in which Adobe writes: “[A]pparently Brookhaven has been making implicitly defamatory statements to Adobe’s stock analysts, members of the media and Adobe’s contractual and prospective business partners. . . . Adobe will be requesting an opportunity to commence discovery against Brookhaven, its officers and attorneys will [sic] respect to this improper conduct and to seek leave of the court to file whatever action is appropriate.”
By mary landers on Aug 24, 2005