Bug 161019 - Visual fidelity issues when exporting spreadsheets with merged cells to PDF after changes to cell data management
Summary: Visual fidelity issues when exporting spreadsheets with merged cells to PDF a...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
24.2.0.0 alpha0+
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:24.8.0 target:24.2.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks: PDF-Export Calc-Merge-Split
  Show dependency treegraph
 
Reported: 2024-05-10 04:50 UTC by Yoichiro Hibara
Modified: 2024-05-17 11:35 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yoichiro Hibara 2024-05-10 04:50:22 UTC
Description:
After a recent commit (e27d4cc31e04be4c47b5085dfa2363ee45457e8a) that changed the way cell data is managed using an item pool (using unorderd_set instead in the latest source code), there appear to be issues with the rendering of borders in merged cells. The visual appearance of the spreadsheet is incorrectly altered when exporting to PDF, as demonstrated by the differences between the "test_correct.pdf" and "test_wrong.pdf" files provided in the attached Google Drive link: https://drive.google.com/drive/folders/1Ko6gLg7fNzzCwjmTHoenB01SnyXG_5c9?usp=sharing.

Steps to Reproduce:
1. Download the test spreadsheet file "test.xlsx" from the following Google Drive link:
https://drive.google.com/drive/folders/1Ko6gLg7fNzzCwjmTHoenB01SnyXG_5c9?usp=sharing

2. Check out the LibreOffice code from the repository at a commit before the problematic changes were introduced, specifically before commit e27d4cc31e04be4c47b5085dfa2363ee45457e8a.

3. Build and run LibreOffice from this pre-commit code.

4. Open the "test.xlsx" file in LibreOffice Calc and export it as a PDF. The resulting PDF should look identical to the "test_correct.pdf" file provided in the Google Drive link.

5. Now, check out the LibreOffice code at a commit after the problematic changes were introduced, specifically after commit e27d4cc31e04be4c47b5085dfa2363ee45457e8a.

6. Build and run LibreOffice from this post-commit code.

7. Open the same "test.xlsx" file in LibreOffice Calc and export it as a PDF. The resulting PDF should now have visual differences compared to the "test_correct.pdf" file. The exported PDF should look like "test_wrong.pdf" file provided in the Google Drive link, where the border of merged cells is not drawn correctly.

Actual Results:
The exported PDF is "test_wrong.pdf" file provided in the Google Drive link: https://drive.google.com/drive/folders/1Ko6gLg7fNzzCwjmTHoenB01SnyXG_5c9?usp=sharing

Expected Results:
The exported PDF should be "test_correct.pdf" file provided in the Google Drive link: https://drive.google.com/drive/folders/1Ko6gLg7fNzzCwjmTHoenB01SnyXG_5c9?usp=sharing


Reproducible: Always


User Profile Reset: No

Additional Info:
During debugging, I focused on the lclSetMergedRange function, which appears to correctly recognize the range of merged cells. The problem does not seem to lie within this function.

However, I suspect that the root cause of the bug is related to the code changes introduced to optimize memory usage. Specifically, the modifications made to manage cell data using an item pool (using unorderd_set instead in the latest source code), including the introduction of the PUTCELL macro and the changes in how cell borders are stored and retrieved, are likely responsible for the incorrect rendering of borders in merged cells.

Further investigation and debugging efforts will be focused on these memory optimization changes to identify the precise cause of the issue and develop a suitable fix.
Comment 1 m_a_riosv 2024-05-10 16:28:44 UTC
Reproducible
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ad1f0bdeac30fca1dc56a08803ef23f2aca4db05
CPU threads: 16; OS: Windows 11 (10.0 build 22631); UI render: default; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded

Last working
Version: 7.6.6.3 (X86_64) / LibreOffice Community
Build ID: d97b2716a9a4a2ce1391dee1765565ea469b0ae7
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: CL threaded
Comment 2 raal 2024-05-12 06:21:17 UTC
(In reply to Yoichiro Hibara from comment #0)

> 5. Now, check out the LibreOffice code at a commit after the problematic
> changes were introduced, specifically after commit
> e27d4cc31e04be4c47b5085dfa2363ee45457e8a.
> 

153258: tdf#150534 reduce the memory consumption of cells when calculating | https://gerrit.libreoffice.org/c/core/+/153258

Adding CC to Noel Grandin. Noel, please take a look. Thank you.
Comment 3 Commit Notification 2024-05-14 16:47:29 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6f8a73a379d97829080367b21d54f9b5fab781c9

tdf#161019 tdf#159846 spreadsheet border rendering

It will be available in 24.8.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 4 Yoichiro Hibara 2024-05-14 16:58:17 UTC
Thank you for your prompt response. I'll apply the patch and try again immediately.
Comment 5 Yoichiro Hibara 2024-05-14 17:46:14 UTC
I just tested it on my end and confirmed that it is correctly converted :)

I truly appreciate your swift resolution of the issue!!
Comment 6 Commit Notification 2024-05-17 11:35:23 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

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

tdf#161019 tdf#159846 spreadsheet border rendering

It will be available in 24.2.4.

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.