Created attachment 160271 [details] table in odt When copy table with merging cells from Writer to Calc, the table losses its overall layout. Please see the attached files. Try to copy the table from Writer to Calc.
Created attachment 160272 [details] Calcu output after paste the table
Reproduced in 6.4.4 RC1: 版本: 6.4.4.1 (x64) Build ID: b50bc319eca5cd5b66fbfe2ebd0d3bd1eed099b5 CPU 线程: 2; 操作系统: Windows 10.0 Build 18363; UI 渲染: 默认; VCL: win; 区域语言: zh-CN (zh_CN); UI 语言: zh-CN Calc: threaded
According to bug 98440, copying merged cells doesn't even work from one part of a table to another part inside Writer, so no surprise it dosn't work from Writer to Calc either.
Ming Hua, I tried to copy the table from Writer to a new Writer and no problem. But of course, the bug is still active with pasting to Calc. I retested the bug. REPRO in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2f4f4cbeb8e50081d607b86b0475b93971c40ab8 CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Dear Zayed, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still exist in version: 7.6.4.1 (X86_64) / LibreOffice Community
The problem seems to depend on where exactly the merged cells in the original Writer table are located in relation to the selected area to be copied. So, for instance, a writer table such as: | a1 | b1 | c1 | | a2&b2 | c2 | | a3 | b3 | c3 | ... should be pasted correctly on Calc. But when selecting in the same Writer table only from cell A2 (merged with B2) to cell C3 and only copying that partial area, the pasted result is incorrect, with the original cell A3 being merged with B3 in the resulting Calc area and the rest of the cells in the same row shifted to the right. This is just one example. Similar inconsistencies can be seen when the merged range is located in the last selected column (as in attachment 160271 [details] from comment 0), compared to having additional columns (to the right) after the merged cells. IOW, the location of the resulting merged attribute in Calc depends on the location of the merged cells in relation to the selected area in Writer, which is evidently a bug. This is especially noticed when the merged area is located on the "limit" of the selected area in the Writer's table (but not necessarily only in such cases).
*** This bug has been marked as a duplicate of bug 101313 ***