Cannot copy a table from LO Calc to LO Writer

English
, , ,
#1

So I have a 3x10 Table on LO Calc, with each cell holding a certain value.
I create a 3x10 Table on LO Writer and highlight the selection. I have tried regular paste and all options from “Paste Special”. Unfortunately, none of them actually produces a table with the values properly corresponding to each cell.

This is the table on LO Calc:
image

This is the table on LO Writer:
image

Is this feature even supported? OnlyOffice and MS Excel/Word accomplishes it with just regular copying.
I appreciate your assistance to this matter.

LO Version:

Version: 25.8.6.2 (X86_64)
Build ID: 580(Build:2)
CPU threads: 16; OS: Linux 6.19; UI render: default; VCL: kf6 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded

#2

In your example:

  1. Select cells A1:C10 of the Calc document sheet and copy to the clipboard (Ctrl + Ins).
  2. Create a new text document and paste from the clipboard (Shift + Ins).
    Result:
    2026-04-19 140810 
Version: 25.8.4.2 (X86_64)
Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df
CPU threads: 6; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL threaded
#3

Here LO 25.8.6.2 under Fedora 43, KDE Plasma desktop

After copying my selection in Calc, I just paste it over the first cell in the Writer table and all data is there.

Note that I didn’t check if formulas were exactly transferred or just the values (Writer and Calc tables are dramatically different; Writer cells are in fact text subdocuments and only elementary functions are possible in formulas).

Note also that by default first row is styled Table Heading while all other cells are Table Contents. So expect formatting differences/discrepancies until you customise the styles or apply others.

#4

Here’s the problem: When I do this on a new document, it works flawlessly. There is already a document I am working on, and it copies nothing for some reason. Is there a table setting that might prevent this?

#5

Not that I know of.

Could you prepare a test case from your existing document? Reduce the Calc one to a “small” table. Do the same on the Writer one (one page max). Chack the problem is still present and attach both sample files.

#6

Testfail.odt (12.3 KB)

This is the document, by the way. Try to add any data from a Calc table to this file. Writer to Writer works fine. If it helps, I have converted this from a .docx file to odt earlier, but that shouldn’t be an issue. Should it?

#7

Works fine here.

Frequently leads to problems. Your style dictionary is polluted by numerous spurious character and list styles coming from DICX to ODF conversion. In this case, should not matter as far as I can see.

There may be a glitch in your Calc spreadsheet. This is why I asked to see it (or an anonymised version of it).

#8

I have recreated the document in .odt (instead of converting it) and it works. However, now I have another minor issue. In the calc table, the data has a font size of 10. In my Writer Table, the font size is also 10. Why am I getting the data in font size 12, making it look different from everythign else? This does not make sense to me. Both use the same font, by the way.

#9

Since I don’t know how your Calc data is formatted, try this in Writer:

  • select the whole table
  • Ctrl+M or Format>Clear direct formatting

This will remove direct formatting and unhide what styles dictate. If you still have a 12pt size, check configuration of paragraph style Table Contents. By default, it inherits from Default Paragraph Style which is set at 12 pt.

If your whole document is intended for 10 pt size, adjust Tools>Options, LO Writer>Basic Fonts (Western) Default setting. Otherwise, modify paragraph style Table Contents.

#10

Thank you. Unfortunately, this is making things even worse for me. Why does something completely unrelated override the font size for those cells? Those empty cells have been set to 10, and the source data is also 10. I set the “Inherit from” to “None”. The same thing still happens. What should I set “next style” to? I want the original font size to be preserved. I mean, what if that original table had different font sizes? I imagine I would have to re-arrange their sizes one by one?

I discovered another bug, by the way. If you create a nested table, and then Ctrl+Z, it will remove the formatting of 1–2 adjacent columns (which received no data, by the way) and return them to default setting, for some reason. I will document this and maybe create another thread for it.

Follow-up:
The style says the font size is 12 for all cells. If I copy data from calc where the font is 16, it turns it into 14. Setting it to 14, though, also makes them 14. Something here is extremely confusing…

#11

Don’t modify this parameter. It is relevant for text entry. When you hit Enter, you end the current paragraph and start the new one. The new paragraph will be styled according to Next style. Usually, Next style is the style itself (e.g. Body Text) and you format identically a sequence of paragraphs. In some cases, Next style is set to a different style to automate a systematic transition (e.g. from Heading n to Body Text).

Wouldn’t be the simplest procedure to insert your spreadsheet with Insert>OLE object. Formatting will be the one in effect in Calc. When you paste in Writer, the whole style machinery comes into play. OLE linking has another advantage: the “citation” in Writer is updated whenever the spreadsheet changes.

#12

But I only want the data of Calc table along with the same font style, I am copying it into a LO Writer table. Is there no setting to override the style? This seems to be creating much more problems than whatever it is supposed to fix. In OnlyOffice/MS Office this is a very straightforward procedure.

Regarding 2 other bugs I discovered:

  1. If I copy a bunch of cells from Calc and paste it into a corresponding area in Writer, the very first time it will always start the copied table data from the bottom right corner of your selection.
    However, in subsequent pastes, it pastes properly if you highlighted the cells from bottom right to top left. I think something goes wrong in the first try always, but in subsequent pastes it inserts the table to where you had the cursor selection active. Every time you Ctrl-C, the very first paste will behave differently like this.

  2. I have been noticing this bug for 3 years already. You have a table with multiple columns. You insert something and unrelated columns’ data gets formatted back to default font style and size. In this case, I paste a calc table as a “nested table”, and if I “undo” this action, 3 adjacent columns return back to “default formatting” of “Liberation Serif 12” fonts.

Do you think it is worth reporting these bugs or are they already known?
Unfortunately, none of the bugs I have reported got any acknowledgment so far. I do understand that it takes a long time, but I am not sure what their current priorities are in terms of bugfixes.
If you need more info about these bugs, or perhaps a recording, let me know.

#13

If your data is “simple”, i.e. common arithmetics, no “fancy” function, just do it inside Writer without an intermediate spreadsheet.

It is always worth it; otherwise developers won’t be aware of a bug in a user-specific context.

Which are their numbers? List them as tdf#123 where 123 is bug number. This automatically creates a link to the report.

#14

If your data is “simple”, i.e. common arithmetics, no “fancy” function, just do it inside Writer without an intermediate spreadsheet.

What is confusing me is how it is “decided” what is supposed to get copied. Even if the style says the size should be 12, it copies the font style from the source, it makes 14 show up as 14, 16 as 14, and 18 as 16. I just don’t understand this logic. There should be an option to choose “keep source formatting” so one won’t have to deal with this style nonsense.

Which are their numbers? List them as tdf#123 where 123 is bug number. This automatically creates a link to the report.

The numbers are tdf#162590, tdf#164240, and tdf#168856.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.