[Libreoffice-commits] core.git: Branch 'libreoffice-6-2' - i18npool/source offapi/com sw/qa

[Libreoffice Gerrit user]

 i18npool/source/characterclassification/cclass_unicode_parser.cxx |   13 +++++
 offapi/com/sun/star/i18n/KParseTokens.idl                         |   22 ++++++++++
 sw/qa/extras/rtfexport/rtfexport.cxx                              |    2 
 3 files changed, 34 insertions(+), 3 deletions(-)

New commits:
commit 9336286a7ea5385541344f444e6f8702c85bdacb
Author:     Eike Rathke <erack at redhat.com>
AuthorDate: Fri Nov 30 14:20:49 2018 +0100
Commit:     Eike Rathke <erack at redhat.com>
CommitDate: Fri Nov 30 22:15:22 2018 +0100

    [API CHANGE] Resolves: tdf#42518 new KParseTokens::GROUP_SEPARATOR_IN_NUMBER
    
    Default unset bit now does not accept/skip group separators in
    numbers.
    
    See .idl description comment for why this is incompatible and how.
    
    This actually uncovered a "bug" (or at least unexpected) in the
    Math parser that parsed "0," as one entity instead of "0" followed
    by ",". As obtaining the text form appends a blank after each
    entity the sw/qa/extras/rtfexport/rtfexport.cxx testMathEqarray()
    testcase had to be adapted.
    
    Change-Id: I2b605742ab3d8a9bb81ad6880faf050535dc80fa
    Reviewed-on: https://gerrit.libreoffice.org/64270
    Tested-by: Jenkins
    Reviewed-by: Eike Rathke <erack at redhat.com>
    (cherry picked from commit 776f7e7463de3e97f3056712ee567f49a314829d)
    Reviewed-on: https://gerrit.libreoffice.org/64355

diff --git a/i18npool/source/characterclassification/cclass_unicode_parser.cxx b/i18npool/source/characterclassification/cclass_unicode_parser.cxx
index 8cca988607fd..3c040a5a0085 100644
--- a/i18npool/source/characterclassification/cclass_unicode_parser.cxx
+++ b/i18npool/source/characterclassification/cclass_unicode_parser.cxx
@@ -441,8 +441,15 @@ void cclass_Unicode::initParserTable( const Locale& rLocale, sal_Int32 startChar
         cDecimalSepAlt = aItem.decimalSeparatorAlternative.toChar();
     }
 
-    if ( cGroupSep < nDefCnt )
-        pTable[cGroupSep] |= ParserFlags::VALUE;
+    if (nContTypes & KParseTokens::GROUP_SEPARATOR_IN_NUMBER)
+    {
+        if ( cGroupSep < nDefCnt )
+            pTable[cGroupSep] |= ParserFlags::VALUE;
+    }
+    else
+    {
+        cGroupSep = 0;
+    }
     if ( cDecimalSep < nDefCnt )
         pTable[cDecimalSep] |= ParserFlags::CHAR_VALUE | ParserFlags::VALUE;
     if ( cDecimalSepAlt && cDecimalSepAlt < nDefCnt )
@@ -814,6 +821,8 @@ void cclass_Unicode::parseText( ParseResult& r, const OUString& rText, sal_Int32
                 }
                 if ( nMask & ParserFlags::VALUE )
                 {
+                    if (current == cGroupSep)
+                        nParseTokensType |= KParseTokens::GROUP_SEPARATOR_IN_NUMBER;
                     if ((current == cDecimalSep || (bDecSepAltUsed = (cDecimalSepAlt && current == cDecimalSepAlt))) &&
                             ++nDecSeps > 1)
                     {
diff --git a/offapi/com/sun/star/i18n/KParseTokens.idl b/offapi/com/sun/star/i18n/KParseTokens.idl
index ce5d355f0430..bc0f92c42c83 100644
--- a/offapi/com/sun/star/i18n/KParseTokens.idl
+++ b/offapi/com/sun/star/i18n/KParseTokens.idl
@@ -95,6 +95,28 @@ published constants KParseTokens
     /// Unicode (above 127) other number
     const long UNI_OTHER_NUMBER     = 0x00080000;
 
+    /** If this bit is set in <em>nContCharFlags</em> parameters, the
+        locale's group separator characters in numbers are accepted and
+        ignored/skipped. Else a group separator in a number ends the
+        current token. A leading group separator is never accepted. If
+        an accepted group separator was encountered in a number
+        (ParseResult::TokenType is KParseType::ASC_NUMBER or
+        KParseType::UNI_NUMBER) this bit is also set in
+        ParseResult::ContFlags.
+
+        <p> <strong>NOTE:</strong> absence of this bit in
+        <em>nContCharFlags</em> changes the default behaviour that in
+        prior releases accepted numbers with group separators but lead
+        to unexpected results when parsing formula expressions where the
+        user entered a (wrong) separator that happened to be the group
+        separator instead of an intended decimal separator. Usually
+        inline numbers in a formula expression do not contain group
+        separators.
+
+        @since LibreOffice 6.2
+     */
+    const long GROUP_SEPARATOR_IN_NUMBER = 0x08000000;
+
     /** If this bit is set in <em>nContCharFlags</em> parameters and a
         string enclosed in double quotes is parsed and two consecutive
         double quotes are encountered, the string is ended. If this bit
diff --git a/sw/qa/extras/rtfexport/rtfexport.cxx b/sw/qa/extras/rtfexport/rtfexport.cxx
index 8b6ecdb27f85..8dc665642278 100644
--- a/sw/qa/extras/rtfexport/rtfexport.cxx
+++ b/sw/qa/extras/rtfexport/rtfexport.cxx
@@ -210,7 +210,7 @@ DECLARE_RTFEXPORT_TEST(testMathEqarray, "math-eqarray.rtf")
 {
     OUString aActual = getFormula(getRun(getParagraph(1), 1));
     OUString const aExpected(
-        "y = left lbrace stack { 0, x < 0 # 1, x = 0 # {x} ^ {2} , x > 0 } right none");
+        "y = left lbrace stack { 0 , x < 0 # 1 , x = 0 # {x} ^ {2} , x > 0 } right none");
     CPPUNIT_ASSERT_EQUAL(aExpected, aActual);
 }