Bug 101828 - RTF paste no longer available in 5.2+
Summary: RTF paste no longer available in 5.2+
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
Whiteboard: target:5.4.0 target:5.3.1
Keywords: bibisected, bisected, regression
: 101150 102547 102921 103860 104012 104917 105007 105340 105820 105997 (view as bug list)
Depends on:
Blocks: RTF Paste
  Show dependency treegraph
Reported: 2016-08-31 17:31 UTC by mike
Modified: 2019-11-01 07:05 UTC (History)
23 users (show)

See Also:
Crash report or crash signature:

PDF for testing (12.30 KB, application/pdf)
2016-10-03 09:24 UTC, Buovjaga
RTF is present, LO don't show/use it (67.19 KB, image/jpeg)
2017-01-25 08:13 UTC, bug102921

Note You need to log in before you can comment on or make changes to this bug.
Description mike 2016-08-31 17:31:59 UTC
in writer 5.2 when i copy and paste from a pdf to writer in loses formatting for bold and italics
this worked on 5.1 (I just upgraded)
i can paste the same text into MS wordpad and see the correct formatting
Comment 1 mike 2016-08-31 21:01:28 UTC
also when i copy/paste from MS Wordpad to writer 5.2 it loses bold and italics.
Comment 2 John Schuetz 2016-08-31 21:24:08 UTC
I'm seeing this as well in writer 5.2 copying from pdf to writer and from Logos 6 to writer.  Also, in these cases Paste Special only gives the option of unformatted text.
Comment 3 mike 2016-09-07 13:50:00 UTC
with version still broken
Comment 4 mike 2016-09-07 14:39:17 UTC
i reverted to and pasting with formatting works correctly
Comment 5 John Schuetz 2016-09-29 14:09:50 UTC
It's still broken with 5.2.2.
Comment 6 Buovjaga 2016-10-03 09:24:13 UTC
Created attachment 127786 [details]
PDF for testing

Copy from this to test.
Comment 7 Buovjaga 2016-10-03 09:29:34 UTC

Win 7 Pro 64-bit Version:
Build ID: 3d9231dd4945dcd6c3d53ba11152049d382b975f
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-28_02:14:14
Locale: fi-FI (fi_FI); Calc: CL

Ubuntu 16.04 64-bit
Build ID: 1:5.2.2-0ubuntu1~xenial0
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 8 John Schuetz 2016-10-03 13:31:09 UTC
Hi Buovjaga,

I downloaded your pdf file and did a copy paste into a Writer document in and neither the bold nor the italics were preserved.
Comment 9 Buovjaga 2016-10-03 13:47:18 UTC
The thing is, I copied and pasted to LibO 3.6 and it didn't preserve the formatting either.
I forgot to test with an older version on Windows.

Arch Linux 64-bit
Version (Build ID: e183d5b)
Comment 10 mike 2016-10-03 14:12:52 UTC
on pasting with formatting works correctly
i have win 7 64 bit SP1 with updates current

i've been using Libre Office for quite a few versions, like all the 4.x ones and 5.0, and never had this problem
Comment 11 Buovjaga 2016-10-04 11:25:25 UTC
Pasting with formatting does not work in 3.5 or 4.4.

In Windows, I use SumatraPDF.
In Arch Linux, I use Okular.
In Ubuntu, I use the default Document viewer.

Which PDF viewer do you guys use?

Tested on Win 7 with:
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735

Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99
Locale: fi_FI
Comment 12 John Schuetz 2016-10-04 13:28:48 UTC
In Windows (Windows 10 x64) I use Adobe Acrobat Reader DC (version 2015.017.20053).  I also use Logos 6 (a Bible resource program), but that's not for pdf's per se.  However, the issue manifests itself the same way when copying from either program into Writer.
Comment 13 mike 2016-10-04 17:00:11 UTC
Adobe reader DC 2015.017

also the loss of formatting issue happens when i paste from microsoft wordpad to libre writer
Comment 14 raal 2016-10-04 20:10:58 UTC
This seems to have begun at the below commit.
Adding Cc: to Oliver Specht; Could you possibly take a look at this one? Thanks

