Regina Henschel wrote:
Hi Daniel, hi all,
<snip>
(3) Some functions, for example CEILING.PRECISE(number;significance),
are partly compatible. We would get the same result, if we translate
it to CEILING(number; SIGN(number)*ABS(significance)). Gnumeric had
used such translations in former versions. I don't like doing so
automatically. I would prefer to set up a Wiki page, which explains to
the users, how they can translate the Excel solutions to Calc formulas
and leave it to the user to change the imported formulas manually.
Might it be possible to treat it like a spellcheck error, identifying
the problem but supplying the equivalent formulation for acceptance with
manual action, and perhaps the converted value as another possibility?
(4) What do you think about my proposal to not convert anything, when
opening an Excel-ods document _readonly_, but show the contained
values? As far as I know, there exists no ods-viewer and therefore a
Calc user is currently not able to see, which values the Excel-ods
document has calculated.
If the contained value is available as a "spellcheck" type option, it
could be used here, too. They wouldn't have to accept the value, but
they could see it.
(5) Should there be a warning, when a user opens an Excel-ods
document, which is not fully compatible to Calc-ods?
I think so -- something like "This spreadsheet was prepared by an
application that does not conform to the [projected] Open Formula
standard. Some issues with formulas are likely."
All this is just my half-cent's worth (I certainly won't claim two
cents, I'm a very low-level user of spreadsheets!). But anything we can
reasonably do to improve interoperability, while making it clear where
the problem actually lies, seems like a "good thing" to me.
kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
