tdf#133077: fix lone CR handling in plain text clipboard on Windows

Failing to treat CRs without corresponding LFs resulted in 0 inserted
in the place of the CR, but the text up to this position not inserted,
and pLastStt not updated. Thus all following text was dropped when the
insertion was finally performed (when CRLF or EOF was reached), because
of the 0 marking end of inserted text. But that was inconsistent with
how other Windows applications treated stand-alone CRs, and also with
our own handling of them when they happened in the end of the internal
read buffer.

Change-Id: Idf4876b0cccd4aa3f14f6efede54d27670f55c35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94277
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

1 files changed, 4 insertions, 6 deletions

diff --git a/sw/source/filter/ascii/parasc.cxx b/sw/source/filter/ascii/parasc.cxx
index 5bc3999b358c..2cf851d0b558 100644
--- a/sw/source/filter/ascii/parasc.cxx
+++ b/sw/source/filter/ascii/parasc.cxx
@@ -401,19 +401,17 @@ ErrCode SwASCIIParser::ReadChars()
                         *pStt = 0;
                         ++pStt;
 
-                        bool bChkSplit = false;
+                        bool bChkSplit = true;
                         if( LINEEND_CRLF == pUseMe->GetParaFlags() )
                         {
                             if( pStt == pEnd )
+                            {
                                 cLastCR = 0x0d;
+                                bChkSplit = false;
+                            }
                             else if( 0x0a == *pStt )
-                            {
                                 ++pStt;
-                                bChkSplit = true;
-                            }
                         }
-                        else
-                            bChkSplit = true;
 
                         // We skip the last one at the end
                         if( bChkSplit && ( !rInput.eof() || pEnd != pStt ))