Created attachment 42354 [details] Read_Error_file Attaching file that exhibits the issue. I have manually remove over 22 graphics from the file (removing from content.xml, manifest.xml and pictures folder when unzipped). I had to do this manually due to the issue that when I resave the file, it no longer will exhibit this behavior. This behavior occurred originally without any manual editing of odt files, but is much more difficult to reproduce. This is a long-standing regression compared to OpenOffice.org Steps to reproduce: Download the file to the desktop (DO NOT OPEN DIRECTLY) Open the file Set autorecovery on and to 1 minute. Change/Add text on the first page (delete 09) Wait at least one minute, maybe two Note the Read-Error Message For the data loss part, simply save the file, then reopen. This bug has been reported elsewhere: https://bugs.launchpad.net/openoffice/+bug/157249 https://bugzilla.novell.com/show_bug.cgi?id=440795
I see the effect with "LibreOffice 3.3.0 RC4 - WIN7 Home Premium (64bit) German UI [OOO330m19 (build 6 / tag 3.3.0.4)]". The question is what we can do, currently it seems to be a damaged document causing some problems. The effect seems to disappear when I copy / paste all contents to a new WRITER document, but I also was not able to reproduce the problem with the original document in further tests. @Bryan Quigley: Please contribute information concerning your Platform and OS! Any chance to reproduce
I believe the file was originally created on Ubuntu 9.04 or 9.10 and the corresponding version of OpenOffice, but I am not entirely sure.
Once you save the file, the issue will no longer reappear reliably. The method I used to make this file, was the best I could do at making it easy to reproduce the effect.
Hi. I had this in OO a year or so ago, think I filed a bug, can't remember. I have a feeling it related to EPS images in my case and then images just kept disappearing. What was happening was that the linking was damaged. I.e after the the save when the image was read-error I could go into the odt file and the image was still there, what had broken was the reference to the image.
I can reproduce with LibO 3.4rc2. Why is the severity "normal" only? Dataloss is pretty critical.
(In reply to comment #5) > I can reproduce With what documents?
> Why is the severity "normal" only? Because the severity field is fairly meaningless here, as anybody can change it.
(In reply to comment #6) > With what documents? With the document attached to this bug, as well as some of my own documents used at work.
I have this also - and have had it with several versions of OOo / LO. I can't say exactly how it happens, but I did most of my work on a linux box, exchanging documents with Windows users I begged and finnally convinced to download LO. Yey very often when email a version back and forth - this would happen. Currently I am on a mac with LibreOffice 3.4.1 (Build:103) and it still happens. My collaborators does not complain about it, so I wonder if it is a *nix thing. I really hope this will get some attention. Please tell me how I can help (technical bugfixing skillz = zero)
I am having the same problem with Read Error replacing my graphics in LO Writer 3.4.4 (build 402) since switching to LO. I am using native ODT format and occurs with several of my ODT docs. The images are actually lost from the data, 8 MB file becomes 1 MB file. Documents were originally created in OO. We did not have the problem until moving to LO 3.3. I had hoped that 3.4.4 would resolve this significant issue. Initially we thought this was related to errors caused by MAC users. We did some testing and opened the file under Mac LO 3.4.4, saved, closed, then opened in the same version with Windows 7 LO. The images were present, then at some point they were replaced with Read Error. Mac user does not have the same problem. This error was not seen when alternately opening OO files between Mac and Windows. Error occurs whether files are on my local Windows 7 machine or on the network drive. My testing shows that corruption occurs during autosave. Manually saving the file first does not eliminate the error. I am able to reproduce the problem easily. Eugene
We spent a few hours going back and forth between Windows and Mac, opening vulnerable LO files in Mac and Windows, pasting the content into new files, saving, using network and local file copies, and editing with autosave enabled and disabled. The Read Error for the images is associated with autosave and occurs under Windows and Mac regardless of the other variables. All of the images are png. We did find that a small png button that we placed during this testing was not lost, only the larger images. We edited a file in Lotus Symphony and brought it back into LO in Windows and the Read Error still occurred with Autosave. Older files from OO also experienced the Read Error with autosave. We have used OO for years to create user manuals, which contain many images and extensive use of styles. In addition to the image read error bug, we also found that when an image is inserted, the document view jumps to the bottom of the document. This is an undesirable characteristic that was introduced with LO, and not present in OO. IBM Lotus Symphony opens the ODT docs without error, but under Mac it only opens the files on our server as read-only. Symphony was stable; autosave worked correctly, and image insertion did not change the document view. However, Symphony does not seem to have the math component which we used for formula objects, although it did allow editing of existing math objects. Nevertheless, it is a very good replacement candidate for those looking to avoid the mentioned LO bugs. Corel does a poor job of opening ODT files, the formatting was completely lost. For now, we are reverting to OO 3.3.0 until compelled to make a change or these LO bugs are fixed. Eugene
Never seen this problem with whatever old files I use. So to be able to track down to the source of this partictular issue (some damaged file, as suggested in an earlier comment?), having a simple test document would be useful.
We experience the same problem in a mixed network environment. It seems that the error appears mostly (maybe only) when our Mac users edit the documents. We are using LO 3.3.2 on the Mac which connects by SMB to a Linux server. The documents are in ODT format and created with LO. This bug is very critical for us since it leads to data loss. However, it is difficult to give a file that reproduces the problem since you never know which image will disappear. Saving the document after getting the "Read Error" will lead to reduced file size as reported previously, corresponding to the amount of data in the lost image.
I also observed picture loss with an own document and Parallel Dev-Installation of "LibreOffice 3.5.0 Beta1 - WIN7 Home Premium (64bit) German UI [Build-ID: 7362ca8-b5a8e65-af86909-d471f98-61464c4] Windows_Release_Configuration 11-Dec-2011 06:51". Not 100% sure that autosave is the reason. Pictures will not reappear when I close and reopen the document. I will try to get a sample document from the confidential test document. "Bug 35631 - FILESAVE Images fail to show and are removed after autosave" might be a DUP
*** Bug 35631 has been marked as a duplicate of this bug. ***
Since disabling autosave and backup early this year I have not experienced this problem.
I sometimes see the effect, but until now I can't reproduce it in a reliable way. Simply opening a document and waiting (with 1 minute autosave interval) does not show the problem.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Related to "Bug 32461 - Graphics disappear from document" Inappropriate NEEDINFO reverted to NEW
I can confirm this bug too for both Windows and OSX version and it's also a quite annoing one.
*** Bug 45167 has been marked as a duplicate of this bug. ***
I hope that the description in Bug 45167 is helpful to reproduce the problem.
@ someone: pls try the description here: https://bugs.freedesktop.org/show_bug.cgi?id=45167#c0 I tried again, and after some various work and returning to the document, the images are los: read-error!
We are experiencing this bug very severely on OS X Lion and 3.5 version. All our templates are unusable because we are losing all logos and graphic elements put into them. This happens both on local files and files on SMB shares.
@Jakub Cerny Are you able to create a test kit that reliably reproduces the bug with definitively proper documents? @Michael: May be you can try to get some progress here? The bug is not easy to reproduce, but for those who suffer from it it's worse than hell. Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
(In reply to comment #25) > Are you able to create a test kit that reliably reproduces the bug with definitively proper documents? here (striked because duplicate, not because it's solved.) https://bugs.freedesktop.org/show_bug.cgi?id=45167#c0 Also see comment #23 in this issue.
Trying to update documentation while recording changes on 64-bit Fedora 16 using LO 3.5 release version. Some of the graphics showed the "read error". when I checked the new file, 12 of the 19 contained PNGs are simply gone. I mean they are missing from the internal picture directory.... and not too surprising, they are also not in the manifest. I looked at content.xml and found the frame should contain one of the missing images and it was simply not there.... completely gone. I will see if I can reproduce. On the plus side, I was tracking changes, so you can see everything that I did right up until the graphics went away!
Created attachment 57180 [details] File at the start of editing. I started editing this file, enabled change tracking..... And then started making changes.
Created attachment 57181 [details] File saved the moment the bug appeared.
I don't know if it is any help, but way back when I had this problem in OOO I looked into the files after the read error. First I noticed that the image file names in the zip file had changed, then a few saves later they disappeared from the zip file. It was as if the image file names got changed breaking the internal linking. I am pretty much over that bug now that I turn all auto-save and backup off.
Using Bryan's document, I am able to reproduce at will. Now if only I knew the code well enough to find the problem. I asked for help on the dev mailing list for some pointers as to where to look.
I reproduced the issue here - nasty. Reading the utterly badly designed GraphicManager for inspiration ... :-)
XML delta is: - <draw:image xlink:href="Pictures/200004AD0000475F000033B381B9C98F.svm" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> + <draw:image/>
with a dbgutil build I get this on autosave: warn:legacy.osl:32088:1:/data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:810: <SwGrfNode::_GetStreamForEmbedGrf(..)> - embedded graphic file not found! warn:legacy.osl:32088:1:/data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:475: Grafik kann nicht eingeswapt werden warn:legacy.osl:32088:1:/data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:810: <SwGrfNode::_GetStreamForEmbedGrf(..)> - embedded graphic file not found! warn:legacy.osl:32088:1:/data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:475: Grafik kann nicht eingeswapt werden Breakpoint 1, SwGrfNode::_GetStreamForEmbedGrf (this=0x9042af0, _refPics=..., _aStrmName="200004AD0000475F000033B367F3281F.svm") at /data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:810 810 OSL_FAIL( "<SwGrfNode::_GetStreamForEmbedGrf(..)> - embedded graphic file not found!" ); (gdb) l 805 uno::Reference < io::XStream > refStrm = _refPics->openStreamElement( _aStrmName, embed::ElementModes::READ ); 806 pStrm = utl::UcbStreamHelper::CreateStream( refStrm ); 807 } 808 else 809 { 810 OSL_FAIL( "<SwGrfNode::_GetStreamForEmbedGrf(..)> - embedded graphic file not found!" ); 811 } 812 } 813 814 return pStrm; (gdb) p _aStrmName $1 = "200004AD0000475F000033B367F3281F.svm" #0 SwGrfNode::_GetStreamForEmbedGrf (this=0x9042af0, _refPics=..., _aStrmName="200004AD0000475F000033B367F3281F.svm") at /data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:810 #1 0xad85ae45 in SwGrfNode::SwapIn (this=0x9042af0, bWaitForData=0 '\000') at /data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:452 #2 0xad72a7f2 in SwNoTxtFrm::PaintPicture (this=0x90525b8, pOut=0x8b18c0c, rGrfArea=...) at /data/opt/libreoffice/master/sw/source/core/doc/notxtfrm.cxx:869 #3 0xad728ccc in SwNoTxtFrm::Paint (this=0x90525b8, rRect=...) at /data/opt/libreoffice/master/sw/source/core/doc/notxtfrm.cxx:319 #4 0xad8deee1 in SwLayoutFrm::Paint (this=0x9052448, rRect=...) at /data/opt/libreoffice/master/sw/source/core/layout/paintfrm.cxx:3255 #5 0xad8e154e in SwFlyFrm::Paint (this=0x9052448, rRect=...) at /data/opt/libreoffice/master/sw/source/core/layout/paintfrm.cxx:3928 #6 0xad7bd326 in SwVirtFlyDrawObj::wrap_DoPaintObject (this=0x9052520) at /data/opt/libreoffice/master/sw/source/core/draw/dflyobj.cxx:533 #7 0xad7bc869 in drawinglayer::primitive2d::SwVirtFlyDrawObjPrimitive::get2DDecomposition (this=0x9400198, rViewInformation=...) at /data/opt/libreoffice/master/sw/source/core/draw/dflyobj.cxx:274 #8 0xb5c77067 in drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D(drawinglayer::primitive2d::BasePrimitive2D const&) () from /data/opt/OOInstall/program/libmergedlo.so #9 0xb5c64d8c in drawinglayer::processor2d::BaseProcessor2D::process(com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::graphic::XPrimitive2D> > const&) () from /data/opt/OOInstall/program/libmergedlo.so #10 0xb6654af5 in sdr::contact::ObjectContactOfPageView::DoProcessDisplay(sdr::contact::DisplayInfo&) () from /data/opt/OOInstall/program/libmergedlo.so #11 0xb6654c63 in sdr::contact::ObjectContactOfPageView::ProcessDisplay(sdr::contact::DisplayInfo&) () from /data/opt/OOInstall/program/libmergedlo.so #12 0xb667408c in SdrPageWindow::RedrawLayer(unsigned char const*, sdr::contact::ViewObjectContactRedirector*) const () from /data/opt/OOInstall/program/libmergedlo.so #13 0xb6715a94 in SdrPageView::DrawLayer(unsigned char, OutputDevice*, sdr::contact::ViewObjectContactRedirector*) const () from /data/opt/OOInstall/program/libmergedlo.so #14 0xadbb469f in SwViewImp::PaintLayer (this=0x9058548, _nLayerID=1 '\001', pPrintData=0x0, _pPageBackgrdColor=0xbfc465b4, _bIsPageRightToLeft= false, pRedirector=0xbfc465d0) at /data/opt/libreoffice/master/sw/source/core/view/vdraw.cxx:148 #15 0xad8de187 in SwRootFrm::Paint (this=0x9059920, rRect=..., pPrintData=0x0) at /data/opt/libreoffice/master/sw/source/core/layout/paintfrm.cxx:2992 #16 0xadbbd0e0 in ViewShell::Paint (this=0x9058390, rRect=...) at /data/opt/libreoffice/master/sw/source/core/view/viewsh.cxx:1678 #17 0xad6201da in SwCrsrShell::Paint (this=0x9058390, rRect=...) at /data/opt/libreoffice/master/sw/source/core/crsr/crsrsh.cxx:1165 #18 0xadd9fcbf in SwEditWin::Paint (this=0x903d7b8, rRect=...) at /data/opt/libreoffice/master/sw/source/ui/docvw/edtwin2.cxx:534 Seems the image ID got corrupted: some change in the SVM stream perhaps: (gdb) p GetGrfObj().GetUniqueID() $6 = "200004AD0000475F000033B 367F3281F" vs. Pictures/200004AD0000475F000033B3 81B9C98F.svm I guess [ spaces added to separate the image checksum at end of id ].
adding: --- a/sw/source/core/graphic/ndgrf.cxx +++ b/sw/source/core/graphic/ndgrf.cxx @@ -798,6 +798,13 @@ SvStream* SwGrfNode::_GetStreamForEmbedGrf( } } + fprintf( stderr, "look for '%s' %d\n", + rtl::OUStringToOString( _aStrmName, RTL_TEXTENCODING_UTF8 ).getStr(), + _refPics->hasByName( _aStrmName ) ); + + fprintf( stderr, "look for [200004AD0000475F000033B381B9C98F.svm] %d\n", + _refPics->hasByName( rtl::OUString::createFromAscii("200004AD0000475F000033B381B9C98F.svm" ) ) ); + // assure that graphic file exist in the storage. if ( _refPics->hasByName( _aStrmName ) && _refPics->isStreamElement( _aStrmName ) ) Shows that it is indeed the 2nd autosave that fails, and/or the first autosave that busts things: look for '200004AD0000475F000033B381B9C98F.svm' 1 look for [200004AD0000475F000033B381B9C98F.svm] 1 look for '200004AD0000475F000033B381B9C98F.svm' 1 look for [200004AD0000475F000033B381B9C98F.svm] 1 ... look for '200004AD0000475F000033B381B9C98F.svm' 1 look for [200004AD0000475F000033B381B9C98F.svm] 1 look for '200004AD0000475F000033B381B9C98F.svm' 1 look for [200004AD0000475F000033B381B9C98F.svm] 1 ... look for '200004AD0000475F000033B381B9C98F.svm' 1 look for [200004AD0000475F000033B381B9C98F.svm] 1 look for '200006B1000048A900003B26E43FDA1F.svm' 1 look for [200004AD0000475F000033B381B9C98F.svm] 1 look for '200006B1000048A900003B26AFABBAD6.svm' 0 look for [200004AD0000475F000033B381B9C98F.svm] 1 warn:legacy.osl:32664:1:/data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:817: <SwGrfNode::_GetStreamForEmbedGrf(..)> - embedded graphic file not found! warn:legacy.osl:32664:1:/data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:475: Grafik kann nicht eingeswapt werden look for '200004AD0000475F000033B367F3281F.svm' 0 look for [200004AD0000475F000033B381B9C98F.svm] 1 warn:legacy.osl:32664:1:/data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:817: <SwGrfNode::_GetStreamForEmbedGrf(..)> - embedded graphic file not found! warn:legacy.osl:32664:1:/data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:475: Grafik kann nicht eingeswapt werden And the cockup is all related to the last checksum field of the ID: fun ! :-)
Interestingly, if I load and immediately save I get a document with the images included, -but- this: look for '200004AD0000475F000033B367F3281F.svm' 1 look for [200004AD0000475F000033B381B9C98F.svm] 0 look for '200004AD0000475F000033B367F3281F.svm' 1 look for [200004AD0000475F000033B381B9C98F.svm] 0 So - the new checksums in this case are being found; a quick check in the .zip file shows the svms have been renamed Pictures/ in the .odt: before: 200004AD0000475F000033B381B9C98F.svm 200006B1000048A900003B26E43FDA1F.svm after: 200004AD0000475F000033B367F3281F.svm 200006B1000048A900003B26AFABBAD6.svm So - I guess, the act of saving is updating these URLs to point to new names that are allocated for the same svm in the backup file, but not renaming the local files in the document that shares these GraphicObjects. I guess this is the ultimate joy from the $#%#$%ing decision to use random string names for all of this lot - which (in turn) I would argue comes from the decision to use UNO - which makes string / id passing 'obvious' ;-) Wunderbar !
vcl/source/gdi/gdimtf.cxx (GDIMetaFile::GetChecksum) was altered: commit d1da85e8f5d3b6a0c5d1fdcc4fedb0eff5e90b65 Author: ka <kai.ahrens@oracle.com> Date: Fri Feb 4 14:49:25 2011 +0100 ka102: SVG import implementation But - *surely* we can't be fragile on this algorithm changing; it should be fine to have any name for a file in Pictures/ surely !?
The difference between the serialized versions before and after appears to be an upgrade of the meta-file format: before: 00000000 56 43 4c 4d 54 46 01 00 31 00 00 00 01 00 00 00 |VCLMTF..1.......| 00000010 01 00 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 |................| 00000030 00 5f 47 00 00 b3 33 00 00 ad 04 00 00 84 00 01 |._G...3.........| after: 00000000 56 43 4c 4d 54 46 02 00 32 00 00 00 01 00 00 00 |VCLMTF..2.......| 00000010 01 00 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 |................| 00000030 00 5f 47 00 00 b3 33 00 00 ad 04 00 00 01 84 00 |._G...3.........| I assume we upgrade it on the auto-save. The files are rather different after the first four lines; diff -u shows little similarity after then.
With: --- a/svx/source/xml/xmlgrhlp.cxx +++ b/svx/source/xml/xmlgrhlp.cxx @@ -621,6 +621,8 @@ sal_Bool SvXMLGraphicHelper::ImplWriteGraphic( const ::rtl::OUString& rPictureSt } else if( aGraphic.GetType() == GRAPHIC_GDIMETAFILE ) { + fprintf (stderr, "xmlgrhlp.cxx - write meta-file ! 0x%lx\n", + (long)aGraphic.GetChecksum() ); pStream->SetVersion( SOFFICE_FILEFORMAT_8 ); pStream->SetCompressMode( COMPRESSMODE_ZBITMAP ); @@ -643,6 +645,9 @@ sal_Bool SvXMLGraphicHelper::ImplWriteGraphic( const ::rtl::OUString& rPictureSt rMtf.Write( *pStream, GDIMETAFILE_WRITE_REPLACEMENT_RENDERGRAPHIC ); bRet = ( pStream->GetError() == 0 ); + + fprintf (stderr, "xmlgrhlp.cxx - done write meta-file ! 0x%lx\n", + (long)aGraphic.GetChecksum() ); I get: xmlgrhlp.cxx - write meta-file ! 0x67f3281f xmlgrhlp.cxx - done write meta-file ! 0x67f3281f xmlgrhlp.cxx - write meta-file ! 0xafabbad6 xmlgrhlp.cxx - done write meta-file ! 0xafabbad6 Which seems to suggest that the id change is over & done by the time we get to writing the graphic out; and/or is not immediately caused by the writeout.
@@ -387,6 +398,9 @@ sal_Bool SwGrfNode::ImportGraphic( SvStream& rStrm ) const String aGraphicURL( aGrfObj.GetUserData() ); if( !GraphicFilter::GetGraphicFilter().ImportGraphic( aGraphic, aGraphicURL, rStrm ) ) { + fprintf (stderr, "Very curious set User Data of '%s' vs 0x%lx\n", + rtl::OUStringToOString(aGraphicURL, RTL_TEXTENCODING_UTF8).getStr(), + aGraphic.GetChecksum()); aGrfObj.SetGraphic( aGraphic ); aGrfObj.SetUserData( aGraphicURL ); return sal_True; Shows: Very curious set User Data of 'vnd.sun.star.Package:Pictures/200004AD0000475F000033B381B9C98F.svm' vs 0x67f3281f which we would expect I guess, the URL name is set to the user data of the graphic there.
By now, I'm highly suspicious of: void SwXMLTextParagraphExport::setTextEmbeddedGraphicURL( const Reference < XPropertySet >& rPropSet, OUString& rURL) const { if( rURL.isEmpty() ) return; SwGrfNode *pGrfNd = GetNoTxtNode( rPropSet )->GetGrfNode(); if( !pGrfNd->IsGrfLink() ) { String aNewURL( RTL_CONSTASCII_USTRINGPARAM("vnd.sun.star.Package:") ); aNewURL += String(rURL); pGrfNd->SetNewStreamName( aNewURL ); // #i15411# save-as will swap all graphics in; we need to swap // them out again, to prevent excessive memory use pGrfNd->SwapOut(); } } Which sets a new stream name for these images: @@ -827,6 +848,9 @@ void SwGrfNode::_GetStreamStorageNames( String& rStrmName, if( !aUserData.Len() ) return; + fprintf (stderr, "UserData '%s' NewStrmName '%s'\n", + rtl::OUStringToOString(aUserData, RTL_TEXTENCODING_UTF8).getStr(), + rtl::OUStringToOString(aNewStrmName, RTL_TEXTENCODING_UTF8).getStr()); shows wonders like: UserData 'vnd.sun.star.Package:Pictures/200004AD0000475F000033B381B9C98F.svm' NewStrmName 'vnd.sun.star.Package:Pictures/200004AD0000475F000033B367F3281F.svm' just before things go completely pear-shaped :-) So - I guess, the ambiguity of what a vnd.sun.star.Package: URL points at: presumably not into the autosave package ;-) bites. I hadn't realised that on top of the poor choice of string naming of images, we have the poor choice of ambiguous URLs.
the txtparae.cxx code that does the export does: // xlink:href OUString sOrigURL; rPropSet->getPropertyValue( sGraphicURL ) >>= sOrigURL; This calls into /data/opt/libreoffice/master/sw/source/core/unocore/unoframe.cxx:1402ish that in a nutshell returns: pGrfNode->GetGrfObj().GetUniqueID() Which is: (gdb) p sOrigURL $9 = "vnd.sun.star.GraphicObject:200004AD0000475F000033B367F3281F" OUString sURL(GetExport().AddEmbeddedGraphicObject( sOrigURL )); This saves the embedded object into the output stream giving it a new name: (gdb) p sURL $11 = "Pictures/200004AD0000475F000033B367F3281F.svm" setTextEmbeddedGraphicURL( rPropSet, sURL ); And this then calls the 'SetNewName' on the graphic: String aNewURL( RTL_CONSTASCII_USTRINGPARAM("vnd.sun.star.Package:") ); aNewURL += String(rURL); pGrfNd->SetNewStreamName( aNewURL ); Which then causes the grief.
Nice to know this is a re-hash of 2005 - one 'thb' even advised on the topic back then ;-) I can't reproduce this bug with my moronic patch applied either. cf: https://issues.apache.org/ooo/show_bug.cgi?id=48434
patch is: diff --git a/sw/source/filter/xml/xmltexte.cxx b/sw/source/filter/xml/xmltexte.cxx index c62bce3..5c89944 100644 --- a/sw/source/filter/xml/xmltexte.cxx +++ b/sw/source/filter/xml/xmltexte.cxx @@ -221,7 +221,9 @@ void SwXMLTextParagraphExport::setTextEmbeddedGraphicURL( { String aNewURL( RTL_CONSTASCII_USTRINGPARAM("vnd.sun.star.Package:") ); aNewURL += String(rURL); - pGrfNd->SetNewStreamName( aNewURL ); + +// This is nonsensical. +// pGrfNd->SetNewStreamName( aNewURL ); // #i15411# save-as will swap all graphics in; we need to swap // them out again, to prevent excessive memory use
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0389b77a3cbea09ddbae238d7934d4c6349a8d37 fdo#33393 - tentative workaround for autosave image loss
Divining a sane and consistent purpose in Michael Brauer's original work here is somewhat difficult. Suffice it to say that -no-other- image save goes and tries to rename the stream name that we get the GraphicObject from. Then again - other components don't wrap their own versions of SwapIn / SwapOut either - which looks extremely curious in ndgrf.cxx -
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8a8eb870b8037801f81c680441d10a1ef95bfb06&g=libreoffice-3-5 fdo#33393 - tentative workaround for autosave image loss It will be available in LibreOffice 3.5.1.
Today I've submitted Bug 46447 "Images disappear and corrupt Impress presentation" to https://bugs.freedesktop.org/show_bug.cgi?id=46447 After that I was advised at users@de.libreoffice.org that this bug, although it happens in the Impress module, might actually be related to the bug here. Any comments?
Once had the problem with 3,5,1rc1 Win7 x64 SP 1
Fix is in 3.5, 3.6, there will be no 3.4.7, so I closed tis one. Please feel free to reopen if I did wrong.
(In reply to comment #50) > Fix is in 3.5, 3.6, there will be no 3.4.7, so I closed tis one. Please feel > free to reopen if I did wrong. Hi Rainer, I still have this problem in 3.5.1 on Mac OSX. It seems like the problem is present for others too : https://bugs.freedesktop.org/show_bug.cgi?id=47832 where it was tested on 3.5.2 RC1. Consequently, I'm re-opening. Alex
This problem appears to be predicated on the auto-save combined with changing the picture. It appeared to be more noticeable when saving in/restoring from a .docx document. Because it is related to auto-save, which by default is 15 minutes, then it will be as serious issue with long documents. it is a significant bug as the author will have little or no indication it has happened. Sending a document with missing drawings could affect the author's credibility.
Hi Alex, (In reply to comment #51) > I still have this problem in 3.5.1 on Mac OSX. It seems like the problem is > present for others too : > > https://bugs.freedesktop.org/show_bug.cgi?id=47832 > > where it was tested on 3.5.2 RC1. Consequently, I'm re-opening. That bug says specifically 'Buttons on forms' thus is far more specific then this bug. So I doubt if one could see it as a duplicate. Maybe a related corner case? Anyway, I'm testing 3.5.2 now with the steps I used previously to reproduce that bug ...
(In reply to comment #53) > Anyway, I'm testing 3.5.2 now with the steps I used previously to reproduce > that bug ... I cannot reproduce this bug anymore. So the other one must be different / special case.
colin.mercer@botley.com, please do not toggle the status. For more on this please see: http://wiki.documentfoundation.org/BugReport_Details#Version
Hello - I just encountered this bug or something like it. Images show as read-error in LO and the xlsx file would not open in Office 2010. I'm using version 3.5.4 using Mac Lion. This is what I did: 1- started docx document in Office 2010 on Windows 7, added text, a few pictures, and table of contents. 2- opened docx in LO 3.5.4 on Mac Lion. Made various edits and added about 13 jpeg photos using Insert > Picture > From File in various places in the document. I did crop one of the images in LO and edited a few with "Edit with External Tool" (Mac Preview rotation) and all seemed okay from those. 3- re-Saved the file as docx and dropboxed it 4- re-opened the docx file at work today and got the following results. MS Office 2010 will not open it now and says it has an error. Libreoffice 3.5.4 on Windows 7 will open it, but there are read-error notices where the pictures should be. I also notice that the file is 4MB, which would be small considering that many pictures. They would have been a few MB each. Also, the few images that were added originally in step 1 are still present and okay. All other images are missing with read-error. Based on the file-size I'm assuming that the file was not saved correctly on the Mac at step 3 and the images were lost at that point. They were visible in the document upon closeing the file on the Mac at step 3. I'm not sure if auto-save is turned on the Mac or not as I'm not at that computer right now, but assume it would be on as default. I assume dropbox did not mangle the file since the other original pictures added at step 1 are okay and the text is readable. Please let me know what other info I can provide.
Looking at the file again I wanted to note that 1 of the 13 pictures I added in step 2 was retained. I think it was the last one added and it was the one that was cropped (although it doesn't appear to be cropped now).
Turns out that this is easy for me to reproduce on Windows 7 with LO3.5.4. using .docx format and autosave (Save AutoRecovery Information Every) turned on. Both docx and autosave are key aspects. Here are my approximate steps. 1-opened LO and made sure autosave was on, and it is by default 2-changed autosave to 1 minutes (as noted in other comments) although it doesn't work at other intervals either. I figured it would be more likely to have problems if it autosaved more often 3-started new file and saved as docx 4-Added some text and formatting and a few images here and there, while waiting a few minutes between. Also clicked the save button once or twice to save the file between waits and adding images. 5-After about 10 minutes and minimal additions, I saved the file, close it, and closed LO. 6-Re-opened the file in LO and the first image I added was read-error. The other images were present, but some in slightly wrong places. Hope this helps.
Fresh install of Linux Mint 13 Mate with LibreOffice 3.5.3.2 and the bug is still present !
@okko7 please try installing brand new LibO 3.5.5 and tell if the bug is still reproducible. It's always better to use the latest available release.
Well, I would consider the problem(s) mentioned from comment #56 on as a separate bug, because unlike the original problem they are limited to .docx and .xlsx (and maybe other MSO2007+) file formats -- or am I missing something? Therefore, I suggest to open a new bug report for the new problems, to copy comment #56 et seqq. to the new bug report, and to close this (present) bug report again. What do other people think?
Opened a new bug for the problem appearing with .xlsx and .docx files: https://bugs.freedesktop.org/show_bug.cgi?id=52226 and closed the present bug report.