The code we've inherited that deals with image caching, swapping in, out, lifecycle management of images via strings, swapping in and out to documents etc. is broken beyond belief. This is a tracker bug to start aggregating these horrors.
Please consider https://bugs.freedesktop.org/show_bug.cgi?id=46447 It damages presentations containing images irreversibly. It happens for more than 80% of the presentation I do. It has been around for me for all 3.x versions (and maybe earlier ones).
Of course - any chance of some hunting through bugzilla to find any more instances of this sort of image-loss meta-problem ?
Is this metabug really a 3.5 MAB? E.g. are we expecting to kill it on the release branch or is this work that touches too much code to be really safely backported? Without deeper knowledge of the topic I would assume the second, and thus demote this from 3.5 MAB state.
Now with LibO 3.5.3 I just lost a frame and an image embedded in the page.
I have a Index entry in my frame (cadre in french) and I have note lost this entry. But I can't see this entry in this frame. I see this only in the table/index off entry.
Another instance of this may be: https://issues.apache.org/ooo/show_bug.cgi?id=105191
The many-megabyte leakage going on in bug#52433 are a particularly nice instance of this - where we have a leakage in place of a crash.
Bug 55312 seems to indicate that images end up as read errors when inserted before Writer has completed its document layout. Adding that to the blocks-list.
The code at: https://bugs.freedesktop.org/show_bug.cgi?id=33393#c37 Is almost certainly related to this.
*** Bug 67624 has been marked as a duplicate of this bug. ***
Work is ongoing on this in the feature/graphicobject branch ... thanks to Norbert for some great progress there during the conference: it now builds ;-) [ still a v. long way to go ].
it now build _and_ seems to pass the basic subsequent checks...
(In reply to comment #12) > it now build _and_ seems to pass the basic subsequent checks... Hmm :) If there is any build (or way to build) that we can test, pls let it know! thanks Norbert, Cor
(In reply to comment #13) > (In reply to comment #12) > > it now build _and_ seems to pass the basic subsequent checks... > > Hmm :) > > If there is any build (or way to build) that we can test, pls let it know! > thanks Norbert, > Cor Don't thanks me yet... make check still blow in few places... and more importantly graphics seems not to be displayed at all at this point so.... not quite there yet....
I have a document for which I can reproduce the image loss under 4.1.x - though it takes a longish series of: load .odt save .odt save .docx re-load save .odt save .docx reload (and the image is now lost) Hopefully that will help us get to a better understanding here of the writer issues.
The writer issue is/was supposedly fixed; and is only one of the issues. Long after that fix I'm still loosing images in impress - when loading and trying to edit together large slide decks. Nothing reproducible but ... horrible.
(In reply to comment #16) > The writer issue is/was supposedly fixed; and is only one of the issues. > Long after that fix I'm still loosing images in impress - when loading and > trying to edit together large slide decks. Nothing reproducible but ... > horrible. FWIW: someone contacted me with that very same problem. I could do the job by: - fully loading all slides in both applications (so in Normal/Edit view pgd through all the slides) - then in Sort view copy some 5, 6 slides per time and paste in the other presentation - and save after each paste So this sort of helps to ensure that all in memory copies of the presentations on screen have all the graphics ..
Cor - it sounds like your instructions are to avoid loosing the images ;-) but we're badly trying to find a repeatable example / set of slides where we can loose them =) does anyone have any repeatable steps from a fresh exit/re-start of LibreOffice ? we tend to only see the aftermath when the suite has got into a busted state after some (ill defined) usage.
More stupid stuff (from a performance perspective) from Impress - why does it take forever to save big slide-decks ? - it's -reading- and de-compressing all the images (but thankfully not re-compressing them all ;-).
*** Bug 80352 has been marked as a duplicate of this bug. ***
This seems to be a time bomb. see bug 73270. I was hit by this when switching from 4.2.x to 4.3.0 (For the moment I switched back). Not a good feeling to know that at your long documents (manuals for students, thesis, ...) suddenly some images might just vanish.
Wow - thanks for the link. Apparently, from: https://bugs.freedesktop.org/show_bug.cgi?id=73270#c10 We have a reproducer for a similar issue ! =)
Created attachment 102617 [details] extension with simple macro for importing whole series of images in one run in Writer document The attached adds a simple macro library 1) Start Writer document; then the macro dialog (macro 'StartInsertPictures') 2) Choose a folder with a lot of images .... OK The pictures will be placed one after another in the document. Might also stop working after 20, 30, ... images. See what this triggers in traces, debugging etc Good luck, Cor
Simple to reproduce case https://bugs.freedesktop.org/show_bug.cgi?id=52226#c41
Useful comment on role of autosave https://bugs.freedesktop.org/show_bug.cgi?id=46447#c85 Comment with summary of some of the cases https://bugs.freedesktop.org/show_bug.cgi?id=52226#c31 I've seen the problem recently with a writer document and a presentation. Not too complicated, both losing one of the images while editing. I've spend time and time to try to reproduce. Not.. As I've written somewhere else in one of the many occurrences of this problem: Knowing that there are various in memory copies of a document, and in Impress maybe related to various views (side panel, normal view, slide sorter, ..) it may be well possible that there is a problem in synchronising those copies. This is supported by some other comments too. This will help to _not_ reproduce the problem ;) ... but alas neither is a guaranty that it won't happen, nor does it help as a reliable solution to do reproduce it..
I've just been working on a odp existing file. Adding two pictures, working on the slide, and back to the pictures, they were gone !? It happens many times, but I can't reproduce. Problem starts with 4.2.5.1, and these evening with 4.2.6.1
@choffardet that looks like Bug 46447 which is already in the "Depends on" of this meta-bug. read the discussion over there.
@tommy27, yes, I've just read the bug description but yes, that is the same behaviour. But I'm working with OpenOffice since 1.9 beta and I'm regularly working with impress, and more, I never link my images. I've never see this bug since LO 4.2.5.1
linking a couple of the closed issues with commits to core/graphic/ndgrf.cxx and svdraw/svdograf.cxx, and svdpagv.cxx
(In reply to Cor Nouws from comment #23) > Created attachment 102617 [details] > extension with simple macro for importing whole series of images in one run > in Writer document Adapted for use in Impress and Writer https://bugs.freedesktop.org/show_bug.cgi?id=46447#c150
added a couple of relevant issues (Windows specific) writer and impress Bug 82465 - Permanent crashes in writer with images Bug 81378 - Permanent Crashes and Content Loss in Presentations ("Bad allocation" warning and crash)
I believe I wrote up some E-mail rant about using strings to reference images across the code left & right, instead of UNO references - which is spectacularly unhelpful (but I lost my rant). An image is a leaf-node, there is no real reason not to have a nice hard, rtl::Reference<> lifecycle for whatever wrapper we put around it (to lifecycle manage it even when it's not swapped in etc.) that I can see. I suspect we try to be too clever - rather than having a nice central image cache we copy images to in the file-system, and that something simpler and more robust with some very hard lifecycle around it would be rather better ;-)
Problem persists in Writer 5.1.1.3. on Windows. I just lost half the images from a 30 page document. They simply disappeared. This makes Writer unusable for creating documents with images.
Image handling is by far the biggest bummer in LO for me. I went over to write my stuff and add images only at the very end of the process. Image handling urgently needs some attention
If someone reproduced the bug and built LO from source, could you please tell us the tag/commit ID and autogen flags? I can't reproduce it on Fedora 24 x86_64 with LO 5.2.2.2 and these flags: --enable-icecream --with-parallelism=64 --with-gcc-home=/usr/libexec/icecc/ --enable-werror --enable-debug --with-jdk-home=/mnt/jvm-ramdisk/java-1.8.0-openjdk-1.8.0.111-1.b16.fc24.x86_64/
(In reply to Dimitri Bouron from comment #35) > If someone reproduced the bug and built LO from source, could you please > tell us the tag/commit ID and autogen flags? > > I can't reproduce it on Fedora 24 x86_64 with LO 5.2.2.2 and these flags: > --enable-icecream > --with-parallelism=64 > --with-gcc-home=/usr/libexec/icecc/ > --enable-werror > --enable-debug > --with-jdk-home=/mnt/jvm-ramdisk/java-1.8.0-openjdk-1.8.0.111-1.b16.fc24. > x86_64/ Here is the configure line used for LibreOffice 5.4.0.3. ``` $ configure --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --sysconfdir=/etc --sharedstatedir=/var --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --datarootdir=/usr/share --datadir=/usr/share --infodir=/usr/share/info --localedir=/usr/share/locale --mandir=/usr/share/man --docdir=/usr/share/doc/libreoffice --exec-prefix=/usr --with-lang=de --with-help --with-jdk-home=/usr/local/java --with-ant-home=/package/mariux64/ant --without-doxygen --without-junit --disable-dconf --disable-epm --disable-odk --enable-release-build --enable-python=internal --with-system-apr --with-system-cairo --with-system-curl --with-system-expat --with-system-harfbuzz --with-system-icu --with-system-jpeg --with-system-lcms2 --with-system-libatomic_ops --with-system-libpng --with-system-libxml --with-system-neon --with-system-nss --with-system-odbc --with-system-openldap --with-system-openssl --with-system-poppler --with-system-postgresql --with-system-serf --with-system-zlib ```
Tomaz - best to CC you here if you're working on this =)
'Images disappearing' might be connected with contents flow and wrapping management. Few days ago I had to reposition/resize images in my big doc (there weren't even that much of them). I touched something, and bang! 'half of the images were gone', just like in the cases guys here describe. However they weren't actually removed from the doc. Some of them somehow got scaled to the height of several points, and some of them got that wrapping option switched on, which allows other content (images) to be placed 'behind' them (in this doc I have the images placed in pairs in page-sized frames). Images which are anchored so that they 'contend' for the place on the same page, on which there's not enough place for both of them, may get placed/get their wrapping set weirdly. Maybe #118200 has some clues?...
Tomaz - seems to me that the image caching / management should no longer be utterly shambolic - just in need of various improvements =) I'd like to rename this tracker bug, and it would be good to poke the open tickets that we fixed to say: Fixed in 6.1 - please re-test there, or somesuch - at least the ones that shouldn't be there anymore. Can you do that in some spare cycles ? =) Thanks - Miklos - I think the load-time perf issue you fixed is also a child item here ...
There is bug 116280 already for the problems caused by the image handling rework. I've just added 2 problems (1 fixed, 1 in progress) to that tracker regarding performance.
Renaming, the majority of the problems are now solved with the work from Tomaz, see <https://blog.documentfoundation.org/blog/2018/06/19/image-handling-rework-for-libreoffice-collaboras-tender-results/>. Not closing yet, there are still a few problems remaining, see the unresolved dependent bugs.
The problem is still there in Draw and Impress (Debian Stretch) Version: 5.2.7.2 Build-ID: 1:5.2.7-1+deb9u4 CPU-Threads: 4; BS-Version: Linux 4.9; UI-Render: Standard; VCL: kde4; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Additional hint: I was using a clipart (png) and did some copy and paste of this clipart Maybe this was affecting the missing images. The images are embedded not linked. Not all of the copied images are lost (about 60% are lost) The problem occoured during creating the presentation.
Can I solve the visual glitch like I did with the https://ovo-game.com? It's quite annoying.
I advise contacting the right platform or program support channels for help if you're having trouble with picture caching. They will have access to the tools and knowledge you need to troubleshoot and fix the issue https://ovo-game.com
Great information! I will visit your site more often so I am updated. The ideas I gather from here cannot be paid with money. Thanks very much! https://pgeoutagemap.com