ISO Approves OOXML
sTeF writes in, with the hope that this is an April Fools joke. Doesn't look like it though. An article up at Intellectual Property Watch claims they have obtained a document (PDF) enumerating the vote after Microsoft's OOXML won ISO standard status.
Microsofts statement hailed the appearance of extremely broad support for the standard at the end of the ISO voting process.
Broad? I think they mispelled bold faced fraud.
and what to avoid. and no, im not a bigoted fanboi of any camp - im just reflecting upon the series of stunts ms pulled to get that format validated. judging from the level they lowered themselves in dirty work to get this through with bribing and manipulating, i'd say that their format has to be total crap. else it wouldnt need that level of filthy campaigning.
Read radical news here
And with that - the "standards body" of ISO was effectively taken down. FUD shovelers everywhere will begin the slow, purposeful targeting of Government, school and corporations to use MS's products for long-term archival concepts.
/. comments down here?
Perhaps with only gnashing of teeth from the geek side, initially. After some time, say 3 or 4 product cycles, MS's formats, content and programs will have slipped into breaking changes - with various patches, pieces, conversion tools and sunsets. Then and only then, will the true colors of MS's saletroopers, who overrule the tech side, be shown. But you know this - why else would you be trawling the
In other news, the business of writing code to munge data from old MS formats into new MS formats is alive and well. Programmers rejoice! There is an endless market of chagrined middle managers who are willing to port old crap to new crap for good $/hour.
So apparently it's not valid to complain that the new standard shouldn't need to support "truncateFontHeightsLikeWP6" in the first place? Wouldn't it be technologically superior to require MS Word to emulate "truncateFontHeightsLikeWP6" using standard formatting directives, rather than forcing every other implementer to code for compatibility with some file format that isn't even part of the spec?
Try this one one for size:
"15 years ago we had a file format that stored text using EBCDIC encoding. While we no longer write any files using this encoding, we propose that the new standard file format include an EBCDIC mode. We realize that traditional arguments for "backward compatibility" don't apply -- obviously none of our 15-year-old products ever produced any output in the new file format being proposed -- and we concede that we could just convert to UTF-8 encoding when saving old documents into the new format. But such conversions would require more work on our part than simply adding another encoding mode to the new file format and reusing our existing code to render in that mode. We acknowledge that this formatting directive will only benefit our product, as no one else can read our 15-year-old, unpublished format, so we'll note that the EBCDIC mode is deprecated. In spite of that note however, we will generate new files using EBCDIC mode, and therefore competing implementations must implement it as well to be functionally compliant."