1. Insert a PDF image (it can be any one) 2. Write some long text and scroll down to hide the PDF image (or paste some long text) 3. After a while, the PDF images disappear in the whole document If the document is saved after disappearing the PDF images, re-opened document won't contain the PDF images. OpenGL or hardware acceleration is disabled. macOS is 10.12.2.
It looks somehow it's affected by memory settings. (I mean LO -> Preferences -> Memory). If I change it from 180 MB (by default) to 768 MB (for example). It seems to be more stable, and PDF images disappearing is less common. But who knows.
Created attachment 130034 [details] Example file
I can reproduce it with Windows (but I have forced it) Version: 5.4.0.0.alpha0+ Build ID: a7c51323b7343f82b5aea6098f5d5e31a8bad0e9 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-29_23:35:20 Locale: nl-NL (nl_NL); Calc: CL Steps to reproduce: 1. Reduce memory settings in Tools -> Options -> LibreOffice(Dev) -> Memory I used: Image Cache settings: 30MB, 12MB, 00:02; Cache for Inserted object: 2 2. Set AutoRecovery information to 1 minute (not sure it's relevant) 3. Open attachment 130034 [details] (first two images are PDF) 4. Enable Multi-Page view 5. Scroll to the bottom. 6. Add or delete something (ADD for example ABC to the last page) 6. Wait a minute 7. Scroll up. 8. Image on the first page is missing 9. Scroll down 10. Scroll up again; second image disappears
Still happens in LO 5.3.0.3. I can't believe LO 5.3 has been released without fixing this issue :( The ability to insert a PDF image is great and very useful, but it's a bit weird when the image disappear after a while.
*** Bug 106791 has been marked as a duplicate of this bug. ***
I'm having the same problem. This is really severe. Being able to embed PDF images would be such a nice feature. However, this bug makes it completely useless.
Created attachment 133694 [details] Example with disappeared PDF image. Figure 1 in test.odt must have image as in test_image.pdf. I also have encountered this bug. I have attached an ODT file with a pasted figure from a bigger document. On this figure a PDF image disappeared.
I was able to reproduce the issue. In my case, with LibreOffice 5.4.0.3, *Read Error* is written in the image frame though.
(In reply to Paul Menzel from comment #8) > I was able to reproduce the issue. In my case, with LibreOffice 5.4.0.3, > *Read Error* is written in the image frame though. Saving the file, and opening it again, the image frames are gone too.
I also have this bug in 5.4. I also see now a flickering error message inside the image frames.
it would be interesting to know if this problem is specific to PDF images? i haven't heard much about such problems with image formats other than PDF for recent versions, since ztamas did some work in the cache. note that exporting to ODF is a good test for SVG and PDF images because it will create a preview bitmap PNG for every SVG/PDF image, so they are all swapped in and (if the cache is not large enough) out again.
(In reply to Michael Stahl from comment #11) > it would be interesting to know if this problem is specific to PDF images? If I remember the other comments correctly, it isn’t reproducible with PNG images. > i haven't heard much about such problems with image formats other > than PDF for recent versions, since ztamas did some work in the cache. > > note that exporting to ODF is a good test for SVG and PDF images > because it will create a preview bitmap PNG for every SVG/PDF > image, so they are all swapped in and (if the cache is not > large enough) out again. Do you really mean “exporting to ODF”? If yes, how can I do that?
(In reply to Paul Menzel from comment #12) > Do you really mean “exporting to ODF”? If yes, how can I do that? yes, i mean saving to the default file format :)
Not sure if this helps. I observed that while the PDF images are still visible, the ODT archive contains both, the PDF and a PNG version of the respective image. Once the images are gone, they are also gone from the archive. I checked this by unzipping the ODT files.
I can reproduce this on: Version: 6.0.0.0.alpha0+ Build ID: ddf8d9a150e3e1725de65577c48d47918b4b11a8 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; Locale: en-GB (en_GB.UTF-8); Calc: group
I can reproduce also in Impress in a new master build: Version: 6.0.0.0.alpha0+ Build ID: c0998d9481cd57560a4d549d760f0be9da510306 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; Locale: en-GB (en_GB.UTF-8); Calc: group Two imported PDF's become invisible on screen after approx. 10 minutes. An imported PNG image in the same document is still visible after approx. 1 hour. All images are still present under Pictures/*.png in the ODP file saved after the PDF images have become invisible on the screen. Opening the saved ODP file seems to solve the problem. The images don't become invisible anymore. In this regard LOdev seems behave different from the behaviour described in the OP.
Bug 108748 might be a variation of this. The main difference is that over there the "link" option is used when adding the PDF-Image.
Still repro with based on comment 3 Version: 6.0.0.0.alpha1+ Build ID: b17294826830e278d060c876cf4f94a9b4ec16cc CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-10-23_06:32:42 Locale: nl-NL (nl_NL); Calc: CL 1. Reduce memory settings in Tools -> Options -> LibreOffice(Dev) -> Memory I used: Image Cache settings: 30MB, 12MB, 00:02; Cache for Inserted object: 2 2. Open attachment 130034 [details] (first two images are PDF) 3. Save the file as 4. Scroll down 5. Scroll up again Or after bug 110448 with: /org.openoffice.Office.Common/Cache/GraphibManager/TotalCacheSize /org.openoffice.Office.Common/Cache/GraphibManager/ObjectCacheSize /org.openoffice.Office.Common/Cache/GraphibManager/ObjectReleaseTime /org.openoffice.Office.Common/Cache/DrawingEngine/OLE_Objects and this setting seems to depend on latter: /org.openoffice.Office.Common/Cache/Writer/OLE_Objects
Created attachment 137288 [details] Bibisect log I could bisect it - based on the steps in comment 18 - to: author Miklos Vajna <vmiklos@collabora.co.uk> 2016-06-27 12:27:25 (GMT) committer Miklos Vajna <vmiklos@collabora.co.uk> 2016-06-27 12:58:58 (GMT) commit d1c346ba848c54424d6ffa88df7a5ff6a3717430 (patch) tree 60ffde6fe1d369d610229e39a483ac51cc5da516 parent de243e8e134c8780e54ebe8402a8a930962852fc (diff) ODF import: add embedded pdf support The use-case is to have a .svm and .pdf alternative, need to pick .pdf from those. The test fails with any of the below commits reverted: - the xmloff part of this commit - fda68426374ed915783fd306c2f56463c757774a (ODT export: add embedded pdf support, 2016-06-27) - 878a860dff10bd91491d6c9f2f4e2308bfe4f0b2 (vcl: add initial PDF import-as-graphic filter, 2016-06-23)
*** Bug 113459 has been marked as a duplicate of this bug. ***
Good STR and test doc (attachment 137298 [details]) in dup bug 113459
Adding Cc: to Miklos Vajna based on comment 19
Is it possible that this is a duplicate of bug 108748 (or the other way around)?
Asking this especially as that has been just fixed on master.
Hi guys, Could someone test this issue with a master build including this commit http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a88795c1211c62277dc646e61c2ba8306febe37 made on 06-11-2017? You can download a master build from http://dev-builds.libreoffice.org/daily/master/ You can install it alongside the standard version.
PDF image doesn't seem to disappear any more. Tested in: Version: 6.0.0.0.alpha1+ Build ID: 6803f3ee3c9c8f2d52c73d79ec3d3d479d6539fb CPU threads: 8; OS: Linux 4.4; UI render: default; VCL: kde4; Locale: en-GB (en_GB.UTF-8); Calc: CL (fresh ./g pull -r and make on 07 November 2017, 23:00)
The the memory page has been removed from the options https://cgit.freedesktop.org/libreoffice/core/commit/?id=765398294b872d01fba5345a7aa65f310ff27868 . I have tried reducing them in the advanced options (assuming the units are bytes and seconds). With the commit before the 3a88795c1211c62277dc646e61c2ba8306febe37 i can reproduce easily with the example file. Version: 6.0.0.0.alpha1+ Build ID: a4b7c54ea83e354f3dae3165bd71989a796ed6bc CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.utf8); Calc: group Can reproduce bug Stepping to the commit mentioned, I can no longer reproduce. Looks like it is fixed (or at least does not trigger as fast). Version: 6.0.0.0.alpha1+ Build ID: 3a88795c1211c62277dc646e61c2ba8306febe37 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.utf8); Calc: group Also I'm not able to reproduce with current git: Version: 6.0.0.0.alpha1+ Build ID: 9b76fa7fc51f178382c14e9ad8b56549c335cbc1 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.utf8); Calc: group Can't reproduce bug. Thanks.
Does anybody now, if this was backported to LibreOffice 5.4?
(In reply to Paul Menzel from comment #28) > Does anybody now, if this was backported to LibreOffice 5.4? Bug 108748 only has a target:6.0.0
(In reply to Buovjaga from comment #29) > (In reply to Paul Menzel from comment #28) > > Does anybody now, if this was backported to LibreOffice 5.4? > > Bug 108748 only has a target:6.0.0 Thank you. It also effects LibreOffice 5.4, so it’d be great to have it fixed there too.
(In reply to Paul Menzel from comment #30) Unlikely. A fairly complex (i.e. risky) patch and 5.4 is nearing EOL, better to move to 6.0 and help verify it is truly a correct fix ready for use.