Bug 123026 - LibreOffice ignore xlsxwriter 'text_wrap' formatting option, seems optimal height for row is not being set to hold cells with wrapped text
Summary: LibreOffice ignore xlsxwriter 'text_wrap' formatting option, seems optimal he...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.0.6.2 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:24.2.0
Keywords: filter:xlsx
: 107552 157468 (view as bug list)
Depends on:
Blocks: Calc-Cells XLSX-External-Generators
  Show dependency treegraph
 
Reported: 2019-01-28 23:42 UTC by Aldennis
Modified: 2024-01-13 12:10 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Generated excel file using xlsxwriter (5.98 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2019-01-28 23:49 UTC, Aldennis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aldennis 2019-01-28 23:42:43 UTC
Description:
I'm creating an excel document using xlsxwriter through python. However, I have a requirement to output the same file and layout in PDF format. I've tried to use the LibreOffice command line option for converting *.xlsx file to PDF but I always end up with an overlapping text. Openning the same file in OpenOffice and Excel 2013 had the row heigt adjusted properly to fit the text.

Steps to Reproduce:
1. Open the attached sample file in LibreOffice, OpenOffice and MS Excel
2.
3.

Actual Results:
The row doesn't resize to fit the text in the cell properly even though 'text_wrap' is enabled in xlsxwriter.

Expected Results:
Row should resize automatically to fit the cell when 'text_wrap' is enabled in xlsxwriter


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Someone has already asked this issue in xlsxwriter github page but gets dismissed placing the reason to be software specific: https://github.com/jmcnamara/XlsxWriter/issues/80

Already asked this in the LibreOffice forum and suggested to file a bug report
https://ask.libreoffice.org/en/question/179550/why-libreoffice-ignore-xlsxwriter-text_wrap-option-where-ms-excel-and-apache-openoffice-do-not/
Comment 1 Aldennis 2019-01-28 23:49:34 UTC
Created attachment 148719 [details]
Generated excel file using xlsxwriter

Open the attached file in LibreOffice, OpenOffice and MS Excel.
Comment 2 V Stuart Foote 2019-01-29 06:06:18 UTC
Confirmed on Windows 10 Pro 64-bit en-US with
Version: 6.1.4.2 (x64)
Build ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
Locale: en-US (en_US); Calc: group threaded

and current master/6.3.0

But actually, the filter import to Calc *does* set the cell formatting to "Wrap text automatically". An uncheck and check of the value will expand the row wrapping the text. 

As will Clearing direct formatting, with an immediate undo.

Applying a Format -> Row -> Optimal height or 0.0 will also expand.

So unclear what is preventing the cell height from expanding to hold the wrap upon import, but the wrap attribute is being set. Just not displayed after import.

Saving to ODF format, both .ODS and flat .FODS, is read back in with row expanded to hold wrapped text.
Comment 3 V Stuart Foote 2019-01-29 17:40:37 UTC
So isn't this more an issue of the optimal height, for rows holding cells with wrapped text, not being applied on initial view?

Seems a long standing issue judging from the see also of bug 32950 bug 55433 and bug 62361, but not sure I'd call it a dupe just yet.
Comment 4 V Stuart Foote 2019-01-29 20:53:29 UTC
Correcting bug 62268 [1] looks to maintain performance by not recalculating height of all rows, but just when parsing of ODF spreadsheets with row styling "use-optimal-row-height" set true.

Guess that means for some externally generated XML, the XlsxWriter output here, there is no style "use-optimal-row-height" being set in the import filter--so the row height is locked at some default row height even though the text wrap is enabled.

Can the import filter(s) be adjusted to set the use-optimal-row-height style on rows when just the wrap text cell is encountered in a cell? That seems to be the way Excel 2007+ consumed the XML--no row height.

Or, should handling output of the XlsxWriter generator be NOB? It does clear as soon as we export to an ODF styled format, or modify the imported sheet.

=-ref-=

[1]https://gerrit.libreoffice.org/#/c/52521/
Comment 5 Justin L 2022-09-14 23:37:25 UTC
repro 7.5+

See bug 62268 and the controversial patch  693953dd4699887bd3f5bca2c3582b5fae1d6992 that explicitly called Calc to re-calculate rows after ODS load.
Comment 6 Justin L 2022-09-17 14:50:42 UTC
I tried to fix, but Library_scfilt.mk can't connect with the sc/source/ui/inc/sizedev.hxx.
Comment 7 Justin L 2022-09-17 15:10:36 UTC
*** Bug 107552 has been marked as a duplicate of this bug. ***
Comment 8 Justin L 2022-09-20 18:02:44 UTC
I might try  https://gerrit.libreoffice.org/c/core/+/140260 for LO 7.6.
Comment 9 Kohei Yoshida 2022-09-29 13:29:08 UTC
(In reply to V Stuart Foote from comment #4)
> Correcting bug 62268 [1] looks to maintain performance by not recalculating
> height of all rows, but just when parsing of ODF spreadsheets with row
> styling "use-optimal-row-height" set true.

FWIW, this is not an accurate description of this flag.  Please refer to https://bugs.documentfoundation.org/show_bug.cgi?id=128204 for what this flag is used for.  In short, this flag simply stores boolean states that represent, in the UI, whether the row heights have been calculated via "optimal row heights" feature. If set to false, that means the user has manually typed in the desired row height value.  This flag is not meant to control whether or not we should recalculate row heights on document import.
Comment 10 Commit Notification 2023-06-27 00:28:37 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b0f55a04f081ff7f566c3ba5b6d6d6be3675e0f7

tdf#123026 sc xlsx: provide per-sheet optimal row height setting

It will be available in 24.2.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.
Comment 11 Commit Notification 2023-07-11 17:39:01 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d15c4caabaa21e0efe3a08ffbe145390e802bab9

tdf#123026 xlsx import: recalc optimal row height on import

It will be available in 24.2.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.
Comment 12 Mike Kaganski 2023-09-29 19:02:23 UTC
*** Bug 157468 has been marked as a duplicate of this bug. ***
Comment 13 Michael Meeks 2024-01-13 11:18:49 UTC
Wow, the commit message:
> This might have a very negative effect on the time needed to open a file.

Good to measure but stats based on the somewhat tiny files we have in our tests are unlikely to be representative of the problem here. AFAIR we have worked hard to get these "calculate optimal-height" code-paths off our profiles, which might also has the benefit of not tweaking / breaking documents on load/save by perturbing all the row heights.

If this is to placate some lower quality file generator, I wonder if we can detect the generator string, or some quirk of what is generated to trigger this sort of thing. Or - of course, perhaps I'm just paranoid - we'll see when we get COOL 24.02 out there and some long-running profiles going I guess =)
Comment 14 Justin L 2024-01-13 12:10:24 UTC
(In reply to Michael Meeks from comment #13)
> Wow, the commit message:
> > This might have a very negative effect on the time needed to open a file.
Yes, I included Noel in the review process in comment 11's patch.

> If this is to placate some lower quality file generator,
It is needed for MS Excel. I ran into the problem constantly at work.