Bug 104998 - PDF images disappear after a while in LO 5.3
Summary: PDF images disappear after a while in LO 5.3
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.0.beta2
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, dataLoss, regression
: 106791 113459 (view as bug list)
Depends on:
Blocks: PDF-Import-Writer
  Show dependency treegraph
 
Reported: 2016-12-30 11:40 UTC by deepjungle.maca
Modified: 2018-02-12 13:02 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (3.64 MB, application/3dr)
2016-12-30 15:33 UTC, Telesto
Details
Example with disappeared PDF image. Figure 1 in test.odt must have image as in test_image.pdf. (16.17 KB, application/zip)
2017-05-29 13:52 UTC, petr_aleksandrov
Details
Bibisect log (2.90 KB, text/plain)
2017-10-25 15:49 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description deepjungle.maca 2016-12-30 11:40:00 UTC
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.
Comment 1 deepjungle.maca 2016-12-30 12:22:16 UTC
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.
Comment 2 Telesto 2016-12-30 15:33:42 UTC
Created attachment 130034 [details]
Example file
Comment 3 Telesto 2016-12-30 15:54:44 UTC
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
Comment 4 deepjungle.maca 2017-02-07 01:36:27 UTC
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.
Comment 5 Xisco Faulí 2017-03-28 07:17:42 UTC
*** Bug 106791 has been marked as a duplicate of this bug. ***
Comment 6 emmanuel.klinger 2017-03-28 07:32:50 UTC
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.
Comment 7 petr_aleksandrov 2017-05-29 13:52:57 UTC
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.
Comment 8 Paul Menzel 2017-08-07 13:04:58 UTC
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.
Comment 9 Paul Menzel 2017-08-07 13:06:49 UTC
(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.
Comment 10 emmanuel.klinger 2017-08-07 13:08:03 UTC
I also have this bug in 5.4. I also see now a flickering error message inside the image frames.
Comment 11 Michael Stahl (CIB) 2017-08-07 13:26:53 UTC
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.
Comment 12 Paul Menzel 2017-08-07 13:30:46 UTC
(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?
Comment 13 Michael Stahl (CIB) 2017-08-07 13:33:04 UTC
(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 :)
Comment 14 emmanuel.klinger 2017-08-07 13:33:54 UTC
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.
Comment 15 Stephan van den Akker 2017-08-07 13:58:04 UTC
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
Comment 16 Stephan van den Akker 2017-08-08 08:44:47 UTC
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.
Comment 17 bartolom 2017-08-17 08:26:13 UTC
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.
Comment 18 Telesto 2017-10-25 15:47:08 UTC
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
Comment 19 Telesto 2017-10-25 15:49:40 UTC
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)
Comment 20 V Stuart Foote 2017-10-26 14:50:30 UTC
*** Bug 113459 has been marked as a duplicate of this bug. ***
Comment 21 V Stuart Foote 2017-10-26 14:52:57 UTC
Good STR and test doc (attachment 137298 [details]) in dup bug 113459
Comment 22 Xisco Faulí 2017-10-26 15:16:23 UTC
Adding Cc: to Miklos Vajna based on comment 19
Comment 23 Miklos Vajna 2017-10-26 15:31:02 UTC
Is it possible that this is a duplicate of bug 108748 (or the other way around)?
Comment 24 Miklos Vajna 2017-11-07 10:51:56 UTC
Asking this especially as that has been just fixed on master.
Comment 25 Xisco Faulí 2017-11-07 14:18:17 UTC
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.
Comment 26 Stephan van den Akker 2017-11-07 23:13:31 UTC
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)
Comment 27 sam tygier 2017-11-08 08:37:04 UTC
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.
Comment 28 Paul Menzel 2018-02-12 12:05:38 UTC
Does anybody now, if this was backported to LibreOffice 5.4?
Comment 29 Buovjaga 2018-02-12 12:15:51 UTC
(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
Comment 30 Paul Menzel 2018-02-12 12:18:35 UTC
(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.
Comment 31 V Stuart Foote 2018-02-12 13:02:45 UTC
(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.