Created attachment 150753 [details] Sample ODS The attached spreadsheet table was copied from bug 123421's sample, just without pivot table content. The sample is using Calibri font, which is installed on the system. Save it as XLSX and reopen. => The width of the most columns and height of empty rows change. Original 1st and 2nd column widths: 2.26 cm & 2.76 cm. XLSX 1st and 2nd column widths: 1.7 cm & 2.76 cm. Height of 2nd and other empty rows also changes from 0.56 cm to 0.45 cm. Observed using LO 6.3.0.0.alpha0+ (2e3b0c5d42d60d46cd9f8b8eda9424b095c63418) & 5.3.0.3 / Windows 7. Looks better in 5.2.0.4. => somewhat of a regression In 5.2.0.4 the column widths in the exported XLSX are 2.22 and 2.73 cm respectively. The row height is still 0.45 cm. Bibisected the 5.2 -> 5.3 difference to the following commit using repo bibisect-linux-64-5.3. Adding Cc: to Bartosz Kosiorek. https://cgit.freedesktop.org/libreoffice/core/commit/?id=40d892a2db4d750aaf0562c63004e693c028273c author Bartosz Kosiorek <gang65@poczta.onet.pl> 2016-07-19 00:26:54 +0200 committer Markus Mohrhard <markus.mohrhard@googlemail.com> 2016-07-28 23:23:49 +0200 tdf#100946 Fix width calculation and add customWidth support (.xlsx)
Created attachment 150754 [details] XLSX exported from ODS
Created attachment 150755 [details] Comparison screenshot
In Excel the exported sample has: - 15 row height (uniform), - 8.43 and 13.43 column widths. Change the column width and row height https://support.office.com/en-gb/article/change-the-column-width-and-row-height-72f5e3cc-994d-43e8-ae58-9774a0905f46
Please attach .xlsx file exported with Calc 5.2.0.4. The Default column width for MS Office is taken from Default Font size: https://www.ablebits.com/office-addins-blog/2017/02/28/change-autofit-column-width-excel/ In LibreOffice it is explicetely set: https://ask.libreoffice.org/en/question/4619/how-does-one-change-default-value-of-column-width/ Of course rows height could be easily fixed.
Created attachment 150761 [details] Sample ODS exported to XLSX with Excel 2016
Created attachment 150774 [details] Sample ODS exported to XLSX with LO 5.2.0.4 (In reply to Bartosz from comment #4) > Please attach .xlsx file exported with Calc 5.2.0.4. Done, thanks!
@Aron Unfortunately I was not able to create such document. If I create new document with custom cell width and height, it is properly exported by LO and looks ok under Excel and LibreOffice. Could you please provide instruction how to create such document?
(In reply to Bartosz from comment #7) > Could you please provide instruction how to create such document? I used attachment 149245 [details] from bug 123421, which is a pivot table, saving it as XLSX and reloading shows the narrow columns (perhaps that sample is more authentic, I just wanted to get rid of the unnecessary pivot parts). For the sample attached here I just copied the table, deleted the pivot table, pasted the table in its place, deleted the other pivot-related data and saved it.
(In reply to Aron Budea from comment #8) > saving it as XLSX and reloading shows the narrow columns A single narrow column, to be precise.
https://gerrit.libreoffice.org/71132 I'm sorry to jump in, not seeing it's assigned. The patch above would hopefully fix this; still, there's something unusual with the default width handling that I didn't try to closely debug: Saving it to an Excel format goes through the procedure of defining default width in XclExpColinfoBuffer::Finalize: the most-used width defined as the default. Then (previously to my patch) all the columns with such widths were removed. That is what (properly!) happened with the bug doc; but with hand-made samples, this funnily does not work: For a simple newly created spreadsheet with two cells with arbitrary content (A1 and B1), and column B having non-default width (all other columns not resized!), the default size is defined from width of column A (equal to width of columns from C and to the end). But immediately then, checking if column A has default width (when removing defaulted columns), returns false! Thus all columns (improperly!) seem "non-default", and all are written to the file, thus not exhibiting the bug.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/071d72cc3662168c58358ce53a77ceacbf80f545%5E%21 tdf#124741: export default column width to XLSX It will be available in 6.3.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.
I will check if this patch has resolved column width issue issue. Still the height of rows needs to be fixed.
(In reply to Bartosz from comment #12) > I will check if this patch has resolved column width issue issue. > Still the height of rows needs to be fixed. Any update ?
Dear Bartosz, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
z
Empty row height still changes when exported to XLSX (width fixed). LO 6.5+.
(In reply to Timur from comment #16) > Empty row height still changes when exported to XLSX (width fixed). LO 6.5+. Hi Timur, Could you please explain the steps to reproduce it ? Which file are you using ?
Start with a new spreadsheet. Click left/top to mark all. menu Format -> Rows > Height. Enter 12.7mm (=36pt). Save to xlsx. Open file in Excel. The row height is not 36pt. Open the archive in editor. The attribute customHeight="1" is missing in element <sheetFormatPr> in file sheet1.xml. Enter the attribute, save and update the archive. Open the changes file in Excel. The row height is correctly 36pt. I see the error in Version: 7.2.0.0.alpha0+ (x64) Build ID: ad9e04321df25824d2288a2ef1f4275f070f1cf7 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL
Dear Aron Budea, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still in 24.8.0.0.alpha0+ (f289fe3dca487c45417f7b40d51a4830f3369fb1) / Ubuntu.