Comment 60 for bug 157249

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.