Bug 130133 - FILESAVE wrong values for attribute chart:regression-type in ODF 1.2
Summary: FILESAVE wrong values for attribute chart:regression-type in ODF 1.2
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
6.3.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: odf odf_validation target:6.5.0 targe...
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-22 21:11 UTC by Regina Henschel
Modified: 2020-05-08 22:35 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
A chart to investigate (15.78 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-01-22 21:11 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2020-01-22 21:11:25 UTC
Created attachment 157343 [details]
A chart to investigate

LibreOffice writes the not existing values "polynomial" and "moving-average", when the file is saved in ODF 1.2, both for 'strict' and 'extended'.

Expected: It writes the attribute with namespace 'loext' in case of ODF 1.2 extended and does not use those regression types at all, if saving to ODF 1.2 strict.
These regression types are implemented by LibreOffice, not by OOo, so I think namespace 'loext' is better than 'chartooo'.

You can test the attached file with the validator https://odfvalidator.org/.

These regression type values will be available in ODF 1.3. But that does not solve the problem for ODF 1.2.
Comment 1 Julien Nabet 2020-01-22 22:17:10 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

I submitted a patch on gerrit here:
https://gerrit.libreoffice.org/#/c/core/+/87226/
Comment 2 Commit Notification 2020-01-23 10:19:08 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/84c2b1ab7a8cf5d7f568ef05d4b2b25e783382b6

tdf#130133: fix wrong values for attribute chart:regression-type in ODF 1.2

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 3 Julien Nabet 2020-01-23 10:45:37 UTC
Just in case because it seems email from gerrit may have some problem, here's my last reply on gerrit:
should we backport this on 6.4? 6.3?
Comment 4 Regina Henschel 2020-01-23 13:12:14 UTC
The patch does not solve the problem entirely.

We would need for writing:
ODF 1.2 strict: do not write it at all  ==> Done with the patch
ODF 1.2 extended: write it in 'loext' namespace ==> ??
ODF 1.3 strict and extended: write it in 'style' namespace ==> Nothing to do

In case 'loext' is written, we would need to make all active LO versions able to read it in loext namespace.

@Michael: What do you think about the case "ODF 1.2 extended", which now still produces invalid files?


A release note is necessary for the applied patch, because the behavior changes from a user point of view. Current situation is, that if a user opens a file, which was saved in "ODF 1.2 strict", he nevertheless gets a trend line, although with default parameters. With applied patch, he will get no trend line at all.
Comment 5 Julien Nabet 2020-01-23 13:27:03 UTC
(In reply to Regina Henschel from comment #4)
>...
> ODF 1.2 extended: write it in 'loext' namespace ==> ??
It needs to be verified but when I tested this, whereas I expected a pb, it was ok. (dealt with another LO part?)

> ...
> In case 'loext' is written, we would need to make all active LO versions
> able to read it in loext namespace.
> ...
Indeed I didn't check but I suppose it'll fail if we do nothing.
Import part is done in XMLChartImportPropertyMapper::handleSpecialItem
else if (IsXMLToken( rValue, XML_POLYNOMIAL))
    rProperty.maValue <<= OUString("com.sun.star.chart2.PolynomialRegressionCurve");
else if (IsXMLToken( rValue, XML_MOVING_AVERAGE))
    rProperty.maValue <<= OUString("com.sun.star.chart2.MovingAverageRegressionCurve");
but don't know what to here :-(
Comment 6 Michael Stahl (allotropia) 2020-01-23 14:29:47 UTC
(In reply to Regina Henschel from comment #4)
> The patch does not solve the problem entirely.
> 
> We would need for writing:
> ODF 1.2 strict: do not write it at all  ==> Done with the patch
> ODF 1.2 extended: write it in 'loext' namespace ==> ??
> ODF 1.3 strict and extended: write it in 'style' namespace ==> Nothing to do
> 
> In case 'loext' is written, we would need to make all active LO versions
> able to read it in loext namespace.

yes, that's a bit of a problem, we'd have to first add the ability to read the loext attribute and then wait a few years until most users have upgraded and then we can write it.

apparently these values are written since 2013 if not earlier.

> @Michael: What do you think about the case "ODF 1.2 extended", which now
> still produces invalid files?

given that we need to wait anyway, my question is: in a couple of years, who wants to export ODF 1.2 extended, i'd expect the default to be ODF 1.3 extended then, which already solves the problem... so given the timing i'm not sure if it's worth the effort to start doing anything about 1.2 extended now.
Comment 7 Commit Notification 2020-01-23 14:44:48 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/5053f01bfebebd5a0f00e0f1c27d4868fbe2e6a0

tdf#130133: fix wrong values for attribute chart:regression-type in ODF 1.2

It will be available in 6.4.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Regina Henschel 2020-01-23 15:02:37 UTC
(In reply to Michael Stahl (CIB) from comment #6)
> 
> > @Michael: What do you think about the case "ODF 1.2 extended", which now
> > still produces invalid files?
> 
> given that we need to wait anyway, my question is: in a couple of years, who
> wants to export ODF 1.2 extended, i'd expect the default to be ODF 1.3
> extended then, which already solves the problem... so given the timing i'm
> not sure if it's worth the effort to start doing anything about 1.2 extended
> now.

I think, it's not worth the effort.
Comment 9 Thorsten Behrens (allotropia) 2020-05-08 22:35:00 UTC
Looks fixed now on master (if we exclude the 1.2 extended special case).