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.
Paste Special > HTML (or plain and convert) => Worksforme.
(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.
Sounds like bug 37223
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.
(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.
After fixing bug 115574, pasting from Excel to Writer now works differently (in this regard) to pasting from Calc to Writer.
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.
Valid enhancement request. Best regards. JBF
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?
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.
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.
Why don't we keep the order in the list and just select the right item?
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.
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?
(In reply to Jan Holesovsky from comment #14) > Is that acceptable? Definitely! :-)
(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
(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
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.
Created attachment 154652 [details] test ODS
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.
(In reply to Timur from comment #20) > But why both RTF and RichText, what's the difference? Please explain.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d8be929f4cbb2fe16a366ef146be29955715fa2f tdf#116685: sw: Add UItest It will be available in 7.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.