Hi. Currently LibreOffice Draw has very slow import of PDF files. Take this example: try to open attach PDF. For me it will take infinite time to import on Linux Fedora 24 with L.O 5.1.6, so that it will never appear to me & I force L.O to quit ! I try it on L.O version 5.3.3 on Windows 7 which also show very slow import speed. This attached file is just an example. It seem that, currently, import mechanism of L.O for PDF very slow which make it, practically, useless for PDF file manipulation ...
Created attachment 133912 [details] BNF
Confirmed in ( I killed it ) Version: 5.5.0.0.alpha0+ Build ID: 6ab249ea6aecef5d3f35d624622a368061cad9c3 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group real 10m40.203s user 10m30.988s sys 0m3.448s
Also confirmed in ( I killed it as well ) Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) real 18m43.877s user 17m7.592s sys 1m59.576s
test in windows 10 with 5.3.5.2 64 bit 1069 pages in pdf 1.6 (acrobat 7) more than 150.000 words and more than 1 Million signs and some fonts. needs 3,5 GB of my 8 GB Ram after 2 green graph runs and then nothing done more. import pdf function needs to much memory and runs against resource walls. acrobat reader needs only 75 MB Ram in Task Manager. import all from acrobat reader with copy paste in LOO Writer only 350 MB Ram needed. Factor 10 or more RAM needed in LOO Draw PDF importer.
Created attachment 135942 [details] freepdf print first 220 pages of about 1100 (20%) freepdf print first 220 pages of about 1100 (20%) import about 5 minutes
Created attachment 135943 [details] odg of 220 pages in LOO Draw 5.3.5.2 win10 64bit odg of 220 pages in LOO Draw 5.3.5.2 win10 64bit
Too many pages in one run were imported. Import functions must make some parts like 128 pages and then next 128 pages and so on. At the end cat of all parts.
import of 220 pages in about 5 Minutes by 700 MB Ram
user needs a warning message pdf with many pages.
Created attachment 135956 [details] save of import pdf with 532 pages in LOO Draw 5.3.5.2 about 2 GB Ram needed and about 2 hours runtime for import and save.
Created attachment 135957 [details] part of first 532 pages printed with freepdf
Hi. Please can you test it on version 5.4.1 ? I'm unable for that because it is not available in my Fedora 26 Linux repositories. I notice that since version 5.4, the import mechanism of pdf in LibreOffice, changed radically. The importer now changed from it's origin. It is now other tool that that used in version 5.3.x For that it is better to test this issue on version 5.4.1 to see real situation of it.
confirm with Version: 6.0.0.0.alpha0+ Build ID: 9c165fe3084b7c054f9f04f3b065897abcbe2162 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-02_23:12:31 Locale: nl-BE (en_US.UTF-8); Calc: group and with 5.4.2 update off this morning very slow and eats a lot off ram more than 3.5gig have to kill the process off loading the document with okular a pdfreader it takes 2 seconds and 100mb ram with the Gimp about 15 seconds and 1.2gig off ram system os linux slackware64 current
test with 5.4.2.1-64 in win 10-64. Intel Ivy bridge needs more then 1 Gig for 20%-file, AMD Phenom II in 5.3.5 only about 700 MB only 6 to 7 per cent (25% is max for one process) in last phase of import in task manager. So factor 3 to 4 of improving is possible only in acceleration for cpu.
User needs a warning for pdf with many pages (more than 100). PDFs with many pages need a split in some parts for actual LOO-Import with other tools like FreePDF.
same behaviour in 6.1.0.3 x64 in win10-64
Dear yousifjkadom, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hi. This bug is still existing without any improvement, a fact which make LibreOffice useless for management of PDF files ..... It need radical change for PDF engine .... (&/or way via which deal with PDF files).
A possible workaround is for programmers: eating the elephant in some steps is better than one step. A solution is global document ODM with 10 or 20 pages parts with a preview window for the old way and a new way with options. So the work is cut by some pages in many documents in the odm. This is also a solution for different paper sizes and orientations.
Hi. The best way to fix this bug - as I see - is to radically change the way by which LO handle PDF files by changing it to native PDF editor. Currently, LO make it's effects on PDF indirectly by changing it into intermediate format then change this intermediate format to PDF again. The best way is to make LO a real PDF editor by making it deal with PDF natively, even if that need to create new sub-program special for PDF files. In the later case - if you accept it - Libre Draw will deal with vector graphic images (but not with PDF) & new sub-program (let we call it "Libre PDF) will deal with PDF only. I recommend this because this bug last very long without fix & it is really make LO not suitable to edit PDF books because most of them composed from more than 100 pages.
By the way, I forget to say that we have good program which is cross platforms called "Okular" can LO team fork it & develop it further to make from it the new proposed sub-program. If LO team add their already existing editing powers to Okular, then we will really will have good free & open source PDF editor .......
Created a separate bug 155030 because LO 7.6 can't open the PDF example now at all
Created attachment 186938 [details] Flamegraph On pc Debian x86-64 with master sources updated today, I retrieved a Flamegraph. (I had to kill LO because import never ended).
Miklos: Reading a bit https://conference.libreoffice.org/assets/Conference/Tirana/PDFium-updated.pdf (which is from 2018), I understand that pdfium is a faster lib to render pdf and has been used in LO to replace poppler lib in the long run. However, it seems poppler still used today. Any thoughts here? Does the Flamegraph trace retrieved may help to find hot spots in LO code?
pdfium is great to view a PDF. But it only gives us a bitmap. The (default) poppler-based PDF import rather focuses on giving you an editable Draw document. I would love to see poppler go away (with its horrible external process), but I guess these will stay with us for a long time. Each is good for its own use-case. Does that help?
(In reply to Miklos Vajna from comment #25) > pdfium is great to view a PDF. But it only gives us a bitmap. The (default) > poppler-based PDF import rather focuses on giving you an editable Draw > document. > I tried "insert image" with the pdf, I got the first page of the PDF quickly, perhaps it's a case where pdfium is used? > I would love to see poppler go away (with its horrible external process), > but I guess these will stay with us for a long time. Each is good for its > own use-case. Does that help? Do you think the slowliness is in Poppler or in LO? (I don't know if the Flamegraph trace allows to tell)
(In reply to Julien Nabet from comment #26) > I tried "insert image" with the pdf, I got the first page of the PDF > quickly, perhaps it's a case where pdfium is used? Yes. > Do you think the slowliness is in Poppler or in LO? (I don't know if the > Flamegraph trace allows to tell) No idea about this, sorry. :-)
the PDF file opening still takes so much time and takes over 4,5Gb of memory with 100% of CPU using in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5cd9de202765e243e41416802f3e4486b8a96f16 CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded
(In reply to Miklos Vajna from comment #27) > (In reply to Julien Nabet from comment #26) > > I tried "insert image" with the pdf, I got the first page of the PDF > > quickly, perhaps it's a case where pdfium is used? > > Yes. pdfium seems very fast then! (even if it was just for first page). > > > Do you think the slowliness is in Poppler or in LO? (I don't know if the > > Flamegraph trace allows to tell) > > No idea about this, sorry. :-) It seems we need to use more pdfium (instead of Poppler) so it requires someone with some expertise and some time, I've got a bit of second one but none about first one=>uncc myself