Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Saturday, 2009-07-04 14:53:45 +0200, Regina Henschel wrote:
I generate a file with a formula =FDISTL(a,b,c) and store it in
version ODF1.2. Unzipping the file I find "of:=FDIST(a,b,c)", which
is correct.
Now I open the file in OOo2.4.2. I get the version warning to
upgrade. (BTW, you get the warning only for first opening.) Then it
opens and the cell with "of:=FDIST(a,b,c)" is calculated with cell
content =FDIST(a,b,c) instead of showing a #NAME? error. This must
not happen, because =FDIST in OOo2.4.2 means the right tail, which
is internally "of:=LEGACY.FDIST". The user does not know, that the
result is wrong.
Ouch..
[..]
If you now save the file in OOo2.4.2 and reopen it in OOo3.2, then
the original =fdistl() cell contents are not restored. We have data
loss.
"Content not restored"? What exactly is imported/displayed, and what is
missing? I assume it is imported as FDIST instead of FDISTL (UI names),
correct?
I know, that it cannot be restored, as the OOo2.4.2 has turned
of:=FDIST([.B3];[.B1];[.B2]) to oooc:=FDIST([.B3];[.B1];[.B2]) when
saving. I mentioned it as contrast to the problem exchanging documents
between OOo3.2 and OOo3.1.
Is there any place in source of OOo3.2 where I can avoid that error?
Or can it only be solved in OOo2.4.x?
The erroneous handling of of:FDIST as oooc:FDIST in 2.4.2 could only be
fixed with a change in 2.x; however, a correct fix could only be to
either make 2.x not load 'of' namespace as formulas at all, or
completely implement handling of both namespaces, which would be quite
tough, partly the same I did for OOo3.0
I've feared that.
An intermediate workaround to not make the function calculate wrong
results in 2.4.2 because of of:FDIST vs. oooc:FDIST could be to always
forcedly write the 4th parameter, such that 2.4.2 will return an error,
which is at least better than a wrong result. More nasty than nice, but ...
For the "contents not restored" I'd need more details. If it is the
function being imported as oooc:FDIST instead of of:FDIST, we might
trick the compiler into translating that to of:FDIST if the function has
4 parameters, given that we wrote always 4 parameters as mentioned
above. Again, more nasty than nice, but ...
And not a really solution. The draft spec allows three parameters and a
OOo2.4.2 version can get a -in this way valid- document from third party.
(2)
Another problem is the following scenario. Save in OOo3.2 with
version ODF1.0. Open in OOo3.1.1. In cells with content "=FDISTL()"
you get correctly content "=fdistl()" and #NAME? error, because this
function is unknown to OOo3.1.1. Now save the file in OOo3.1.1 with
version ODF1.2. and open it in OOo3.2. The cell content is shown as
"=fdistl()", but the now known function
It is not really known, because of:FDISTL doesn't exist.
is not identified and the
cells show a #NAME? error. Unzipping the file you see a
"of:=fdistl()", which small instead of capital letters. Even a hard
recalculate does not help.
Any solution for this?
We could introduce an alias handling in the compiler and tie that to the
<meta:generator> element's value and accept the alias only for documents
created by versions OOo3.0 and OOo3.1
The content.xml has the node
<table:table-cell table:style-name="science"
table:formula="of:=fdistl([.B3];[.B1];[.B2];1)"
office:value-type="float" office:value="0">
<text:p>#NAME?</text:p>
</table:table-cell>
So the table formula exists, besides being in lower case. Perhaps a
conversion is not needed in the way, that it is done automatically. As
long as the table:formula attribute is preserved with saving, I can also
image to implement a "repair"-command, that takes the table:formula
attribute and generates a valid formula from that and recalculate the
cell then.
I think, that a solution is necessary, because there will be similar
situations in future, that there are two versions, both working with
ODF1.2, where a newer version knows a function that the older does not know.
However, given all these quirks I'm hesitating to implement FDISTL at
the current stage, especially with regard to the OOo2.4.2 problems.
I agree, not to implement FDISTL with OOo3.2. I can send you the code
which contains the algorithms, so that you can keep it and the
algorithms get not lost. Do you want a patch or the complete
interpr3.cxx file?
I think, that the FDIST problem has to be solved in OASIS. For CHIDIST
it has been solved by introducing the new function name CHISQDIST. The
left tailed variant of the F-distribution needs a new name too. At least
it should not allow three parameters, so that application can notice the
change by counting the parameters. Do you take the problem to the committee?
kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
