Description: The content in excel cell is not visible by default in the MSO excel until you doble click it.But When we open the excel in Libre office, the content in the cell is fully visible. Hence when I export to pdf the content is fully visible where as when I do Export to pdf from MS office the content in the cell is not fully visible. When I adjust this cell in Libre office calc then doing a export is some what solving the problem, but if we can import this file same as in MSO then export can match the output from MSO. Steps to Reproduce: 1. Open the attached file "Example 3 - Original Document_LastPage_Scrubbed.xlsm" 2. Observe the 4th cell (starts with Reason for ..) 3.This cell has more content, but when exported to pdf from MSO and LO has the difference. Actual Results: Import and Export to PDF is not matching with the MS office. Expected Results: Import and Export to PDF should match with the MS office. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 195252 [details] source document
Created attachment 195253 [details] PDF from Libre office export
Created attachment 195254 [details] PDF from MS office export
Created attachment 195255 [details] MSO_Vs_LO
Row height id different. Regression Confirm in Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2afdc61dd3138b383fb73dae2242ba1a9c8de901 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb) Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Justin Luth ; Could you possibly take a look at this one? Thanks b3c14523e3d622babc44ea6b0bc7e5c24eb14c00 is the first bad commit commit b3c14523e3d622babc44ea6b0bc7e5c24eb14c00 Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Jul 11 19:46:40 2023 +0200 source d15c4caabaa21e0efe3a08ffbe145390e802bab9 140260: tdf#123026 xlsx import: recalc optimal row height on import | https://gerrit.libreoffice.org/c/core/+/140260
Created attachment 195382 [details] Example 3 - Original Document_LastPage_Scrubbed_5.2.pdf: PDF from LO 5.2 I noticed that even earlier (I looked at LO 5.2 and 7.6) when row 5 was not "auto-expanded" that it displays "- Adjustment NPV calculation" (the middle of the content) instead of the top row of the content. So this has never really been correct. I wonder about this file, whether it is a generated, non-excel-created document. If I unmerge and then re-merge cell A5, then Excel 2010 roundtrips it as: <row r="5" spans="1:9" ht="12.75" customHeight="1" x14ac:dyDescent="0.2"> and LO opens that up just fine. The original document only defines row 5 as <row r="5" spans="1:9" x14ac:dyDescent="0.2"> meaning it starts with the default height, but it auto-grows with word-wrap. Since word-wrap is kindof enabled (on the first of the merged cells), I would have expected it to wrap. However, I see that merged cells never auto-size in Excel. LO on the other hand is able to auto-size a merged cell. So I'm not sure how to handle that. I doubt we want to limit LO so that it mimics Excel by not auto-growing merged cells when the content changes, and we can't remove word-wrap because it DOES do that. We also can't force customHeight on the row simply because it has some merged cells.
A simple work-around is to set a height of 12.76 instead of 12.75 (the default). Alternatively, in 24.8 there is a RecalcOptimalRowHeightMode setting (bug 124098) that can prevent/prompt auto-fit on load, but then you will run into problems of non-merged cells not auto-growing.
I'm going to remove my name from the regression field. Ultimately, we are handling this file OK. The row needs to be "dynamic height" as seen in Excel if you put word-wrapped text in a cell in this row. MSO format has a mechanism to force the default height (customHeight=1), and that mechanism is not invoked. So it is an implementation detail as to exactly "how" dynamic height is implemented. LO's implementation is better IMHO.