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:
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' ;-)
Interestingly, if I load and immediately save I get a document with the images included, -but- this:
look for '200004AD000047 5F000033B367F32 81F.svm' 1 5F000033B381B9C 98F.svm] 0 5F000033B367F32 81F.svm' 1 5F000033B381B9C 98F.svm] 0
look for [200004AD000047
look for '200004AD000047
look for [200004AD000047
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: F000033B381B9C9 8F.svm 200006B1000048A 900003B26E43FDA 1F.svm F000033B367F328 1F.svm 200006B1000048A 900003B26AFABBA D6.svm
200004AD0000475
after:
200004AD0000475
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 !