https://bz.apache.org/ooo/show_bug.cgi?id=126827
orcmid <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from orcmid <[email protected]> --- This is a consequence of the ODF specification of the number:position attribute in ODF 1.2 Part 1 section 19.354. The value must be an integer, starting with 1, and it only applies counting left from the rightmost position of the integer part of a number's presentation. So there is no way to put the "D" (at position 0) and anything to the right of the decimal (technically, negative positions given the number:position" definition). The number:position definition probably codifies what the implementers of OpenOffice.org thought the behavior might have already been. That was probably determined too long ago (i.e., 2005 or earlier). I confirm that AOO 4.1.2 Calc allows the User-defined format code 0"A"0"B"0"C"0"D"."E"0"F"0"G"00"L" for cells. To be entered and that it will be usable in making cell entries. For example, Entered Displayed/Saved Reloaded 0 0A0B0C0D.E0F0G00L 0A0B0C0.0000DEFGL -3.14159 -0A0B0C3D.E1F4G16L -0A0B0C3.1416DEFGL 99999 99A9B9C9D.E0F0G00L 99A9B9C9.0000DEFGL And, when the file is saved as an .ods, the sheet remains displaying the above Displayed/Saved forms. However, the saved .ods has changed styles that satisfy the ODF rules and the reloading is as described by Falcon and shown as the Reloaded forms. Finally, if the document is saved as an Excel 97/.../XP .xls file, the expected formatting is seen when opening that file in Microsoft Office Excel 2016 *and* back in AOO 4.1.2 Calc. OBSERVATION #1: This provision in OpenOffice Calc (and there are a few others) is only implemented correctly in saving and opening in .xls format. When the feature is used and the document is saved as an ODF Spreadsheet .ods file, there is silent transformation without any indication to the user and the saved file has a corruption of what the user saw as successful. OBSERVATION #2: There is a policy issue here with regard to interoperability via the OpenDocument format. We are in the peculiar position that, if this behavior were to be sustained, we need to warn users that saving as .ods may not preserve all features used in the user's document. OBSERVATION #3: On opening the .xls version in Excel 2016 and doing a new Save As ... into .ods format from Excel 2016, there is the usual compatibility warning and, after the save, the document is still shown in Excel with the feature working. On opening of that Excel-created .ods in AOO 4.1.2 Calc, the result is the same as the Calc Reloaded case, above. In that case, the Excel warning about possible loss of features is accurate, even though it is a rubber-stamp message. CONCLUSION: Giving preference to .xls fidelity and silently failing on saves to ODF formats is a nasty problem. The preference may satisfy a majority of users who only look for Office-format interoperability. Nevertheless the silent failing in production of the preferred/default OpenDocument format files is awful. DIFFICULTY: This takes a clarification of policy (perhaps the easiest step) and some remedy in the software. It may involve half measures and there is no outlook on how long it can be before there is any remedy. -- You are receiving this mail because: You are the assignee for the issue.
