Download it now!
Bug 116685 - Copy-pasting a range of cells from Calc to Writer should produce a table by default
Summary: Copy-pasting a range of cells from Calc to Writer should produce a table by d...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:6.4.0
Keywords:
Depends on:
Blocks: Paste Writer-Tables-Enhancements
  Show dependency treegraph
 
Reported: 2018-03-28 16:51 UTC by Aron Budea
Modified: 2020-08-22 23:41 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
test ODS (9.38 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-09-30 09:51 UTC, Timur
Details
test compared in LO before and after and MSO (156.27 KB, image/png)
2019-09-30 10:01 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2018-03-28 16:51:36 UTC
Copy-pasting cells from Calc to Writer creates an embedded spreadsheet by default. This, while might be useful in some cases, is rarely what users want.

Not only that, the other paste options (namely HTML and Formatted Text (RTF)) don't produce anything that is like a normal table in Writer:
-they have grey borders instead of black,
-they don't have automatic alignment.

I'd expect the default paste option to produce a table that looks close to the original (in terms of formatting), but is based on the style of a Writer table.
Comment 1 Heiko Tietze 2018-03-28 16:53:10 UTC Comment hidden (obsolete)
Comment 2 Aron Budea 2018-03-28 17:17:04 UTC
(In reply to Heiko Tietze from comment #1)
> Paste Special > HTML (or plain and convert) => Worksforme.

1. It's not the default paste.
2. It doesn't look close enough like a Writer table.
Comment 3 Telesto 2018-03-28 17:38:09 UTC Comment hidden (obsolete)
Comment 4 V Stuart Foote 2018-03-28 18:54:20 UTC
There is no means to paste data into an existing table--that is bug 37223 and/or bug 95741

Copy -> Paste from Calc to Writer by default pastes a Calc8 OLE object.

Copy -> Paste Special DDE, or HTML will paste either active DDE content, or HTML table which picks up Writer templates "Default Style" table. The style can then be changed.

Point here is that you _can_ bring data over from Calc -- just that the default now is a static OLE object that can not be styled, with an option of DDE or HTML--either of which can be styled.

Would the HTML table be a better paste default than the Calc8 OLE? And at some point we would need to be able to modify the Default Table style.
Comment 5 V Stuart Foote 2018-03-28 19:11:54 UTC
(In reply to V Stuart Foote from comment #4)
The paste special options--RTF will also paste the selection as a table with the calc formatting--that can also be styled.

So, it is really a question of what should the default be?  Kind of agree that the calc8 OLE object is not especially helpful.
Comment 6 Mike Kaganski 2018-03-30 06:38:53 UTC
After fixing bug 115574, pasting from Excel to Writer now works differently (in this regard) to pasting from Calc to Writer.
Comment 7 Aron Budea 2018-03-30 10:02:03 UTC
We discussed this a bit with Miklos yesterday, the priority of format filters is defined here:
aEXCHG_DEST_SWDOC_FREE_AREA_Copy
https://opengrok.libreoffice.org/xref/core/sot/source/base/formats.cxx

Technically, switching the order SotClipboardFormatId::EMBEDDED_OBJ and SotClipboardFormatId::RTF fixes the precedence, but the list is more general, so it might have unwanted side effects elsewhere. Introducing a blacklist, and/or more granular priorities depending on the type of content seems to be the way forward.
Comment 8 Jean-Baptiste Faure 2018-03-31 17:34:19 UTC
Valid enhancement request.

Best regards. JBF
Comment 9 Julien Nabet 2019-09-26 14:27:36 UTC
Since it may have some side effect about UX and so may generate some bugs about behaviour change, thought it could be relevant to include Heiko and Xisco in the loop.
At least, perhaps something to put in 6.4 release notes?
Comment 10 Heiko Tietze 2019-09-27 06:39:44 UTC
I agree with the request and do always paste special to unformatted text + convert to table. Wouldn't change the list order but just not select the first element. Can't think of any side-effect with this modification.
Comment 11 Mike Kaganski 2019-09-27 07:01:23 UTC
The side effects mentioned in comment 7 are not about the workflow which this enhancement is for: the straightforward approach from that comment would modify the precedence of different clipboard formats, which could affect other copy-paste operations in unexpected places. That's why the comment mentioned the better fine-grained approach that should be implemented here, as a draft of implementation plan. That idea would allow to modify the priority for only some special cases, not affecting other operations.
Comment 12 Heiko Tietze 2019-09-27 07:07:55 UTC
Why don't we keep the order in the list and just select the right item?
Comment 13 Commit Notification 2019-09-27 07:55:15 UTC
Jan Holesovsky committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e9e6d4b058e13165f3dde1ca7822eec97dfe8aa7

tdf#116685: Make the RICHTEXT take precedence over EMBED_SOURCE.

It will be available in 6.4.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 14 Jan Holesovsky 2019-09-27 08:02:59 UTC
Oops, I had the patch from yesterday, and merged it before seeing the discussion ;-) - sorry!

But - I'd leave it in, and see if anybody complains: I was unable to come up with a scenario that fails now, as the export from Calc uses a RICHTEXT, not RTF, so the order was not changed and hopefully the impact will be low.

Is that acceptable?
Comment 15 Mike Kaganski 2019-09-27 13:22:17 UTC
(In reply to Jan Holesovsky from comment #14)
> Is that acceptable?

Definitely! :-)
Comment 16 Roman Kuznetsov 2019-09-28 08:08:00 UTC
(In reply to Jan Holesovsky from comment #14)
> Oops, I had the patch from yesterday, and merged it before seeing the
> discussion ;-) - sorry!
> 
> But - I'd leave it in, and see if anybody complains: I was unable to come up
> with a scenario that fails now, as the export from Calc uses a RICHTEXT, not
> RTF, so the order was not changed and hopefully the impact will be low.
> 
> Is that acceptable?

Pasting as native Writer table works fine. But we lost font and cell background colors, and cell borders also...

Pasting from Excel to Word native table works fine and saves all formatting of cells

Версия: 6.4.0.0.alpha0+ (x64)
ID сборки: 24c7c12224f1c1d66f335f6fe085595352137646
Потоков ЦП: 4; ОС:Windows 10.0; Отрисовка ИП: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-09-28_01:32:49
Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU
Calc: threaded
Comment 17 Roman Kuznetsov 2019-09-28 15:08:13 UTC
(In reply to Jan Holesovsky from comment #14)
> Oops, I had the patch from yesterday, and merged it before seeing the
> discussion ;-) - sorry!
> 
> But - I'd leave it in, and see if anybody complains: I was unable to come up
> with a scenario that fails now, as the export from Calc uses a RICHTEXT, not
> RTF, so the order was not changed and hopefully the impact will be low.
> 
> Is that acceptable?

Jan, would be MORE cool to make HTML as format for Calc table pasting by default.
In this case we'll be have ALL original Calc cells formatting in Writer table after pasting
Comment 18 Heiko Tietze 2019-09-29 05:59:17 UTC
Don't think any formatting is wanted here. The reason for this patch (and previous workaround with paste special) is to have a consistent layout in your Writer document with one font across paragraphs and tables. And if you want to apply a special format to tables the better way to do so is using styles.
Comment 19 Timur 2019-09-30 09:51:49 UTC
Created attachment 154652 [details]
test ODS
Comment 20 Timur 2019-09-30 10:01:11 UTC
Created attachment 154653 [details]
test compared in LO before and after and MSO

Hard to say what's best here. 
Average user would want the same look (HTML) but we my say we promote using styles so RichText as default might do.

But why both RTF and RichText, what's the difference? We need to add and update Help.

Wording in Paste is technical in LO and descriptions in MSO.
FWIS, we don't have "link AND keep styles". Link works for DDE but no styles, some weird format.
Comment 21 Timur 2019-10-10 12:39:24 UTC
(In reply to Timur from comment #20)
> But why both RTF and RichText, what's the difference? 
Please explain.