In creation of an article for my club's newsletter, I'm having constant "Read-Error" problems while trying to load the JPGs I have embedded into the article. Because the newsletter editor uses MS Office, I have to offer the file in the DOCX format. Rather than creating the article in the native LO writer format and then saving it as a DOCX when its done, I thought I'd be able to save the file as the DOCX from the start... too often I've sent the editor the ODF version instead of the DOCX version. The first part of the article I had only one image which caused this problem. In the second part, only the very first image loads, while ALL the rest show up as Read-Error boxes. I've uploaded the article's file to my google drive account, the file is 13megs: https://docs.google.com/file/d/0B0q8pfT0-of-S1VpY1BCdzNGLTQ/edit?usp=sharing
Hi JD Thanks for reporting. I try to make the summary a bit more to the point. Hope that is fine for you as I do it now. Also I set the importance lower - after all there is a work around (though you often forget to use it.) Sorry that (for now) I do not try to reproduce the problem (maybe someone else does this). But I can well imagine that it happens.
Okay, since you didn't bother to tell me what this work around is, I re-upped the level of the bug. Saying there is a work around and then not telling what it is doesn't do any good.
(In reply to comment #0) > ... too often I've sent the > editor the ODF version instead of the DOCX version. Not forgetting how to send the file, is the work around. Sorry, I thought that would have been clear ;)
That's like the work around Ford had for the Pinto... don't crash it! Its not a work around, its a kluge. The point is LO should not claim to work with the DOCX format if it can't handle the calls needed for the format. On your same train of thought, I should just get him to use LibreOffice instead of MS Office. I'm NOT amused.
I've played with the document linked in the Description. Loading in LO 4.1.0.1: First image displays fine, others show a reading error. BUT, opening the same document with Word does show the same behavior. Also Word gives a warning that the document cannot be opened because there are issues with the content of the file. So concerning opening the file: it seems LO behaves correct. From what I understand those images are fine in the original odf file. J.D.: Could you please attach the original odf file so we can further test this. It seems the problem is introduced during the export to docx. After providing that file please set this bug back to "UNCONFIRMED". Thanks, james
James, I can't share the original LO format file because there is none. I created & edited the file as a docx. I am now recreating the documents from scratch in the native Open format, with hopes that doing that will allow me to then convert to docx at the end. Not trying to be a jerk, but if there is a file format error, then LO put it there. I ran a disk check twice to be sure that it wasn't a bad sector, and until I can get a copy of SpinRite, thats all I can do. By the way, thanks for checking it in MSO. Running only LO can have its problems.
On pc Debian x86-64 with master sources updated today, I reproduced the problem. I can see first image on the first page (a big old train) and the images of the last page (kids + old train again). I noticed these console logs: warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:i18nlangtag:25072:1:i18nlangtag/source/languagetag/languagetag.cxx:771: LanguageTag::getRegionFromLangtag: pRegionT==NULL warn:writerfilter:25072:1:writerfilter/source/dmapper/GraphicImport.cxx:1564: failed. Message :GraphicCrop warn:writerfilter:25072:1:writerfilter/source/dmapper/GraphicImport.cxx:1564: failed. Message :GraphicCrop warn:writerfilter:25072:1:writerfilter/source/dmapper/GraphicImport.cxx:1564: failed. Message :GraphicCrop warn:writerfilter:25072:1:writerfilter/source/dmapper/GraphicImport.cxx:1564: failed. Message :GraphicCrop warn:legacy.osl:25072:1:oox/source/helper/storagebase.cxx:71: StorageBase::StorageBase - missing base input stream warn:sfx2.control:25072:1:sfx2/source/control/dispatch.cxx:1465: Childwindow slot missing: 10365 warn:sfx2.control:25072:1:sfx2/source/control/dispatch.cxx:1465: Childwindow slot missing: 10365 warn:sfx2.control:25072:1:sfx2/source/control/dispatch.cxx:1465: Childwindow slot missing: 10365 warn:legacy.osl:25072:1:sw/inc/swrect.hxx:299: SVRect() without Width or Height
Created attachment 81510 [details] bt concerning "Missing base input stream" I don't know if it can help for the debug
Michael: any idea how to dig on this tracker or who may help? I attached some logs and a bt but am quite stuck.
OSX 10.10.3 and LO Version: 4.5.0.0.alpha0+ Build ID: 4e0d2fcdda3f639a05118b25ef99d8a4848302ce TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-04-13_06:20:15 Locale: de_ opens the file as expected. Word 15.8 on OSX complains about a damaged file suggesting that were dealing with a broken document to begin with. J.D. who ever put the error into the docx file, have you manage to re-create this document in a odt file? If so, could you attach that file? Also are you still seeing issues after storing as docx using that newly created file? NEEDINFO, after providing the requesting info please reset the bug to NEW.
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 INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO 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! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-10-14
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID 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 Warm Regards, QA Team This INVALID Message was generated on: 2016-05-09