-
-
Notifications
You must be signed in to change notification settings - Fork 636
ODS Reader yields different results #184
Comments
Hi @madflow, thanks for filing this issue. This is definitely not the correct behavior. All readers should behave consistently. |
I am interested to help - of course time and knowledge about the spreadsheet internals are an issue. I will have a look at the tests first. I reckon there should be a set of shared tests that all readers should equally pass. |
Yes! Tests are in the "tests" directory (obviously). ODS files are composed by a bunch of XML files, zipped together. One way to get familiar with the ODS format is to create an ODS file with fake data, unzip the *.ods file and look at the extracted files. They all contain some pieces of information you have to merge together to get the actual data. The test files used in the tests are located in "tests/resources". What I recommend you to do is create a test file with zeroes and empty strings, add a test with the expected behavior (it should fail) and then update the ODS Reader code to fix the issue. Once the issue is fixed, the test should now pass. |
Hey @madflow, your changes look good. Feel free to submit a pull request. I'll be happy to merge it |
The current commits only fix bug number 1 (Zeros treated as missing values). The second Bug has not been fixed yet in my branch (tests are failing like they are supposed to) ;) I can create a "Work in Progress" PR if you like. |
No need for a WIP PR. Just submit the PR when you are done :) |
Fixed as part of #189 |
Hi there!
When playing with the
Reader
part of the library I came across the artifact, that the ODS reader treats input differently than its peers XLSX and CSV.Example:
Example:
Maybe this is wanted behavior: Then I would argue to change it and introduce a legacy flag for the old behavior to avoid a regression.
If this is a known thing and ODS needs some love - then this could be a PR.
Thanks!
The text was updated successfully, but these errors were encountered: