Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Floating point type value format are not retained in ods documents #7

Open
sraps opened this issue Jan 27, 2016 · 6 comments
Open

Floating point type value format are not retained in ods documents #7

sraps opened this issue Jan 27, 2016 · 6 comments

Comments

@sraps
Copy link
Contributor

sraps commented Jan 27, 2016

Quick "dirty" fix:

At the line (1100) in opendocument.py add following line :

tag.attrib['{%s}value-type' % namespaces['calcext']] = guess_type

Please report test results.

@lukebranch
Copy link

@sraps ,

Which issue is this a fix for? I'll be doing some testing for 9.0 next week, so I can let you know the results in my environment if I know what i'm testing for.

@sraps
Copy link
Contributor Author

sraps commented Jan 27, 2016

To reference back to original issue for the record:
aeroo/aeroo_reports#78

@alexis-via
Copy link
Contributor

@sraps I tested your "dirty fix" and it works well with my ODS template, thank you very much !

alexis-via pushed a commit to akretion/aeroolib that referenced this issue Feb 2, 2016
@sbidoul
Copy link

sbidoul commented Feb 4, 2016

👍 the fix works fine with libre office 5.0.2.2

@a0c
Copy link

a0c commented Jan 17, 2017

The fix turns all Float-looking Texts into Floats.
So all your 0405036 will turn into 405036 where leading zeroes are lost.

If this is an issue, consider this (will probably interfere with the original fix):

diff --git a/aeroolib/plugins/opendocument.py b/aeroolib/plugins/opendocument.py
index b3eadb1..cad04a7 100644
--- a/aeroolib/plugins/opendocument.py
+++ b/aeroolib/plugins/opendocument.py
@@ -1093,8 +1093,15 @@ class OOSerializer:
             else:
                 try:
                     float(tag[0].text)
+                    try:
+                        if str(int(tag[0].text)) != tag[0].text:
+                            raise TypeError
+                    except ValueError:
+                        pass
                     guess_type = 'float'
                     tag.attrib['{%s}value' % namespaces['office']] = tag[0].text
+                    # AKRETION HACK https://github.com/aeroo/aeroolib/issues/7
+                    tag.attrib['{%s}value-type' % namespaces['calcext']] = guess_type
                 except (ValueError,TypeError):
                     guess_type = 'string'
             tag.attrib['{%s}value-type' % namespaces['office']] = guess_type

Still, does the main subj mean that a tool created for processing numbers (openoffice) does not even make a difference between numbers and strings on the core level?

@sraps
Copy link
Contributor Author

sraps commented Jan 20, 2017

Hi,
actually I've found out that all previously proposed solutions to the problem, of not retaining cell value formats, fires another problem of being incompatible with ods templates created with older versions of LibreOffice/OpenOffice. Problem lies in fact that there is no "calcext" attribute, hence nowhere to assign. So there is need for another more complex solution. I have one and now testing implications.

@a0c the idea behind all reporting engines are in principle of predictably generating for subsequent rendering of documents. I would not go as far as completely replicate LO/OO formating of the cells, dynamic formatting/calculation, or even more macro functionality. It is quite complex, heavily dependent on locale of particular installation. In other words there are number of things that can not be fixed, like decimal points, etc. As Aeroo does it's job without help of LO/OO, it would have to recreate all the functionality on it's own. Or maybe run the template through LO/OO process, like Aeroo DOCS, even if the return format is the same as original format (read- no conversion takes place), in order to recalculate all the formulas, tidy up formatting, etc. So ideally, Aeroo should generate document with all the cells being text, that is then being converted to PDF or sent to printer.

Nevertheless, spreadsheets are being used as a convenient way to output data from the system, in this case it is desirable to retain value as it has been generated, with all the leading and trailing zeroes and decimal places shown and data types preserved.

In other words LO/OO dynamic recalculation could not be a goal with Aeroo Reports. I assume that there is a space for a feature to run document through the OO/LO process. Still it is justifyable in order to recalculate such things as number or pages (and their correct display on the pages themselves), etc.

stephanamann added a commit to Glue-Software-Engineering-AG/aeroolib that referenced this issue Apr 13, 2017
sraps added a commit that referenced this issue Mar 17, 2018
sraps added a commit that referenced this issue Mar 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants