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
pgp9ixmZUauRP.pgp
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
