Apache OpenOffice (AOO) Bugzilla – Issue 60323
Export meta data for OLE objects (particularly for charts)
Last modified: 2017-05-20 11:29:38 UTC
Currently OLE objects do not contain the meta.xml stream. This should be changed for at least two reasons: 1. For some fixes we need a reliable generator information for the content of the OLE object's streams. The generator of the parent document needs not to be the same as the one of the OLE object. 2. Document variables, like filled-in fields in a form, will get lost after saving a document as OLE object. It has to be decided which kind of information should be written to the OLE object's meta.xml stream with respect to actuality and privacy. That is, it should not be necessary to update the OLE object's meta information when doing a "Save As" (actuality). Sensitive things like the author should probably not be written. For the parent document there is a checkbox in the Document Info for deciding whether sensitive information should be written or not. Using this information also for OLE objects would require loading all of them (which is not practical).
One concrete case where this fix would have helped, and thus will help if similar fixes are done in the future (after the fix for this issue) is the stroke-opacity fix in Issue 42959. If you have saved a document containing a chart with lines that have 100% opacity (that is unfortunately also true for many default lines) in a version prior to SRC680.m125, those file contain a stroke-opacity of 0% (wrong export). If you load such a file in a version after SRC680.m128 (in which the fix for Issue 42959 is contained) and save it to a different location, the chart will not be loaded an saved again, so that you get a new file that still contains the bug in the OLE chart object. The ifx for Issue 42959 checks the version with which the chart was saved by checking the container document's meta.xml (because the chart itself has no meta information) which leads to the wrong assumption that the chart does not contain the bug. Thus the stroke-opacity values are not adapted, and the lines will be invisible (0% opacity means 100% transparent). As a work-around, you can try to make sure that all charts are at least once loaded before you re-save the file. In Calc, you can press F9 to update all charts. In other applications I fear it only helps to activate each chart once (double-click).
To avoid confusion: In the last comment I wrote that charts may not be loaded and saved when saving a file to a different location. What I meant was, that the existing chart stream (the chart part in the file) is usually just copied like you would copy a file with cp or copy in you file system. To write a correct file, the chart would have to be loaded (thus a chart would be created in memory) and saved again using the export XML filter. Since we have a replacement image for OLE objects, even visible chart are no longer loaded by default nowadays.
adjusting target
added me to CC and added 'chart' to summary, so this issue looks up in the chart queries
I changed the SfxXMLMetaExport to export the generator even if the document info properties are empty. This is the case for charts. As the generator is independent from the properties, I see no problem in this change.
I also changed the SfxXMLMetaImport. Now, it imports the Generator, even if the Document Info is not available. There are other properties that do not depend on the document info, but I only changed the behaviour for the generator (as I don't know the other properties). Now, it is possible to do the following in the import code: sal_Int32 nUPD = 0, nBuildId = 0; if( GetImport().getBuildIds( nUPD, nBuildId )) { // only reached, if the generator was exported in meta // do something dependent on the BuildId }
target 3.0
target 3.1
The implementation is tricky. If we write meta.xml we must not write any personal data into it or we must remove this data from all objects in case the user does not store it for the container document. So how can we prevent some meta data from being stored for embedded documents? The MetaExport class just serializes everything what has been stored in the DocumentProperties and I see no easy way to change that (UNO APIs involved). The DocumentProperties instance does not know anything about whether the document is embedded or not, so it will take all set...() calls for any property. We could fix that by not calling e.g. setAuthor() and similar things for embedded documents. This would be some effort and it remains error prone. So this feature needs some more thoughts.
As it was implemented for Chart this issue no longer is a blocker for others
Reset assigne to the default "issues@openoffice.apache.org".