| Summary: | FILEOPEN Read error with images (large..) in DOCX file | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | J.D. <jgallaway81> |
| Component: | Writer | Assignee: | Cao Cuong Ngo <cao.cuong.ngo> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | CC: | cno, michael.meeks, serval2412 |
| Version: | 4.0.0.3 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Windows (All) | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=65765 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | bt concerning "Missing base input stream" | ||
|
Description
J.D.
2013-06-23 20:07:46 UTC
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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.