Re: broken backwards compatibility with certain old charts

On 31/08/13 10:44, Lionel Elie Mamane wrote:
> I'd like to draw your attention on my commit
>
> ommit b090cbdf82e0827234caf5969124f6631311ef35
> Author: Lionel Elie Mamane <lionel@mamane.lu>
> Date:   Fri Aug 30 18:00:21 2013 +0200
>
>     fdo#68663 don't blindly force categories when there are none
>
>     Change-Id: If52ea471ee3ca10e2f69d2fcd7b3ae0d5772bfc3
>
>
> If the comment is right (which is not always the case in the
> LibreOffice codebase...), then I've just broken reading of categories
> for these kinds of old "files with own data without a categories
> element but with row descriptions".
>
> This code was pretty much unconditionally always adding categories,
> although I could see no trace of "row description" in the charts
> generated by Report Builder; by force-adding categories, this was
> leading to fdo#68663.

> So, if anyone has a clue how to make that "force-add categories"
> conditional to the presence of these mysterious "row descriptions",
> I'd be happy to collaborate to add this (now properly conditional)
> "add categories" back.

actually i had wondered the same thing...

this code was apparently added in a commit from Bjoern Milcke's chart2
re-write:

    INTEGRATION: CWS chart2mst3 (1.13.26); FILE MERGED
    2006/12/12 16:55:12 bm 1.13.26.9: own data with no categories
element: apply categories in applyTable()

... without any issue id.

i would guess that "files with own data without a categories
element but with row descriptions" would be written by the old chart
application, before the re-write; not because i have any knowledge of
that but it's simply the most plausible assumption.

usually when previous versions of OOo wrote files that were invalid in
some way, some hack was added in the import filter so that existing
files could still be read in newer versions; this often comes with a
version check.  possibly the version check is missing in this case
because the chart2 re-write took a long time so at the time of the above
commit it was unknown which OOo version would be the last one to write
the affected files (and then it was forgotten)?

so based on the above vague hand-waving explanation i would suggest to
do this fix-up hack only for files written by e.g. OOo versions < 3.0
and hope for the best (unless somebody has a better idea or explanation).

version check is "SvXMLImport::isGeneratorVersionOlderThan(OOo_30x,
LO_3x)" for this.