Bug 161453 - Wrap text not exported to XLS/XLSX
Summary: Wrap text not exported to XLS/XLSX
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:xls, filter:xlsx, regression
Depends on:
Blocks: Anchor-and-Text-Wrap File-Export
  Show dependency treegraph
 
Reported: 2024-06-07 08:35 UTC by Roman
Modified: 2024-06-11 04:12 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
strok.xlsx (6.14 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2024-06-07 08:45 UTC, Roman
Details
Screenshot LibreOffice vs Excel (137.35 KB, image/png)
2024-06-07 09:20 UTC, m_a_riosv
Details
strok.png (165.88 KB, image/png)
2024-06-07 09:43 UTC, Roman
Details
перенос текста (50.59 KB, image/png)
2024-06-07 11:00 UTC, Roman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman 2024-06-07 08:35:31 UTC
Description:
EN: The line break rule is not saved after the document is closed.
1. The cell contains the formula
2. .xlsx
RU: Не сохраняется правило переноса строки после закрытия документа.
1.	В ячейке содержится формула
2.	.xlsx


Steps to Reproduce:
EN:
1. Open document
2. Cell C9 apply a line break
3. Save and close the document
4. Open the document
RU: 
1.	Открыть документ
2.	Ячейка  С9 применить перенос строки
3.	Сохранить и закрыть документ
4.	Открыть документ


Actual Results:
EN: The line break rule is not saved after the document is closed
RU: Не сохраняется правило переноса строки после закрытия документа


Expected Results:
EN: The line height is correct according to the value of the text cell.
RU: Высота строки верна согласно значению ячейки текста.



Reproducible: Always


User Profile Reset: No

Additional Info:
EN: There is a monthly impact on the user's work.
RU: Есть влияние на работу пользователя ежемесячное.
Comment 1 Roman 2024-06-07 08:45:25 UTC
Created attachment 194578 [details]
strok.xlsx

strok
Comment 2 m_a_riosv 2024-06-07 09:20:30 UTC
Created attachment 194580 [details]
Screenshot LibreOffice vs Excel

Seems the issue is in the input line, not in the cell.

Version: 24.2.4.2 (X86_64) / LibreOffice Community
Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 3 m_a_riosv 2024-06-07 09:21:24 UTC
Reproducible also with
Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 6d39b1a6068bbbd5ca4947f668f989dbfb73342d
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 4 Roman 2024-06-07 09:43:43 UTC
Created attachment 194581 [details]
strok.png

EN: I think maybe I was misunderstood. That's why I attached a screenshot
RU: Мне кажется, возможно меня не поняли. Поэтому приложил скриншот
Comment 5 m_a_riosv 2024-06-07 09:58:39 UTC
What you want is not possible, references always take the plain text, nothing of the format of the source cell.

*** This bug has been marked as a duplicate of bug 56217 ***
Comment 6 Roman 2024-06-07 10:54:03 UTC
(In reply to m_a_riosv from comment #5)
> What you want is not possible, references always take the plain text,
> nothing of the format of the source cell.
> 
> *** This bug has been marked as a duplicate of bug 56217 ***

How is this impossible? everything works in Excel. And I looked at bug 56217, it does not apply to me, the principles are different.
Here the principle is not to transfer the formatting of the source cell, but to adjust the row height by value, even when there is a formula.
Как это невозможно? в Excel все работает. И я посмотрел bug 56217, он не относится ко мне, принципы разные.
Тут принцип не переноса форматирования исходной ячейки, а подгон высоты строки по значению, даже тогда когда есть формула.
Comment 7 Roman 2024-06-07 10:55:50 UTC
I didn't write a word about the dimension of the cell. Only about the operation of the text transfer function.
Я ни слова не писал о размерности ячейки. Только о работе функции переноса текста.
Comment 8 Roman 2024-06-07 11:00:50 UTC
Created attachment 194582 [details]
перенос текста

картинка
Comment 9 ady 2024-06-07 21:59:42 UTC
There is some mix of 2 issues in this report. Whether any of these would be considered a bug, that's another matter.

A. In older versions, the size of cell C9 (and in particular its height), was not automatically recalculated (optimized?) when opening the file. So, when opening the file in LO 7.6 and older, the height of cell C9 is much bigger than when opening the same file with LO 24.2. This behavior is about opening and displaying the spreadsheet, without taking any action. I don't know whether the change is intentional.


B. The problem described in comment 0 seems to be focused on the following steps.

1. Apply "Wrap text" to cell C9.
2. Save and reload.

Actual result: the Wrap Text property in cell C9 is not saved to the XLSX file.

It also happens with XLS.

It does not happen with ODS (but there are other reports regarding Wrap text that were opened relatively-recently, during the LO 7.6 cycle).

Reproduced with:

Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 8501cb20627e5bc36d760b53b0990f4105c4ff65
CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: CL threaded

Also reproduced with LO 24.2, but not with LO 7.6. > Regression.
Comment 10 ady 2024-06-07 22:01:43 UTC
I am changing the Summary field from:

"The line break rule is not saved after the document is closed"

to:

"Wrap text not exported to XLS/XLSX"
Comment 11 raal 2024-06-09 16:45:16 UTC
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2.
Adding Cc: to Paris Oplopoios ; Could you possibly take a look at this one?
Thanks
 0fd3d8fa5041781bea37aeda264bda71a66c6152 is the first bad commit
commit 0fd3d8fa5041781bea37aeda264bda71a66c6152
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Mon Aug 28 10:38:53 2023 +0200

    source 1760ee4d328cfb6ba22a5b3c84016625b12adb25

155970: sc: Fix wrapText not being applied correctly on export | https://gerrit.libreoffice.org/c/core/+/155970