author	Oliver Specht <oliver.specht@cib.de>	2016-03-09 15:19:51 (GMT)
committer	Oliver Specht <oliver.specht@cib.de>	2016-03-10 10:11:04 (GMT)
commit 36bf13247b01075b533b127c7e5ffc760f9642f8 (patch)
tree f70cdbad2cb3bf8f15b248f342ce88c4cc237523
parent 416526cfa382d3482042f3c917bcb2bfa178402a (diff)
tdf#97591: mark RTF clipboard format as text/rtf
 git bisect log
# bad: [6380ca07b05f68dedcaa379302cfe1fa478571c4] source 60b74fe1775e647545d2da1fcc58a4c63ec18aa5
# good: [1f670510f08cb800cbae2a1dd6ea70d3542e4721] source 49c2b9808df8a6b197dec666dfc0cda6321a4306
git bisect start 'origin/master' 'oldest'
# good: [38f37b8ec1a2d199bb957cfd2581df7d1b273b74] source c0da1080b61a1d51654fc34fdaeba373226065ff
git bisect good 38f37b8ec1a2d199bb957cfd2581df7d1b273b74
# bad: [11ae494d8c566f23e0ef84ba0cc25fb1388b67f7] source 470cfa9860232ab70e017e6084d80f80d469555c
git bisect bad 11ae494d8c566f23e0ef84ba0cc25fb1388b67f7
# bad: [d247d25062e6cc4afccdc3c4be84a2b98523b36a] source 150c1dcab007dd8acc1551791f42eef692f9e531
git bisect bad d247d25062e6cc4afccdc3c4be84a2b98523b36a
# good: [dc23450cfb87b61fcbd905a7079d8a0d32759e6b] source 5c1234eac2b9f3a3ea032e4828a15bedca6b9ebe
git bisect good dc23450cfb87b61fcbd905a7079d8a0d32759e6b
# bad: [3c06b49a11643ee6e22d8184f65dcc129ceb586d] source 42d6a165b053ebdccbd6979eb849b1abe305d2ba
git bisect bad 3c06b49a11643ee6e22d8184f65dcc129ceb586d
# good: [ae20ff1c2de6ecec64f34a839a82f6dfd00f5ac5] source 70fca3e901e41fa52589eb3f06e6839c4a8582de
git bisect good ae20ff1c2de6ecec64f34a839a82f6dfd00f5ac5
# bad: [6d7499abfffe460a5f7013564141cc51dbc39e87] source 127fbac23afa1fc94dd7f8aae390e1ff55ed5d64
git bisect bad 6d7499abfffe460a5f7013564141cc51dbc39e87
# bad: [ead1e6d2162bca106369cec08b6bac34610626dc] source a3fcf5a3b8ea26c289b12216d7f8fdb7e07814b7
git bisect bad ead1e6d2162bca106369cec08b6bac34610626dc
# good: [76ec908f8aa5824caac5af760b0b866e1bb0720b] source 3d82b08bcea45408b1998934558e2e28721125df
git bisect good 76ec908f8aa5824caac5af760b0b866e1bb0720b
# bad: [d644a4e4923dfa3b358bbb64eeb77baab7defeb4] source 51d1fca2041ba4478c5abae59b1ed4fee37ea1ee
git bisect bad d644a4e4923dfa3b358bbb64eeb77baab7defeb4
# bad: [e9331335bf8aa1bad7e9846fc91393f07d3648ef] source 5c4717416b7eeaf99765725785278a7437fdaf8a
git bisect bad e9331335bf8aa1bad7e9846fc91393f07d3648ef
# bad: [81cc3639fe6b1ba719ad6e0419fe516d09bcae78] source 36bf13247b01075b533b127c7e5ffc760f9642f8
git bisect bad 81cc3639fe6b1ba719ad6e0419fe516d09bcae78
# good: [e40edc1a88bcd94f34a0ecb58a9f0c6fdebbb86c] source 416526cfa382d3482042f3c917bcb2bfa178402a
git bisect good e40edc1a88bcd94f34a0ecb58a9f0c6fdebbb86c
# first bad commit: [81cc3639fe6b1ba719ad6e0419fe516d09bcae78] source 36bf13247b01075b533b127c7e5ffc760f9642f8
Comment 15 Xisco Faulí 2016-10-05 08:11:50 UTC
*** Bug 101150 has been marked as a duplicate of this bug. ***
Comment 16 Xisco Faulí 2016-10-05 08:36:14 UTC
*** Bug 102921 has been marked as a duplicate of this bug. ***
Comment 17 bugs 2016-10-05 09:02:11 UTC
Basically the problem is that "Rich Text Format" is not recognized as a valid clipboard format. I have software that only copies "Rich Text Format" data to the clipboard and LO does not enable the Paste option in the versions specified.
Comment 18 Xisco Faulí 2016-10-19 21:53:56 UTC
*** Bug 102547 has been marked as a duplicate of this bug. ***
Comment 19 John Schuetz 2016-11-21 15:06:48 UTC
Kind of both a bump and a report that this problem still exists in 5.3 alpha (Windows 10; 64-bit)
Comment 20 Xisco Faulí 2016-11-23 16:10:22 UTC
*** Bug 104012 has been marked as a duplicate of this bug. ***
Comment 21 Buovjaga 2016-11-27 19:45:39 UTC
*** Bug 103860 has been marked as a duplicate of this bug. ***
Comment 22 ChrisAIX 2016-12-22 15:24:11 UTC
A fix for this bug should be delivered - cut&paste is a basic functionality.

