Thanks for your personal response, Stéphane! I have no experience with VBA, but if the value 12345.12345 is stored as a "double" and converted to a decimal string representation with 17 significant digits, what you will get is 12345.123449999999. The value 123.12345 is returned as 123.12345000000001. The value 123456.123456 is, as it happens, mapped to itself. These relative errors of around 1e-16 are simply unavoidable when using IEEE double representation. The double type has a limited precision and does not use base 10, hence even seemingly simple decimal values like 0.1 will not be represented exactly. (Other values like 0.5, 0.25 and 0.125 will, though.)
Unless VBA has access to the verbatim type-in value and keeps the value in string representation, these rounding errors are what you will get from VBA also. The fact that OOo Calc actually seems to keep the value which was typed in could be either due to Calc actually keeping the typed-in value verbatim, or that there is some extra, reasonable but nonstandard rounding taking place when saving. I would need to make closer investigations or take a look at the source to know for sure.
Perhaps VBA does such "smart rounding" when reading the values from MS Office? That would be a reasonable explanation for the discrepancy between VBA and the stored value in OOXML.
DrawingML+VML store content with their own locale.
Aha. I actually missed that in my first reading, sorry. Ouch. That's bad formatting
indeed. But there are plenty of other places where the OOXML spec doesn't hold
together as a single standard, so I can't say that I'm surprised.
The whole ECMA 376 spec looks certainly a bit rushed, just like everything
Microsoft does related to international issues.
I can fully agree on that. It's a rush job straight through. Most of it looks as if
it has received only a cursory review by ECMA. It is clearly immature, both in
terms of the technical content and the presentation of the document.
