Issue 60323

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".