Description: Take a simple, straight-forward Impress presentation with a couple of slides, a couple of embedded pictures and use one of Impress' own standard templates (like the one with the green title bar background), then export this presentation to PDF and you can wait minutes (!) till it completes on a powerful enough hardware. Note: It makes no difference if you select image compression during the PDF export or not. HW: MacBook Pro Retina 15", early 2013, 16GB RAM, quadcore CPU, Intel 4000 HD and Nvidia GeForce GT 650M SW: macOS 10.12.1, LibO 5.2.3.3 with OpenGL enabled and no OpenCL Steps to Reproduce: 1.See description 2.Use atached sample presentation (will be attached after I file the bug) 3. Actual Results: conversion takes many minutes Expected Results: conversion should finish within max. 30 s Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0
Created attachment 128402 [details] sample presentation to test slow PDF export
No repro with Version: 5.2.1.2 Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 Threads CPU : 2; Version de l'OS :Mac OS X 10.12; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group In the Export to PDF dialog, I deactivated all of the options on the right hand side, but left the default compression ratios suggested by LO. The export completed with the test file provided in approximatel 20s. Version: 5.2.1.2 Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 Threads CPU : 2; Version de l'OS :Mac OS X 10.12; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group Hardware (macmini mid-2010, Intel Core 2 Duo, 4gb RAM, Nvidia Geforce 320M @Frank : there must be something else that is absent from your description - which options, if any, do you choose when you export to PDF ?
@Alex: I got it: in the "export to PDF" dialog, enable the creation of "PDF/A-1a" and the you will see the performance impact. Without "PDF/A-1a" creation, it is fast. With "PDF/A-1a" creation enabled, you will wait minutes. BTW, I tested with and w/o OpenGL enabled and it made no difference on my machine.
Thanks Frank. Indeed, with the PDF/A-1a option ticked, I can confirm.
This bug is still there - even with LibO 5.4 and the move to pdfium. Does anybody care about such bugs?
I tested this old issue again, using LibO 6.0.3.1 on macOS 10.13.3. It's all unchanged, the bug is still there.
Repro with Version: 6.1.0.0.alpha0+ Build ID: dd4f1b1bd31daf080dc0420524712dc244e539b5 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-20_23:26:38 Locale: en-US (nl_NL); Calc: CL Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL and with Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89) ---- Crash while exporting with Versie: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 and with LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5 ---- Layout is missing content but export is fast with LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
This continues to be a horrible performance issue, now open for almost 2 years. Since you want to save a PDF in the PDF/A archive format, it's high time someone looks at it.
In 6.2.2 it is still slow with A-1a, but in 6.3 the archive format is A-2b and it only takes about 4 seconds. You can test with https://wiki.documentfoundation.org/QA/Testing_Daily_Builds I hope we can close this as WORKSFORME after others have tested. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 1fee3f1da6291bfbcd75455512726215d41b3e83 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 18 April 2019
+/- 6 seconds.. So fixed IMHO Version: 6.3.0.0.alpha0+ Build ID: 3a5d78365dd172881c16c03e67f2d170ffc6d7d4 CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-04-09_22:53:59 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL