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

fix: Correct data type 'number' constant to 'n' #89

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

janmagnusdev
Copy link

The official xlsx spec defines that the t property of a cell should have t='n' if the cell type is number.

This fix also makes the exported Excel sheet work with LibreOffice correctly, since that expects 'n' as the type of number cell.

Before, sheets exported with @microsoft/connected-workbooks and opened in LibreOffice Calc would not display numbers in number cells at all, those cells would be blank.

For Excel sheets, this does not change anything, since Excel understands t='n' as the type as well.

Actually, t='1' is a derivative from the spec, and it seems to be just per chance that Excel understands it.

Therefore, I changed dataTypeKind.number from t='1' to t='n'.

In the following, I used the code from https://github.com/microsoft/connected-workbooks?tab=readme-ov-file#2-export-a-table-from-raw-data to export data to a sheet and compare their view in LibreOffice vs Excel. I used Excel online, since I am working on a Linux machine.

The first image shows the result of an export using the original code, dataTypeKind.number = "1", in both applications. Excel Online is on the left, LibreOffice Calc is on the right.

corrupt-export

The second image is the same, but showing the result of an export using modified code of this library from this PR, dataTypeKind.number = "n".

working-export

As you can see, in the second image, both applications, LibreOffice and Excel, are showing the numbers correctly.

For further reference, compare the xlsx specification, Part 1 “Fundamentals And Markup Language Reference”, 5th edition, December 2016, p. 2451: https://ecma-international.org/publications-and-standards/standards/ecma-376/

Please do leave feedback on this PR, since I haven't opened a PR in a public library before.

The official xlsx spec defines that the t property of a cell should have
 t='n' if the cell type is number.
 This also makes the exported Excel sheet work with LibreOffice
 correctly, since that expects 'n' as the type of number cell.
 Before, sheets exported with connected-workbooks and opened in
 LibreOffice calc would not display numbers in number cells at all.
 For Excel sheets, this does not change anything, since Excel
 understands 'n'
 as the type as well. Actually, '1' is a derivative from the spec, and
 it
  seems to be just per chance that Excel understands it.
  Therefore, I changed dataTypeKind.number from '1' to 'n'.
@janmagnusdev
Copy link
Author

Tests are failing because the hardcoded substring in two tests is now different, as 1 has changed to n. This is expected and a simple fix, if this PR is generally accepted.

@janmagnusdev
Copy link
Author

@janmagnusdev please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

  • (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.
@microsoft-github-policy-service agree
  • (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.
@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

@janmagnusdev
Copy link
Author

Any updates on this?

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

Successfully merging this pull request may close these issues.

None yet

1 participant