Hi. I tried to edit a scanned PDF by using LibreOffice Draw but when I click on "export" to .pdf or "save as pdf", the application freeze & process of saving failed ! Please your kind fix. Scanned PDF is here: https://drive.google.com/file/d/0B1nB8I_1Xoa3UmNxTFhBbzA4Y3M/view?usp=sharing Please inform me when you download this pdf so as to remove it. Best.
No, it doesn't fail, it just takes some time. In Version: 5.4.0.0.alpha0+ Build ID: d3b5bd4a07a619db6bee1c39c32280ac3c620532 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group it takes real 5m58.726s user 5m50.052s sys 0m5.624s but eventually the new pdf is created. Could you please attach the original pdf to the ticket ? it would be nice if you can create a minimal document as the one you mentioned has ~350 pages.
it seems it's faster in previous versions. in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) it takes real 2m28.071s user 2m9.792s sys 0m1.428s
in Version: 4.2.0.0.alpha1+ Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 it takes real 5m17.058s user 5m7.044s sys 0m1.676s while in Version: 4.1.0.0.alpha1+ Build ID: a2c9d4f8bbde97f175bae4df771273a61251f40 it takes real 2m14.649s user 2m10.760s sys 0m1.160s thus, it can be considered a regression.
The link in bug description now reports that the file does not exist. This makes it impossible to bibisect this bug, and it will make it impossible to report timing of a fixed LibreOffice. How big is the slow .pdf? Is there any reason not to attach it to the bug report?
(In reply to Terrence Enger from comment #4) > The link in bug description now reports that the file does not exist. > This makes it impossible to bibisect this bug, and it will make it > impossible to report timing of a fixed LibreOffice. > > How big is the slow .pdf? Is there any reason not to attach it to the > bug report? YOu're right! Setting to NEEDINFO until the reporter attaches the problematic document...
Created attachment 132266 [details] output1
Created attachment 132267 [details] output2
I attached PDF here directly. But due to it's size higher than limit for upload allowed here, I upload 2 files: - output1: same PDF but after deleting last 2 pages from it. - output2: same PDF but after deleting 1st 2 pages from it. I wish you fix this slowness which make LO draw useless practically. Best.
Created attachment 132325 [details] bibisect details, 1min+ vs. 2min+ and 2min+ vs. 6min+ Working on debian-stretch in the bibisect-42max repository, I see three clusters of times taken to save output1 as .pdf: 1 minute plus, 2 minutes plus, and 6 minutes plus. The attacment has the tail of two bibisect runs with each of the two longer times deemed "bad". In summary ... commit s-h timed -------- -------- ------------------------------------------- 4.2max oldest b3c6cf28 a2c9d4f8 1:24.20 other 1min+ 1:33.47, 1:45.70, 1:42.30, 1:43.48, 1:43.62 last 1min+ 60a00257 39fee18a 1:48.24 first 2min+ 67bcc9a7 9bb96049 2:14.26 other 2min+ 2:18.22, 2:14.43, 2:14.11, 2:13.31, 2:20.05, 2:15.88, 2:17.75, 2:13.12, 2:07.89, 2:08.61, 2:07.54, 2:13.37, 2:08.64, 2:31.38, 2:26.98, 2:49.21, 2:26.73 last 2min+ f5673efd 284a03b4 2:33.12 first 6min+ 4904c61a 03e73d57 7:13.50 other 6min+ 7:12.56, 6:37.15, 7:03.06, 6:54.41 4.2max latest 7:08.44, 7:25.32 The first commit taking more than two minutes is ... commit 67bcc9a72ab4681cae229cd04726c721259cabe7 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 18:27:36 2015 +0800 source-hash-9bb96049addebd8907854730713d8a3f5f033e34 commit 9bb96049addebd8907854730713d8a3f5f033e34 Author: Armin Le Grand <alg@apache.org> AuthorDate: Wed Jan 23 13:27:50 2013 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Fri Jun 14 16:00:13 2013 +0100 Resolves: #i121534# Reintegrating changes for rotated bitmap support (cherry picked from commit b2cc0de3fc9adee90787ca760e86869f9255b380) Conflicts: canvas/source/vcl/spritecanvashelper.cxx drawinglayer/Library_drawinglayer.mk drawinglayer/source/processor2d/vclhelperbitmaprender.cxx drawinglayer/source/processor2d/vclhelperbitmaprender.hxx drawinglayer/source/processor2d/vclhelperbitmaptransform.cxx drawinglayer/source/processor2d/vclhelperbitmaptransform.hxx drawinglayer/source/processor2d/vclprocessor2d.cxx officecfg/registry/schema/org/openoffice/Office/Draw.xcs svx/source/svdraw/svdograf.cxx vcl/aqua/source/gdi/salgdi.cxx vcl/inc/aqua/salgdi.h vcl/inc/os2/salgdi.h vcl/inc/salgdi.hxx vcl/inc/unx/pspgraphics.h vcl/inc/vcl/bitmapex.hxx vcl/inc/vcl/outdev.hxx vcl/inc/vcl/salbtype.hxx vcl/os2/source/gdi/salgdi2.cxx vcl/source/gdi/bitmapex.cxx vcl/source/gdi/outdev2.cxx vcl/source/gdi/salgdilayout.cxx vcl/source/gdi/salmisc.cxx vcl/unx/generic/gdi/pspgraphics.cxx vcl/unx/generic/gdi/salgdi2.cxx vcl/unx/headless/svpgdi.cxx vcl/unx/headless/svpgdi.hxx vcl/unx/headless/svppspgraphics.cxx vcl/unx/headless/svppspgraphics.hxx vcl/win/source/gdi/salbmp.cxx vcl/win/source/gdi/salgdi.cxx vcl/win/source/gdi/salgdi3.cxx vcl/win/source/gdi/salgdi_gdiplus.cxx vcl/win/source/gdi/winlayout.cxx Change-Id: I871d1d107b019758f3913e5eb63bc9bc0ba403fd Do not name unused arguments to prevent compiler warnings. (cherry picked from commit f3118889a0cd941f193e9b6557c0792015d77a34) Change-Id: I482d1f96d695c7bf9912ec464bb39e7fdd14adef Related: #i121534# fix graphite-enabled windows build (cherry picked from commit c90a6ca92b1239d01a2892e15488e4a183a88b1a) Conflicts: vcl/win/source/gdi/winlayout.cxx Change-Id: I95fd41ad6f7187f34ba9474674a471fb4fc65314 and the first commit taking more than 6 minutes is (rewrapped) ... commit 4904c61a99b2cd68a35535381d85e1f32192eab4 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 20:39:11 2015 +0800 source-hash-03e73d57f1bf7da4f4a19ae1cff9c104e8fedd5e commit 03e73d57f1bf7da4f4a19ae1cff9c104e8fedd5e Author: Armin Le Grand <alg@apache.org> AuthorDate: Wed Aug 28 12:23:58 2013 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Aug 28 15:37:07 2013 +0100 Resolves: #i122923# optimize place to add alpha to bitmaps which need rotation (cherry picked from commit 2178fea0941c4abb624ecddf2453f670ba68878f) Change-Id: Ib83d10bcd2d0950fbb8afe8894caa9c0b60e6a5d I am removing keyword bibisectRequest and setting bibisected and bisected.
Armin: what do you think?
Created attachment 133837 [details] Callgrind output from 5.5, exporting output1.pdf Arch Linux 64-bit, KDE Plasma 5 Version: 5.5.0.0.alpha0+ Build ID: c855400e9686ddd8bcba5691393f839f6f52c966 CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on June 2nd 2017
Adding Cc: to Armin Le Grand
@buovjaga, Xisco: Looks as if Matthew changed stuff in the graphics stack, esp. dealing with transparency stuff in RGBA bitmaps (BitmapEx). I have no idea what this tried to improve, but that is potentially a slow op that might have got much slower by the change.
(In reply to Armin Le Grand (CIB) from comment #13) > @buovjaga, Xisco: Looks as if Matthew changed stuff in the graphics stack, > esp. dealing with transparency stuff in RGBA bitmaps (BitmapEx). I have no > idea what this tried to improve, but that is potentially a slow op that > might have got much slower by the change. Matthew just compiled the bibisect repo. The changes were made by you for AOO and Caolán merged them :)
@buovjaga: Ah yes, sorry - have to re-check. Need to get used to that stuff again...
Checked commit 03e73d57f1bf7da4f4a19ae1cff9c104e8fedd5e, that one moves code to a place where better decisions can be made then before, e.g. if transparency is needed (rotated/sheared) at all and where the target resolution is known. For metafile and printer this is limited due to ressources and pixel stuff already. This means that 6x is due to enhancing quality in metafiles which could be pretty bad before. Of course PDF could do better with rotated/sheared images, but as long as PDF export is based on Metafile and not on primitives that info is just not transportable in Metafiles and thus cannot be used in PDF exports. Only thing doable now would be to 'play' with the fMaximumArea limitation on the cost of getting bad edges again in PDF exports (and reports for that).
(In reply to Armin Le Grand (CIB) from comment #16) > Only thing doable now would be to 'play' with the fMaximumArea limitation on > the cost of getting bad edges again in PDF exports (and reports for that). Yep, let's just wait for primitives instead of shooting ourselves in the foot. Closing
*** Bug 108038 has been marked as a duplicate of this bug. ***
@Buovjaga Hi Buovjaga ! Please can you, kindly, explain to me what you mean by changing bug state to "RESOLVED WONTFIX" ? Do you mean by that, you will never fix it in the future or you mean that you will wait for some time before trying to fix it ? If you will never fix this bug, then this will simply mean that L.O Draw is almost useless tool for editing PDF because it will be un-practical to use it to edit PDF file more than 10 or 15 pages !! Any PDF book with numerous , say 100 0r 500, will be hung & program freeze at saving ! Please your kind explanation.
(In reply to yousifjkadom from comment #19) > @Buovjaga > > Hi Buovjaga ! > > Please can you, kindly, explain to me what you mean by changing bug state to > "RESOLVED WONTFIX" ? > > Do you mean by that, you will never fix it in the future or you mean that > you will wait for some time before trying to fix it ? > > If you will never fix this bug, then this will simply mean that L.O Draw is > almost useless tool for editing PDF because it will be un-practical to use > it to edit PDF file more than 10 or 15 pages !! Any PDF book with numerous , > say 100 0r 500, will be hung & program freeze at saving ! > > Please your kind explanation. If the code changes that cause this problem are reverted, we will get many other problems instead. There has to be a more fundamental fix: moving to primitives instead of metafiles.