--> It still existists in v5.2.4

As already stated in Bug 104012 - this bug has been "added" in v5.2.x - so the 5.2.x branch is not usable (for me) ... 

The commit of the bug has already been found - see post #14 ...
Is it possible to increase the severity and to fix (uncommit) the root cause?
Comment 23 Marco Coppola 2016-12-25 17:13:29 UTC
This bug for me is a real show-stopper, because it prevents the interaction with  another software (that I need and cannot modify) that generates text in RTF format and tries to paste it in a Writer document.

Please fix
Comment 24 bugs 2016-12-25 17:38:28 UTC
We have an Add-In for Microsoft Office and Libre Office that copies and pastes from our application to the word processor. We use RTF for copy and paste. It stopped working at 5.2+. Our customers want a open source option rather then spending large amounts on Microsoft Word.

Please Fix.
Comment 25 Xisco Faulí 2016-12-28 09:43:04 UTC
*** Bug 104917 has been marked as a duplicate of this bug. ***
Comment 26 Xisco Faulí 2016-12-28 09:46:25 UTC
Hi Aron, *,
What about reverting the problematic commit? There're already 6 duplicates of this and we keep receiving more and more reports for this problem.
Comment 27 Aron Budea 2016-12-28 14:11:48 UTC
Hi Xisco, no need to, the following gerrit patch fixes the bug once it's merged:
Comment 28 Telesto 2016-12-30 17:38:36 UTC
*** Bug 105007 has been marked as a duplicate of this bug. ***
Comment 29 Xisco Faulí 2017-01-06 23:58:10 UTC
Hi Aron,
it seems Oliver Specht has also uploaded a fix for this problem: https://gerrit.libreoffice.org/#/c/32682/
it would be nice if you both can sync so you don't overlap your work
Comment 30 Commit Notification 2017-01-09 00:35:01 UTC
Oliver Specht committed a patch related to this issue.
It has been pushed to "master":


tdf#101828 handle rtf/richtext correctly

