Bug 140177 - LibreOffice hangs showing Repagination on HTML file with table convert/export to PDF
Summary: LibreOffice hangs showing Repagination on HTML file with table convert/export...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.1.6.3 release
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Repagination HTML-Import
  Show dependency treegraph
 
Reported: 2021-02-05 08:46 UTC by Michael Wallach
Modified: 2025-10-07 08:50 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
File that results in LibreOffice hanging (763.04 KB, text/html)
2021-02-05 08:46 UTC, Michael Wallach
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Wallach 2021-02-05 08:46:49 UTC
Created attachment 169491 [details]
File that results in LibreOffice hanging

For attached HTML file, LibreOffice is hanging on convert to HTML. With Other HTML files this is not an issue. Unable to determine what about this file is causing to hang. Using below from command line to test:

/opt/libreoffice/program/soffice.bin -env:UserInstallation=file:///opt//tomcat/temp .jodconverter_socket_host-127.0.0.1_port-8101 --headless --nodefault --nofirststartwizard --nolockcheck --nologo --norestore --backtrace --convert-to pdf:writer_pdf_Export --outdir ./ ./testFile.html

File causing issue is attached
Comment 1 Indy 2021-02-05 11:28:46 UTC
This defect is impacting an end customer's Go Live, is there any way to expedite the investigation on it, please?  Any details on how long resolution may take and if a fix can be provided would be extremely useful.  Many thanks.
Comment 2 Hossein 2022-01-27 12:42:01 UTC
Version: 7.2.4.1 / LibreOffice Community
Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9
CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

$ time google-chrome --headless --disable-gpu --print-to-pdf testFile.html 
real	0m2.397s
user	0m0.149s
sys	0m0.098s

$ time libreoffice7.2 --headless --convert-to pdf testFile.html 
real	7m28.437s
user	7m27.877s
sys	0m0.337s
Comment 3 Buovjaga 2022-01-27 12:44:28 UTC
Michael: Hossein was able to convert the file and me as well through the UI. Did the conversion never finish for you?

The performance is bad and should be improved.

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: eb69767d7c1bb8e6e780fd9503f08c9d7f5ecb45
CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: fi-FI (fi_FI); UI: fi-FI
Calc: threaded
Comment 4 QA Administrators 2024-01-28 03:14:11 UTC Comment hidden (obsolete)
Comment 5 Buovjaga 2025-10-04 07:09:59 UTC
Perf seems to have improved significantly. With 7.6 on Linux I get
real    5m37,902s
user    5m30,327s
sys     0m0,682s

With 25.8:
real    3m1,406s
user    2m58,393s
sys     0m0,355s

With latest master:
real    2m36,406s
user    2m33,020s
sys     0m0,159s
Comment 6 Hossein 2025-10-07 08:50:03 UTC
I can confirm big improvement:

$ time libreoffice --headless --convert-to pdf testFile.html 
real	1m25.795s
user	1m23.655s
sys	0m0.141s

But there is still a big gap between this result and what is currently achievable with a browser:

Without GPU:
$ time google-chrome --headless --disable-gpu --print-to-pdf testFile.html 
real	0m0.938s
user	0m0.390s
sys	0m0.219s

It is interesting that the system time for LibreOffice is actually less than Chrome, but the user/real time is multiple times compared to Chrome. The CPU time is wasted in many nested loops/conditionals/inefficient operations.

Profiling shows Wasted time is spent in SwTabFrame::MakeAll(), which is a huge function containing ~1K line of code.