Dennis E. Hamilton wrote:
For out-in (which this is, presumably), you want to record a decimal expression of the internal value that will convert back to the exact internal value on re-input. (The in-out case is that the input conversion provide whatever internal representation that will convert to the read value on re-output. Without additional information, it is generally very difficult to have these be the same.) It is also desirable, of course, that any other ODF consumer use the same technique so that its in-out conversion satisfies the out-in condition of the original source of the decimal expression of the value.
Hi Dennis, yes - but in a first approximation, one can probably relax this a bit (for the use case at hand): only _after_ the first save operation this needs to hold. Also, most people would probably be contempt with this to work for *one* ODF editing application.
It is also desirable, of course, that any other ODF consumer use the same technique so that its in-out conversion satisfies the out-in condition of the original source of the decimal expression of the value.
Note that there's a difference between spreadsheet values (for which I think de facto the above holds true - likely everyone stores those in IEEE doubles), and other content: consumers might employ rather complex transformations to arrive at internal values, given e.g. a gradient center coordinate - asking for common behaviour is very close to asking for a common ODF application model. Cheers, -- Thorsten
Attachment:
pgpa4GqFMNhMK.pgp
Description: PGP signature