Description: In Calc, if the whole row is merged into a single cell, it would cause PDF export stuck there. Steps to Reproduce: 1. Start a new file in Calc 2. Input anything in a cell, like, in A4 3. Select the whole Row 4, right-click on the cell and select Merge Cells 4. Don't need to save, just directly export PDF Actual Results: It is stuck there forever. Expected Results: It should be able to produce PDF file. Or at least give a warning since merging the whole row doesn't really make sense. Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9e3803ae438ddcf91ec0e15431be379561d28ba6 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb) Locale: zh-TW (zh_TW.UTF-8); UI: en-US Calc: threaded
Correct the result. It doesn't stick there forever, but take a very, very long time to produce a more than 200 pages of PDF file. Maybe it is about judging or calculating what's to print.
I don't consider it to be a bug. LibreOffice generated 2341 pages in 10 seconds in one PDF file. Is reasonable. Version: 25.2.0.1 (X86_64) / LibreOffice Community Build ID: ddb2a7ea3a8857aae619555f1a8743e430e146c9 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
(In reply to BogdanB from comment #2) > I don't consider it to be a bug. LibreOffice generated 2341 pages in 10 > seconds in one PDF file. Is reasonable. > > Version: 25.2.0.1 (X86_64) / LibreOffice Community > Build ID: ddb2a7ea3a8857aae619555f1a8743e430e146c9 > CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 > Locale: ro-RO (ro_RO.UTF-8); UI: en-US > Calc: threaded Not in every system I think. It took nearly half an hour here in my laptop to generate 265 pages PDF. Also, it's not "reasonable" to generate a 2341 pages PDF file while most is caused by unused merged cells. It may not be a "bug", more like an UX issue.
BTW, Excel would just generate one page PDF with its data in it. We got a user reporting this issue to us. The original file which caused this issue seems to be converted from xls(x) file, which there is a "whole-row merged" row in it. It must not cause any problem while using Excel, but after converting it to ODS file this issue is shown. So I think it's more like a user experience issue.
Created attachment 198670 [details] Test with Excel, add border line You can see it has only one page with data in it, and the border line is incomplete.
Created attachment 198671 [details] PDF generated by LibreOffice, with border It created a 2341 page PDF file, every page has the border line. It's not wrong, but does it make sense?
(In reply to Franklin Weng from comment #6) > Created attachment 198671 [details] > PDF generated by LibreOffice, with border > > It created a 2341 page PDF file, every page has the border line. It's not > wrong, but does it make sense? BTW this page took 5 hours and 50 minutes to complete generating in my laptop.
Please attach a sample file(s).
It is working in any new Calc file.
(In reply to Franklin Weng from comment #4) > BTW, Excel would just generate one page PDF with its data in it. Confirming, probably they ignore the cell width in some cases. Similar issue in bug 49701, bug 150239, bug 158604 (and others) where I commented that lengthy operations should have a feedback.
Besides the long-lasting operation on slow systems (here it takes just a two or three seconds), it is a question whether a merged row or column should result in this oversized data. Perhaps MSO does it inconsistently => needsDevAdvice