It will be available in 5.4.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 31 mike 2017-01-09 12:31:12 UTC Comment hidden (no-value)
Comment 32 Aron Budea 2017-01-09 17:13:47 UTC
(In reply to Xisco Faulí from comment #29)
> it would be nice if you both can sync so you don't overlap your work
No worries, I abandoned mine.
Comment 33 Aron Budea 2017-01-09 21:47:23 UTC
Mike, this is how bug fixing works, first the fix is pushed into the current development branch, and later it's backported to release branches. This ensures the fix can be tested first before it potentially causes more serious issues than it fixed. Additionally, not all fixes get backported, but let's not get into that, I'm sure this qualifies. Please be patient.
Comment 34 V Stuart Foote 2017-01-14 18:05:44 UTC
*** Bug 105340 has been marked as a duplicate of this bug. ***
Comment 35 V Stuart Foote 2017-01-14 18:55:23 UTC
On Windows 10 Pro 64-bit en-US with
Build ID: 9e7526044c8fa6b006b0cb791d15f2476c96ebf2
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-14_04:20:03
Locale: en-US (en_US); Calc: CL

Copy and a paste special from attachment 130430 [details] (from duplicate bug 105340 ) offers "Formatted Text [RTF]" format choice. The columns from OOXML sheet paste into a table in Writer. 

But may have some adjustment to do yet, as the formatting on canvas of the RTF as copied from Calc does not match the format of the RTF when copied from Excel 2007. Seems like we loose some of the styling of the text between LO modules in rendering the RTF to document canvas.

And with Impress, the Edit -> Paste Special for selection is still offering the "Formatted text [Richtext]" as well as the desired "Formatted text [RTF]"--but either is restyled from the RTF to use defined Table style. But here, pasting from Excel 2007 to Impress keeps the text styling (i.e. bold and color) but picks up the Impress table style.

Raises the question--I'm not clear should pasting an RTF retain fidelity to its source style(s)? If answer is no--then believe we are good. Otherwise, may need more development.
Comment 36 bug102921 2017-01-25 08:13:32 UTC
Created attachment 130669 [details]
RTF is present, LO don't show/use it

In 5.2.4 sill present. Please fix it.
Comment 37 V Stuart Foote 2017-01-25 14:14:39 UTC
(In reply to bug102921 from comment #36)
> Created attachment 130669 [details]
> RTF is present, LO don't show/use it
> In 5.2.4 sill present. Please fix it.

Currently patched in master, e.g. 5.4.0--testing using current daily build is appreciated. Otherwise, when and if a backport is prepared it will be reflected in the Whiteboard status. Please check back.
Comment 38 Buovjaga 2017-02-12 13:11:46 UTC
*** Bug 105820 has been marked as a duplicate of this bug. ***
Comment 39 V Stuart Foote 2017-02-15 03:59:55 UTC
*** Bug 105997 has been marked as a duplicate of this bug. ***
Comment 40 Mike Kaganski 2017-02-19 07:07:10 UTC
Hm, seems that commit notification was missing. As already stated in whiteboard, the patch was backported to 5-3: https://cgit.freedesktop.org/libreoffice/core/commit/?id=a6f3ca06100bc23eee5017d6cf53e89282dc580d.
Comment 41 Samuel Mehrbrodt (allotropia) 2017-07-05 07:57:23 UTC
Can we close this bug as FIXED then?
Comment 42 johngr.kroeze 2017-07-06 05:35:23 UTC
No, it should not be closed as the latest version on the web page (5.3.4)  still will not allow me to paste Greek or Hebrew fonts into an English document. John.
Comment 43 Mike Kaganski 2017-07-06 06:28:25 UTC
(In reply to johngr.kroeze from comment #42)

What makes you believe that your problem is this bug? Doesn't your version have "Paste as - Formatted text (RTF)" option, while 5.1 had it for the same operation?

To be specific: with Version: (x64)
Build ID: 962a9c4e2f56d1dbdd354b1becda28edd471f4f2
CPU threads: 4; OS: Windows 6.19; UI render: default; 
Locale: ru-RU (ru_RU); Calc: group

and attachment 127786 [details], I can successfully paste text copied from the PDF (Adobe Acrobat Reader DC) with formatting (the RTF is used by default). That was impossible with 5.2 and 5.3.0, so I think that this bug is fixed, and your problem should be discussed in a new issue (please create one with proper description and steps to reproduce, including test document if required for reproduction).

Comment 44 Alex Thurgood 2017-09-20 15:34:52 UTC
(In reply to Mike Kaganski from comment #43)

> Closing as RESOLVED FIXED.

@Mike : that is unfortunate, as a corresponding bug (bug 109343) affecting Mac is still not fixed...