Description: LibreOffice Calc can handle only 1024 columns, but default style says it apply style to column 1025 too. If such .xlsx document is processed with PhpOffice and single cell value is written, <col> nodes gets expanded, including for <col min="1025" max="1025"/>. This column cannot be processed by LibreOffice Calc and produces warnings that some information is lost. Value should be at most 1024 (or whatever limit is in 6.1). Steps to Reproduce: 1) Open LibreOffice Calc 2) File > New > Spreadsheet 3) File > Save As, choose name vanilla.xlsx > Save Extract contents of vanilla.xlsx file to some directory. Actual Results: In the xl/worksheets/sheet1.xml file in the node worksheet/cols/ you'll find node <col collapsed="false" customWidth="false" hidden="false" outlineLevel="0" max="1025" min="1" style="0" width="11.52"/> Expected Results: <col collapsed="false" customWidth="false" hidden="false" outlineLevel="0" max="1024" min="1" style="0" width="11.52"/> Reproducible: Always User Profile Reset: Yes Additional Info: Ideally I prefer to avoid ranges at all if that does not change how documents are shown. If the max will be in tens of thousand, after processing with PhpOffice tens of thousands of nodes will be generated after writing even single cell. Of course it's problem of PhpOffice, but it would be good not to trigger it. File produced on my copy of libreoffice is attached. Bug was filled in Ubuntu bug tracking system at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1796698 and instructions were given to submit report here. Version: 6.0.6.2 Build ID: 1:6.0.6-0ubuntu0.18.04.1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group
Created attachment 145586 [details] Example file
Repro. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 750ccfb2a60582a5652c08f3cbb6f11d4c152275 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 22 November 2018
Dear Aidas Kasparas, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
fixed after https://git.libreoffice.org/core/+/071d72cc3662168c58358ce53a77ceacbf80f545%5E%21
Actually, although the problem actually doesn't manifest now for majority of cases, it still is reproducible like this: 1. Create a new spreadsheet 2. Go to last column: AMJ (Ctrl+Arrow Right) 3. Change the width of column AMJ 4. Save as XLSX. The reason is the code in sc/source/filter/excel/xetable.cxx introduced in https://git.libreoffice.org/core/+/64274b38f6cc50a8bb49f114f1ac9e7c1c3b3c4f back in 2009: that was the commit introduced export to XLSX (integrated to LO from Go-oo). The code starts with this comment: > // if last column is equal to last possible column, Excel adds one more which is directly taken from the older code that exports to XLS binary formats. Obviously, this is just a left-over from copy-paste. When writing to OOXML format, Excel doesn't do that. Setting to NEW.
https://gerrit.libreoffice.org/c/core/+/86046
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f1aec2392dba32e90f2cb0e4ad3c84bcbbd9f305 tdf#120502: Excel doesn't increment max column for OOXML It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski: Thanks for the fix. Any plan to backport this to libreoffice-6-3 and libreoffice-6-4 branch?
(In reply to Kevin Suo from comment #8) > Mike Kaganski: Thanks for the fix. Any plan to backport this to > libreoffice-6-3 and libreoffice-6-4 branch? Backported to 6-4: https://gerrit.libreoffice.org/c/core/+/86428
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/925be88167868798c97ff1f66dcdb9bd3bbec1e2 tdf#120502: Excel doesn't increment max column for OOXML It will be available in 6.4.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/6599bdfd7a108617e7b920a7ebe30cd1da585718 tdf#120502: Excel doesn't increment max column for OOXML It will be available in 6.3.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.