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.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/157249
Title:
[Upstream] [ooo-build] images deleted from file after auto-save occurs
Status in LibreOffice Productivity Suite:
Confirmed
Status in The OpenOffice.org Suite:
Confirmed
Status in “libreoffice” package in Ubuntu:
Incomplete
Status in “openoffice.org” package in Ubuntu:
Won't Fix
Bug description:
I have opened an existing file for the first time in Gutsy with OOo
2.3. After some modifications brought to this file, I noticed some
images had disappeared, but not all images, and an error message was
displayed in a frame of the size of the disappeared image indicating a
read error. Then, I don't saved it to keep my file in its last
correct state, and I made a copy of this file and opened it in
parallel. And at this time the images reappeared in my first modified
file. So, I saved it and closed. After reopening, all images which
had disappeared were not present (not an empty frame, but totally
removed this time).
After, I opened a new copy of my file and I insert a space and remove it in
order to have "save" button enabled and my file not modified, and then I saved
it. I wondered why the size increased from 155566 bytes to 159378 with
exactly the same content, maybe a new version of ODF used in OOo 2.3 as this
file was created with OOo 2.0 and last modified on 2.1??? I have redone the
same modifications and this time there was no problem.
I noticed that when I had finished to redo the same modifications, automatic
saving was triggered, that I didn't see the first time. I say that as this is
may be linked to this problem, and the images in the first time disappeared
after a duration of the same order, but this is only an hypothesis and I'm not
sure at all of that (I will try to made some new tests).
I condider this as critical as it leads to a content loss.
To manage notifications about this bug go to:
https://bugs.launchpad.net/df-libreoffice/+bug/157249/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
