Bug 69679 - EDITING: Problem in Copy-Paste when text contains characters with code 0Dh
Summary: EDITING: Problem in Copy-Paste when text contains characters with code 0Dh
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.1.2 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Paste Character
  Show dependency tree / graph
 
Reported: 2013-09-22 16:28 UTC by Ankur Vishwakarma
Modified: 2022-01-26 08:22 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Java source file (3.99 KB, text/x-java)
2013-09-22 16:28 UTC, Ankur Vishwakarma 		Details
result of pasting into Writer in 3.4.2 on WinXP (8.75 KB, application/vnd.oasis.opendocument.text)
2013-09-23 12:55 UTC, sasha.libreoffice 		Details
Test case to simply demonstrate the problem (775 bytes, text/plain)
2014-02-06 23:42 UTC, Dale 		Details
Test Case with example results (21.80 KB, application/x-zip-compressed)
2014-02-07 06:57 UTC, Dale 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ankur Vishwakarma 2013-09-22 16:28:33 UTC 
Created attachment 86322 [details]
Java source file

Problem description: 

I copy and pasted a java source code to librewriter, but instead of complete code paste only a single statement got pasted.

MS Office 2007 works well in this regard.

tested on Windowx XP SP3 and ubuntu 12.04 LTS.

Steps to reproduce:
1. Open attached java source file in text editor in read-only mode

2. Select all code from source file for copy operation using Ctrl+A and Ctrl+C.

3. Open LibreWriter and Press Ctrl+V to paste the copied source code.

4. You will see the bug then.

Current behavior:

Incomplete paste operation.

Expected behavior:

Complete paste operation

              
Operating System: All
Version: 4.1.1.2 release
Comment 1 Terrence Enger 2013-09-22 18:08:06 UTC 
Examination of Quiz.java shows that carriage-return separates lines.
This could well be the trigger for the problem.

I have not reproduced exactly "only a single statement gets pasted",
but I can get the whole file joined together into one paragraph.
Since the problem description says the problem is the same on Linux,
it is strange that my bad result differs from the reporter's result.
Ankur, can you confirm my understanding that you see a different
result?

When I save the "joined together" document as an .fodt, I see that the
carriage returns are represented as "
".


How to get the bad result:

(*) Wine Notepad, running on wine, does not recognize the carriage
    returns in its own display, and the paste into Writer gives
    everything run together in one paragraph.


How to get good results:

(*) Writer menu option Insert > File produces good results.

(*) emacs tells me that Quiz.java is a Mac file, and on input it
    converts carriage return to linefeed-only (the Linux convention);
    pasting into Writer works well.

(*) gedit is less forthcoming about what it is doing, but the result
    is good.


My LibreOffice is master commit 95e95e0, fetched 2013-09-19, and
configured with:

    --enable-option-checking=fatal
    --enable-dbgutil
    --enable-crashdump
    --without-system-postgresql
    --without-myspell-dicts
    --with-extra-buildid
    --without-doxygen
    --with-external-tar=/home/terry/lo_hacking/git/src


HTH,
Terry.
Comment 2 sasha.libreoffice 2013-09-23 12:55:56 UTC 
Created attachment 86361 [details]
result of pasting into Writer in 3.4.2 on WinXP
Comment 3 sasha.libreoffice 2013-09-23 13:04:19 UTC 
Reproduced in 3.4.2 and 3.5.0 in WinXP 32 bit
(therefore not a regression)

In LibreDraw and Calc works correctly.
Possible workaround: paste first into Draw, then select text, copy and paste now into Writer.

IMHO this bug may result in problems with interoperability with MacOS users. There this ODh character is widely used.
Comment 4 Terrence Enger 2013-09-23 13:48:29 UTC 
Thank you, Sahsa.  Your result matches the original problem
description and is quite different from mine.

It might help the programmer if you identify the program in which you
did the copy operation.  Mind you, I do not know that different
programs would put different things on the clipboard.

So far, we do not have a report from a Mac user.  That is the other
popular platform for LibreOffice.  As the carriage-return as a line
separator is the Mac convention, it would be surprising if LibreOffice
on the Mac screws up.  Pending that information, I am marking this as
a Windows bug.

Meanwhile, I think I shall ask the discuss list whether my observed
"bad" behavior is in fact a bug.  As ugly as the result is, it is not
entirely unreasonable.

Terry,
Comment 5 sasha.libreoffice 2013-09-24 05:51:38 UTC 
Used notepad and TotalCommander (pressed F3)
Comment 6 Ankur Vishwakarma 2013-09-24 13:52:31 UTC 
Hi Terry,

     Sorry firstly; I have the bug on Windows XP SP3 and getting a good result under ubuntu 12.04 LTS.

As explained by you that Inserting a file from menu will give good result doesn't happens on WinXP

(*) Writer menu option Insert > File produces bad results.


I have used MS Notepad and Notepad++, but getting the same bad result in LibreWriter.



Ankur,
Comment 7 Dale 2014-02-06 23:42:30 UTC 
Created attachment 93571 [details]
Test case to simply demonstrate the problem

This test file demonstrates that, in a paste operation, all characters following "CR not immediately followed by LF" are discarded until a CR/LF pair is seen.
I observe this behaviour in the two versions I have tested: LO 4.1.1.2 and 4.2.0.4
Comment 8 Dale 2014-02-07 06:57:09 UTC 
Created attachment 93585 [details]
Test Case with example results

Clarifying my previous post, the problem shows up on Windows XP.
I have checked on Linux and the behaviour is different. Specifically the line feeds are being interpreted as expected, but all carriage returns are embeded as "
" (as reported in Comment 1).
I concurr with Comment 4 that this is a Windows bug, although the Linux behaviour is not what most would expect either.
Comment 9 Joel Madero 2015-05-02 15:43:10 UTC Comment hidden (obsolete)
Comment 10 Terrence Enger 2015-05-05 17:07:07 UTC 
I no longer have wine available, so cannot do the test which I
reported in comment 2, but here is what I see with LibreOffice
4.4.2.2 running on Windows Vista:

(*) Insert > Document brings in only the first line of Quiz.java.

(*) Copy from emacs 24.3.1 and paste into LibreOffice gives good
    results.

(*) Copy from Notepad Version 6.0 (Build 6002: Service Pack 2) gives
    one line, which I am retyping:

        import javax.microedition.midlet.*;","IBM"};

    with the cursor after the ending semicolon.  This is quite
    different from the results with Notepad under wine that I reported
    in comment 2.

    The imported line up to the first semicolon is the first line of
    Quiz.java.  The double-quoted comma appears many places in
    Quiz.java and the remainder of the line appears two places.

    When I save the result in a .fodt, the saved line appears as one
    line, which I am retyping here with added line breaks:

        <text:p text:style-name="P1">
          import javax.microedition.midlet.*;&quot;,&quot;IBM&quot;};
        </text:p>

HTH,
Terry.
Comment 11 QA Administrators 2016-09-20 09:37:03 UTC Comment hidden (obsolete)
Comment 12 Terrence Enger 2016-12-11 20:39:14 UTC 
I still get the results described in comment 11 using
bibisect-win32-5.3 repository commit 479ca41, source hash f8c463b3.
Comment 13 QA Administrators 2018-07-05 02:49:14 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2020-07-05 03:39:05 UTC Comment hidden (obsolete)
Comment 15 Timur 2022-01-26 08:22:20 UTC 
Repro 6.4, no repro 7.0 and 7.4+. WFM.