It started with version 22.214.171.124 in win 10 x64 and continues to the 126.96.36.199
Loss of images in the document.
I am working on a long document, It started with text of 85 pages. I started to add png photos. About 30 photos,were included, anchored to page, to paragraph, to character. Some with borders, and the majority with test written around them.
despite the difficulty on positioning, sticking mainly to the right side, not moving to the correct set position, they disappeared 4 times in the updated versions of the document as progressing. The relevant box in settings, is always checked, but the file from 18 mb was reduced to 500 kb, only with the frames of the photos appearing, but not including the photos.At least I did not have to import and re-calibrate each photo manually!I had to re-enter the photos using for comparison an older file, but with not the same full content!
This happened 4 times.
I had the same problem with impress as well. At an international conference in Germany, where I was also suggesting the use of open source software, all my photos disappeared from my presentation. Only blank border lines, but no photos, I had to do the same work 3 times, including the legends of the photos that were lost!
I see on the net that a lot of people have the same problem for quite sometime. As the documents are sheared with other colleagues, they also loose photos. using other software, but also the photos are changing positions, making it very hard to use Libreoffice. Already I am asked to use the MS Office, for safety of not repeating the same job already done
The problem must be fixed as soon as possible. Otherwise a turn to the stupid Office will not be avoided!
Michael: Could it be related to tdf#47148?
BTW, is there some project (like vclptr) to refactor images management?
Indeed, there are still many bugs linked to images.
So if it's not already the case, it should be an high priority.
Badfully, I'm not C++ expert but if I can contribute with janitorial/simple prepare work, no problem.
Hi Julien - so - yes, in a nut-shell we need a similar work to the VclPtr cleanup here - so we have hard references on images instead of the current truck-load of lame heuristics and workarounds - with all the fragility they bring =)
For my part, the image loss problems I experienced in the past around impress are gone in ~5.0+ I think - so I'm interested to see a more recent duplicate here.
Bill - sorry about that; and thanks for filing - this is an inherited legacy issue we need to nail.
I have used a hex inspector, and I have observed that the corresponding image file is corrupted. It is full of secuences like 00 FF 00 FF... or 33 66 99 CC FF."
@Meeks, @Julien: Setting this to NEEDINFO so its no longer unconfirmed, so please close if needed.
This is un-related to VclPtr. We -need- a VclPtr -like- solution to this, but it is certainly not related; we already have a tracker for the mis-designed image lifecycle mess here; lets stick with that one.
Bill - do you have any way to reproduce this ? we need concrete steps to do that - since it is really unclear how this happens and short of large-scale re-work of the whole image handling code, it would be nice to isolate and fix just this issue.
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker
Meeks said this should be reopened and that there is a TDF tender set to fix this issue.
I found this bug report while searching for possible solutions to images disappearing in multiple documents (Draw, Writer) in recent months. Currently I am using LibreOffice 188.8.131.52 (x64) on Windows 10. It is very discouraging to open up a document and find broken links to images. On multiple occasions it has taken an hour or more of work re-inserting and re-creating images to get back to where the document is usable again. An inspection of the document renamed as a zip file shows images still existing inside the document in the Pictures directory.
Sorry for the loss - Tomaz is actively working on this even now =) and no doubt watching this tracker carefully; my hope is to close all of the bugs there when that work is done but ... lets see ;-)
Is this bug here the same as bug 98686, which has now been marked fixed due to the image handling rework also mentioned here in comment 9?
(In reply to Michael Weghorn from comment #12)
> Is this bug here the same as bug 98686, which has now been marked fixed due
> to the image handling rework also mentioned here in comment 9?
Probably, so Bill and Peter might test with version 6.2.0.
Since version 6.2, I have not encountered the same problem
I therefore consider the problem solved
Thank you all
Fantastic. Tweaking status to WFM.
Recently I have been using the 6.1 series and yesterday updated to 184.108.40.206. Spot checks using 220.127.116.11 of some files that previously gave me trouble did not turn up any loss of graphics. I loaded the files and scrolled through the pages looking for broken image links. I made a few edits and went through multiple save-load cycles. Based on relatively limited testing I cannot prove that the problem is solved, but I am encouraged.
Thanks for testing it Peter ! =)