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.
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/
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.
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?
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.
(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 :-(
(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.
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.
(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.
Looks fixed now on master (if we exclude the 1.2 extended special case).