| |||||||||||||
Microsoft: Boiling Frogs Since 1975Microsoft: Boiling Frogs Since 1975Posted Apr 16, 2012 21:55 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)In reply to: Microsoft: Boiling Frogs Since 1975 by anselm Parent article: Paoli: Microsoft will engage with the open source and standards communities
>If you need to look at Excel 95 to figure out what the OOXML standard really means – note that Microsoft didn't bother to actually specify in the standard what the flag in question did, just that it was supposed to trigger behaviour »compatible to Excel 95«
Can you point out the list of trigonometric functions usable in spreadsheets and their parameter types in ODF 1.0?
(Log in to post comments)
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 22:22 UTC (Mon) by anselm (subscriber, #2796) [Link] There is a big difference between not standardising something and standardising something in a way that is virtually impossible for everybody except a single party to implement. The trigonometry functions in ODF 1.0 were left out to keep the scope of the first version of the standard manageable. They got added in a later version of the standard. Problem solved. In the meantime there was fairly widespread consensus about what a »sine« and »cosine« is as well as what sort of data type such a function would take or return, and there were various open-source implementations of ODF-based spreadsheet software to refer to. On the other hand, we're pretty much stuck with the weird bits in OOXML that refer to Excel 95 and Word for the Macintosh without actually telling us what they are really supposed to do. There is no source code you can look at to figure them out. And since they're in the standard already they are very difficult to get rid of again.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 22:46 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
That's about the worst way to standardize something because it causes a plethora of incompatible implementations. And we see this right now - there are no two ODF implementations that render complex documents the same way.
Yeah, that annoying 'backwards compatibility' problem again.
We recently tried to migrate a medium-sized organization to a mix of Google Docs (managers need to edit documents during business trips) and OpenOffice. We've failed miserably - there were TONS of incompatibilities, even though both ostensibly support ODF.
In the end, managers decided 'screw Linux and that commie hippies in Google' and went to Microsoft and Office Live with that godawful Sharepoint. And I can't really blame them, at least Microsoft is fairly compatible with itself and you receive something working for your $$$$$.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 23:03 UTC (Mon) by anselm (subscriber, #2796) [Link] there are no two ODF implementations that render complex documents the same way. With Word, there's only one implementation and even that does not manage to render documents consistently, depending on which printer driver (and version) you have installed. This is even before you bring in other software that is ostensibly compatible. I'd say the situation is just as bad.
Microsoft: Boiling Frogs Since 1975 Posted Apr 16, 2012 23:10 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Dependency on printer driver (actually, on paper size settings) is well-known and easy to work around. It mostly bites users when constant switching between Letter/A4 is required. Other times you can simply ignore it.
And no, Microsoft has a top-notch online collaboration suite that is almost perfectly compatible with their desktop products, we've found some inconsistencies but they were truly minor.
And no, the actual OOXML files that MS produces do not use the magic 'behave like Excel 95' entries, they are fairly straightforward and easy to parse/generate. It's pretty clear to everybody that MS tries to be bug-compatible with earlier versions so everyone who don't need to work with old documents can simply ignore these commands.
|
|||||||||||||