To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=47521
------- Additional comments from [EMAIL PROTECTED] Wed May 11 04:57:24 -0700
2005 -------
Eike - this is not looking encouraging at all:
Boiling down your comments to something more bald it seems like you say:
* once 2.0 is released - we can do no changed whatsoever to any
functionas ever again. pwrt. no. of arguments, core functionality etc.
we can also never add new functions - since they won't be backwards
compatible; and we can't detect versions in the file format
* we can't get this change into 2.0 => it can never be committed, cf. above.
Is that accurate ?
Ultimately - to become more Excel compatible we're going to need lots of changes
of this form. It's a shame that they are not acceptable up-stream. In which case
- can I ask again: would this be acceptable up-stream with an EXCEL_COMPATIBLE
conditional ?
> 1. It adds yet another parameter to several methods that are called
> a million times, just to get this tiny change in.
Yes - that sucks, but we'll need to do a number of other changes to improve
interop - all of which would use that information.
> 2. We could apply this change only to OOo2.0, not in any later release,
> because then there would be no distinction between formats anymore,
This sounds like some endless backwards compatibility argument - that
intrinsically means feature addition is impossible: surely that's not the case
generally ?
> 3. This patch would introduce a core-based distinction between the new
> OpenDocument file format and the older .sxc format. We don't do that
> on purpose to keep this away from the core, all saves to the older
> format are handled by a transformation.
You would really prefer to output the formula as a string, and then have
xmloff/ accurately re-parse that, alter a few tokens, and re-stringify it ? wow
- of course, we can cut/paste the parser into xmloff/ but it seems a curious
design.
> Just a quick idea: I could imagine another approach that uses the auto
> correction of the formula compiler to either suggest the use of LOG10
Sure - if you type it in by hand; of course - the LOG vs. LOG10 thing is a
rather trivial example of this meta-problem, there are tens of other more
complex functions which are broken. Naturally, most / many functions are going
to be imported from Excel - and I can see no way forward but to add
functionality in those cases; there is no LOG10 escape route.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
