|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Storage of Add-In functions, such as ERFC, is broken between releases and localizations of OOo2. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Calc | Reporter: | Regina Henschel <rb.henschel> | ||||||
| Component: | open-import | Assignee: | AOO issues mailing list <issues> | ||||||
| Status: | CONFIRMED --- | QA Contact: | |||||||
| Severity: | Trivial | ||||||||
| Priority: | P2 | CC: | 84353228, issues, marcelly.bernard | ||||||
| Version: | DEV300m20 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
| Developer Difficulty: | --- | ||||||||
| Attachments: |
|
||||||||
|
Description
Regina Henschel
2008-08-06 17:52:54 UTC
Created attachment 55608 [details]
first open in German, than English, than German
ERFC() is an Add-In function, there may be something wrong with how names are determined for storage, this area heavily changed for ODFF compliance. Needs investigation. @regina: Are other Add-In functions affected as well? The files were saved using the old table:formula 'oooc' namespace, not the new 'of' namespace, since DEV300_m20 was some intermediate developer version. Does the error still persist using OOO300 RC1 or later? Thanks Eike OK: German OOo3.0RC1 -> English OOo3.0RC1 -> German OOo3.0RC1 OK: German OOo3.0RC1 -> English 2.4.1 -> German OOo3.0RC1 Faulty: German OOo2.4.1 -> English OOo3.0RC1 -> German OOo2.4.1 I have not tested all of the Add-In functions, but other functions are effected too. I see the error in BININDEZ GGANZZAHL IMAGINÄRTEIL ZWEIFAKULTÄT UMWANDELN_ADD (This converts back to UMRECHNEN) *** Issue 92528 has been marked as a duplicate of this issue. *** Apparently this is due to the fact that the stored function names changed between namespace 'oooc' used in ODF 1.0/1.1 and 'of' used in ODF 1.2. An OOo2.x reading 'of' namespace content will not be able to correctly identify all functions. Documents that shall be read with OOo2.x need to be saved as ODF 1.1. @regina: your scenario sounds as if you did not touch Tools -> Options -> Load/Save -> General "ODF format version", or did you? The document attached to this issue is the result of a save with "English OOo3.0RC1" of your latest scenario given? I have _not_ changed the default setting of "save in ODF 1.2". I know that I could do it, but it would not give a realistic situation. Most time you do not know, which version has been used to create a document and in which version it will be opened next time. The document, which I have attached do not belong to my tests from "Sep. 16", but was generated earlier, "Aug. 6." When you mentioned "namespace change", I have tested it with OOo2.4.1 in addition but have not attached a document. I used OOo2.4.1 because I thought it would be more realistic for real life scenario than a developer snapshot. *** Issue 94966 has been marked as a duplicate of this issue. *** Given the scenario that fails, German OOo2.4.1 -> English OOo3.0RC1 -> German OOo2.4.1 I don't think there is anything we can do about this, other than teaching OOo2 the new 'of' namespace and function names. OOo2 knows the Analysis Add-In functions by their programmatic name, in this case com.sun.star.sheet.addin.Analysis.getErfc, whereas OOo3 stores the name as defined by ODFF, here ERFC. However, failing to find a match an English UI Calc also attempts to match the English function name and so can read it correctly, but a German UI Calc does not, it attempts to match the German name instead. It is not a German only problem, but is problem for other languages too, and it occurs also if you open a original OOo3 spreadsheet with OOo2.4.1, see issue 92530. If it cannot be solved in OOo3, shouldn't it then be corrected in OOo2.4.2? A P2 issue with target milestone "not determined"? For OOo2.4.2 it is too late. Changing a OOo2.4.x release to recognize the new standard's namespace would be quite an effort, and I don't even know if we will do another 2.4.x release hence the "not determined" target. Implementing that would bind my work resource where I could spend it better on other things. Also, I think that people should upgrade to a 3.x release instead of yet another 2.4.x release to come. *** Issue 95275 has been marked as a duplicate of this issue. *** There is a more important bug specific to OOo 3.0.0 : if you have the option ODF format to : 1.2 (recommended) then it is not possible to store a valid Calc file in sxc format. Next attachment is a zip containing 3 files. All were written with en-US interface. Fonc-US-ODF12.ods has a simple call to Add-in function HEX2DEC. It is stored with recommended option ODF 1.2. Fonc-US-ODF12b.sxc is a Save As of the same document. Option was still ODF 1.2. The formula does not work when read from OOo versions 3.0.0, 2.4.1, 1.1.5. Fonc-US-ODF11b.sxc is a Save As of the first document, but with option set at ODF 1.0/1.1. Formula works correctly in all OOo versions. Created attachment 57379 [details]
3 Calc files written with OOo 3.0.0 (300m9)
@bmarcelly: Though related, the .sxc export is a different problem, I created issue 95312 for that. And no, I wouldn't call export to deprecated .sxc old XML file format more important at all. The same is for the function KALENDERWOCHE (German) / isoweeknum (English) in Version 3.1.1 / OOO310m19, Build 9420 I still have the problem with storing a (German) spreadsheet in OO XML 1.0 format. kalenderwoche becomes isoweeknum, what older OOo-versions don't understand. It seems, this bug exists for 6 years now - will it ever be fixed? Even worse, save spreadsheet as sxc and re-open -> errors because ISOWEEKNUM isn't recognized in sxc-format. Very strange... Reset the assignee to the default "issues@openoffice.apache.org". |