Saved embedded objects (e.g., images, spreadsheets) are saved with as part of an .odt file and should appear when the file is opened in LibreOffice. However, even across after a restart the current LibreOffice Write fails to open with these objects. To reproduce: 1. Start LibreOffice Writer 2. Open a file previously saved with embedded images (LO 7.0.2 or earlier) 3. Document will simply show the frames for "image" and/or "object" This failure happened with a file I last saved on 19/11/20. Testing with the Appimage of LO 7.0.3.1, the file opened correctly.
Thank you for reporting this, and sorry for the inconvenience it has caused you. 'embedded' is ambiguous. I imagine you are not talking simply about a document which contains images (which I have tested to work with libreoffice-writer-7.0.3.1-1.mga8), but something more complicated; and there is more than one way. Can you be more exact about what technique you are using, so we can try the same sort of thing? I doubt that it would be possible to attach an example to the bug. > Testing with the Appimage of LO 7.0.3.1, the file opened correctly Hmmm.
CC: (none) => lewyssmith
Created attachment 12011 [details] Screenshot of document with text eliminated This screen shot shows the document as it appears, except with text removed. Two images, one in a table, and an object, which is actually a LO spreadsheet that can be edited in situ. As shown, even the simple images (as I recall both jpg) are not showing. This is on a fully up-to-date Cauldron system with Enlightenment DE, mostly Gtk apps. I did ask on the LO users list and Italo responded that there had been no significant changes that should have caused this. I just checked java and even the appimage uses Mageia's openjdk, defaulting to 11. Using the Mageia LO package with the older openjdk yields the same results.
Just to eliminate another variable, I switched over to an IceWM session ... with the same results.
My apologies, I should have run LO from the terminal. If I run the appimage from the terminal and open the file there is no error. However, running with the Mageia package I get: [aguador@localhost ~]$ libreoffice SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. Here is the information from the link: Failed to load class org.slf4j.impl.StaticLoggerBinder This warning message is reported when the org.slf4j.impl.StaticLoggerBinder class could not be loaded into memory. This happens when no appropriate SLF4J binding could be found on the class path. Placing one (and only one) of slf4j-nop.jar slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar on the class path should solve the problem. Note that slf4j-api versions 2.0.x and later use the ServiceLoader mechanism. Backends such as logback 1.3 and later which target slf4j-api 2.x, do not ship with org.slf4j.impl.StaticLoggerBinder. If you place a logging backend which targets slf4j-api 2.0.x, you need slf4j-api-2.x.jar on the classpath. See also relevant faq entry. since 1.6.0 As of SLF4J version 1.6, in the absence of a binding, SLF4J will default to a no-operation (NOP) logger implementation. If you are responsible for packaging an application and do not care about logging, then placing slf4j-nop.jar on the class path of your application will get rid of this warning message. Note that embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J's purpose.
OK, I eliminated another variable I forgot to mention: language. My system is Es_es, so, having seen the post today about langpack & font issues, I started LO in terminal with LC_ALL=C. The problem is still there even without the language pack.
Just updated to 7.0.3.1-2 and the file still does not open properly.
OK. Can you provide here such .odt file with embedded objects as you are trying to display? Please send this on a cloud file service of your choice and provide here a link. Please remove any sensitive information.
CC: (none) => ouaurelien
Sorry for the noise, I forget that LO profiles become corrupted (it seems more frequently these days, but still). This should have occurred to me when the problem could not be reproduced. Now rebuilding my profile . . . but everything works. Again apologies.
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME
Sometimes this is the culprit: user profile. Again, Cauldron should not used in production environment.