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
also when i copy/paste from MS Wordpad to writer 5.2 it loses bold and italics.
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.
with version 18.104.22.168 still broken
i reverted to 22.214.171.124 and pasting with formatting works correctly
It's still broken with 5.2.2.
Created attachment 127786 [details]
PDF for testing
Copy from this to test.
Win 7 Pro 64-bit Version: 126.96.36.199.alpha0+
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
I downloaded your pdf file and did a copy paste into a Writer document in 188.8.131.52 and neither the bold nor the italics were preserved.
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 184.108.40.206 (Build ID: e183d5b)
on 220.127.116.11 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
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:
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99
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.
Adobe reader DC 2015.017
also the loss of formatting issue happens when i paste from microsoft wordpad to libre writer
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 <email@example.com> 2016-03-09 15:19:51 (GMT)
committer Oliver Specht <firstname.lastname@example.org> 2016-03-10 10:11:04 (GMT)
commit 36bf13247b01075b533b127c7e5ffc760f9642f8 (patch)
parent 416526cfa382d3482042f3c917bcb2bfa178402a (diff)
tdf#97591: mark RTF clipboard format as text/rtf
git bisect log
# bad: [6380ca07b05f68dedcaa379302cfe1fa478571c4] source sha:60b74fe1775e647545d2da1fcc58a4c63ec18aa5
# good: [1f670510f08cb800cbae2a1dd6ea70d3542e4721] source sha:49c2b9808df8a6b197dec666dfc0cda6321a4306
git bisect start 'origin/master' 'oldest'
# good: [38f37b8ec1a2d199bb957cfd2581df7d1b273b74] source sha:c0da1080b61a1d51654fc34fdaeba373226065ff
git bisect good 38f37b8ec1a2d199bb957cfd2581df7d1b273b74
# bad: [11ae494d8c566f23e0ef84ba0cc25fb1388b67f7] source sha:470cfa9860232ab70e017e6084d80f80d469555c
git bisect bad 11ae494d8c566f23e0ef84ba0cc25fb1388b67f7
# bad: [d247d25062e6cc4afccdc3c4be84a2b98523b36a] source sha:150c1dcab007dd8acc1551791f42eef692f9e531
git bisect bad d247d25062e6cc4afccdc3c4be84a2b98523b36a
# good: [dc23450cfb87b61fcbd905a7079d8a0d32759e6b] source sha:5c1234eac2b9f3a3ea032e4828a15bedca6b9ebe
git bisect good dc23450cfb87b61fcbd905a7079d8a0d32759e6b
# bad: [3c06b49a11643ee6e22d8184f65dcc129ceb586d] source sha:42d6a165b053ebdccbd6979eb849b1abe305d2ba
git bisect bad 3c06b49a11643ee6e22d8184f65dcc129ceb586d
# good: [ae20ff1c2de6ecec64f34a839a82f6dfd00f5ac5] source sha:70fca3e901e41fa52589eb3f06e6839c4a8582de
git bisect good ae20ff1c2de6ecec64f34a839a82f6dfd00f5ac5
# bad: [6d7499abfffe460a5f7013564141cc51dbc39e87] source sha:127fbac23afa1fc94dd7f8aae390e1ff55ed5d64
git bisect bad 6d7499abfffe460a5f7013564141cc51dbc39e87
# bad: [ead1e6d2162bca106369cec08b6bac34610626dc] source sha:a3fcf5a3b8ea26c289b12216d7f8fdb7e07814b7
git bisect bad ead1e6d2162bca106369cec08b6bac34610626dc
# good: [76ec908f8aa5824caac5af760b0b866e1bb0720b] source sha:3d82b08bcea45408b1998934558e2e28721125df
git bisect good 76ec908f8aa5824caac5af760b0b866e1bb0720b
# bad: [d644a4e4923dfa3b358bbb64eeb77baab7defeb4] source sha:51d1fca2041ba4478c5abae59b1ed4fee37ea1ee
git bisect bad d644a4e4923dfa3b358bbb64eeb77baab7defeb4
# bad: [e9331335bf8aa1bad7e9846fc91393f07d3648ef] source sha:5c4717416b7eeaf99765725785278a7437fdaf8a
git bisect bad e9331335bf8aa1bad7e9846fc91393f07d3648ef
# bad: [81cc3639fe6b1ba719ad6e0419fe516d09bcae78] source sha:36bf13247b01075b533b127c7e5ffc760f9642f8
git bisect bad 81cc3639fe6b1ba719ad6e0419fe516d09bcae78
# good: [e40edc1a88bcd94f34a0ecb58a9f0c6fdebbb86c] source sha:416526cfa382d3482042f3c917bcb2bfa178402a
git bisect good e40edc1a88bcd94f34a0ecb58a9f0c6fdebbb86c
# first bad commit: [81cc3639fe6b1ba719ad6e0419fe516d09bcae78] source sha:36bf13247b01075b533b127c7e5ffc760f9642f8
*** Bug 101150 has been marked as a duplicate of this bug. ***
*** Bug 102921 has been marked as a duplicate of this bug. ***
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.
*** Bug 102547 has been marked as a duplicate of this bug. ***
Kind of both a bump and a report that this problem still exists in 5.3 alpha (Windows 10; 64-bit)
*** Bug 104012 has been marked as a duplicate of this bug. ***
*** Bug 103860 has been marked as a duplicate of this bug. ***
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?
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.
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.
*** Bug 104917 has been marked as a duplicate of this bug. ***
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.
Hi Xisco, no need to, the following gerrit patch fixes the bug once it's merged:
*** Bug 105007 has been marked as a duplicate of this bug. ***
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
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.
5.3 is an RC now. so in a year we will see the 5.4 fix!!!
how about the 5.3 branch too??
(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.
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.
*** Bug 105340 has been marked as a duplicate of this bug. ***
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.
Created attachment 130669 [details]
RTF is present, LO don't show/use it
In 5.2.4 sill present. Please fix it.
(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.
*** Bug 105820 has been marked as a duplicate of this bug. ***
*** Bug 105997 has been marked as a duplicate of this bug. ***
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.