Comment 55 for bug 157249

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 !