Created attachment 126603 [details] this ODT file contains simple tables to reproduce this issue The attached ODT file contains a simple table, in which cell "f" is a merged cell. When copy-paste the table in a Calc file (as formatted RFT text), the cells are placed in wrong position. It is noted that it works OK when the merged cell is in the first column. Version: 5.3.0.0.alpha0+ Build ID: 9dc3356f1499a2b90078be86ca7470eb2e96aba8 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-07-21_23:52:45 Locale: zh-CN (zh_CN); Calc: group Version: 5.2.0.3 (x64) Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Locale: zh-CN (zh_CN) This issue was initially reported in the LibreOffice Chinese Forum: http://www.libreofficechina.org/thread-1542-1-1.html
reproduce: OS: xubuntu 16.04(x64) LO: Version: 5.1.4.2 Build ID: 1:5.1.4-0ubuntu1 CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; Locale: zh-CN (zh_CN.UTF-8)
bibisect-release bibisect results suggests that the bug started from libreoffice-4.0.0.0.beta1. Added keyword "regression". 4f2186cd72652db35eebe5b1b9d3693723433b85 is the first bad commit commit 4f2186cd72652db35eebe5b1b9d3693723433b85 Author: Matthew Francis <mjay.francis@gmail.com> Date: Tue Apr 14 22:40:46 2015 +0800 libreoffice-4.0.0.0.beta1 LibO-Dev_4.0.0.0.beta1_Linux_x86-64_install-deb_en-US.tar.gz :040000 040000 e6812e3e351d23e270d6424988196d6208d95b5d 34c7fa1c93970d74dd4dc1bd5706704ffb0b0a9e M opt git bisect log # bad: [e992b5c0217fbbfaed351e4898b8c751ae2fe90e] libreoffice-4.4.7.2 # good: [52afdea50650697a791234f22d2cf2147498b06e] libreoffice-3.3.0 git bisect start 'libreoffice-4.4.7.2' 'libreoffice-3.3.0' # bad: [33d0c0cac4bfc14221f2a665735e125f446f3251] libreoffice-4.1.3.2 git bisect bad 33d0c0cac4bfc14221f2a665735e125f446f3251 # bad: [4f2186cd72652db35eebe5b1b9d3693723433b85] libreoffice-4.0.0.0.beta1 git bisect bad 4f2186cd72652db35eebe5b1b9d3693723433b85 # good: [4a9bc438d62f90e8bf687683d854c3a044397505] libreoffice-3.5.3rc2 git bisect good 4a9bc438d62f90e8bf687683d854c3a044397505 # good: [ac15b75361b54e9d29f2ed9e3203b731fd0a0d29] libreoffice-3.6.2.2 git bisect good ac15b75361b54e9d29f2ed9e3203b731fd0a0d29 # good: [f4b2466b27f7d7d13b71213a534a8f01dfa1805b] libreoffice-3.6.6.1 git bisect good f4b2466b27f7d7d13b71213a534a8f01dfa1805b # good: [208dc7bb206c4f313021c2fb045b165638921b9e] libreoffice-3.6.7.1 git bisect good 208dc7bb206c4f313021c2fb045b165638921b9e # good: [2ba8a27cc4f9f01e531e73760f6c3f6505999be5] libreoffice-3.6.7.2 git bisect good 2ba8a27cc4f9f01e531e73760f6c3f6505999be5 # first bad commit: [4f2186cd72652db35eebe5b1b9d3693723433b85] libreoffice-4.0.0.0.beta1
Added another "bibisectRequest" keyword, we need someone with the old "43all" bibisect repo to narrow down the range.
Bibisect with repo bibisect-43all. 80860139a96019d7487e02c7b488a8990e1e524f is the first bad commit commit 80860139a96019d7487e02c7b488a8990e1e524f Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon Dec 10 03:22:19 2012 +0000 source-hash-27d3fc221d042decbd84b72719107547562d2e12 commit 27d3fc221d042decbd84b72719107547562d2e12 Author: Michael Stahl <mstahl@redhat.com> AuthorDate: Thu Jul 26 15:53:28 2012 +0200 Commit: Michael Stahl <mstahl@redhat.com> CommitDate: Thu Jul 26 15:54:50 2012 +0200 warning C4018: '>': signed/unsigned mismatch Change-Id: I25607ce79111b2c2933ab5e2c165df0594ed4363 # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect good 369369915d3582924b3d01c9b01167268ed38f3b # good: [6fce03a944bf50e90cd31e2d559fe8705ccc993e] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 git bisect good 6fce03a944bf50e90cd31e2d559fe8705ccc993e # good: [da317333e5675622f55c9dda17396c659af65320] source-hash-15af925c254f27046427de70a59011e2ac3d6bdb git bisect good da317333e5675622f55c9dda17396c659af65320 # bad: [18518588d8414f446ece5591944766f5082ebef5] source-hash-82c25249e624cb54ca6d3293d1c3d0d8ebc208e0 git bisect bad 18518588d8414f446ece5591944766f5082ebef5 # good: [89740762f0af849e492932bd71e59149cdcd5a00] source-hash-06f20d73da21342046a480a6b22af69901351328 git bisect good 89740762f0af849e492932bd71e59149cdcd5a00 # good: [a429a2e082aeb9bff36833603d8deb55385c7905] source-hash-b8fa8841c098f15ef2280aa4c82c55c4f96325c9 git bisect good a429a2e082aeb9bff36833603d8deb55385c7905 # bad: [80860139a96019d7487e02c7b488a8990e1e524f] source-hash-27d3fc221d042decbd84b72719107547562d2e12 git bisect bad 80860139a96019d7487e02c7b488a8990e1e524f # good: [489397741e799a5ad767e4b12be827c8c96ba60b] source-hash-50b4cbe94e200288d57a135bc9386012164bc726 git bisect good 489397741e799a5ad767e4b12be827c8c96ba60b # first bad commit: [80860139a96019d7487e02c7b488a8990e1e524f] source-hash-27d3fc221d042decbd84b72719107547562d2e12
This is the range of commits resulting from bibisect with bibisect-43all: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=50b4cbe94e200288d57a135bc9386012164bc726..27d3fc221d042decbd84b72719107547562d2e12
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still repro in Version: 6.2.0.0.beta1 (x64) Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL
Bug still exists in version 版本: 7.0.0.0.alpha0+ Build ID: 0a6ec034dc8088d9de399142bb193ae7d338e645 CPU 线程: 4; 操作系统: Linux 5.4; UI 渲染: 默认; VCL: gtk3; 区域语言: zh-CN (zh_CN.UTF-8); UI 语言: zh-CN Calc: threaded Fedora 31 x64.
reproducible in: Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Still reproducible on today's master after the fix for bug 74577.
Dear Kevin Suo, 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 reproducible on Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ffccbf4762a9ae810bcdd21c41fccdd436e7bfc9 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Calc: threaded
For those who are interested, this may be due to sth wrong in the sc RTF parser in ScRTFParser::SeekTwips() or ScRTFParser::ColAdjust() https://opengrok.libreoffice.org/xref/core/sc/source/filter/rtf/rtfparse.cxx?r=4790ef5c
I have doing some debugging and have found the following, but I don't think I can fix this, so could someone take a look: The code works for the Writer table like this: +---+----+----+ |a |b |c | +---+----+----+ |d |e | +--------+----+ But does not work for a Writer table like this: +-------+----+----+ |a |b |c | +---+---+----+----+ |d |e |f |g | +---+---+----+----+ The difference between the two tables is that: - In the first table, the 2nd row contains the merged cell. The right border for *each* of the cells ("d" and "e") has a corresponding aligned border in its top row (i.e. the right border of cells "b" aligns to the right border of cell "d", and the right border of cell "c" aligns to the right border of cell "e"). In such case, ScRTFParser::SeekTwips successfully finds the "nTwips" through the following code, for each of the "d" and "e" cells: ScRTFColTwips::const_iterator it = aColTwips.find( nTwips ); bool bFound = it != aColTwips.end(); sal_uInt16 nPos = it - aColTwips.begin(); *pCol = static_cast<SCCOL>(nPos); if ( bFound ) return true; -- In the second table, the 1st row contains the merged cell. The right border of "d" in the 2nd row does not have a corresponding aligned border in the 1st row (i.e. its top row), thus ScRTFParser::SeekTwips failes to find the "nTwips" through: ScRTFColTwips::const_iterator it = aColTwips.find( nTwips ); bool bFound = it != aColTwips.end(); sal_uInt16 nPos = it - aColTwips.begin(); *pCol = static_cast<SCCOL>(nPos); so it goes on to: SCCOL nCol = *pCol; // nCol is insertion position; the next one higher up is there (or not) if ( nCol < static_cast<SCCOL>(nCount) && ((aColTwips[nCol] - SC_RTFTWIPTOL) <= nTwips) ) return true; *Note* that aColTwips is always the list of right border twips of the cells in the first row, and is not updated upon the rows that followed. (i.e, for the 2nd table, aColTwips always has 3 elements which are the twips of the first row cels). At this moment *pCol is 3 because after the "find" the iterator is at the aColTwips.end(). the *pCol 3 is then passed to its caller "SeekTwips( pE->nTwips, &nCol )" in ScRTFParser::ColAdjust(), in which the column count grows to 6, and the pasted result in Calc becomes: +-------+----+----+ |a |b |c | +-------+---------+---+----+----+ |d |e |f |g | +-------+---------+---+----+----+
After two days of work installing an old EOL Fedora 17 and setting up the build environment, I was able to finally build the old libreoffice code and start bisect based on the bibisected range of 50b4cbe94e200288d57a135bc9386012164bc726..27d3fc221d042decbd84b72719107547562d2e12 shown in comment 5. This regression is now confirmed to be caused by: commit ed24564ce11683731b820c29d5a46e073ab7a2a7 Author: Noel Grandin <noel@peralex.com> Date: Thu Jul 19 15:22:31 2012 +0200 SV_DECL_VARARR_SORT(ScRTFColTwips) o3tl::sorted_vector Adding keyword "bisected". Adding Noel Grandin to cc: would you please take a look? Thanks in advance.
*** Bug 132628 has been marked as a duplicate of this bug. ***
Thanks Kevin for the hard work of bisecting. Fix is here: https://gerrit.libreoffice.org/c/core/+/163518
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4df426e429e1aed92f074d8acd3ba3a5ec335ba9 tdf#101313 Copy-paste table from writer to calc It will be available in 24.8.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/034f6c29c309561e75719142c305245ac19f7ba9 tdf#101313 Copy-paste table from writer to calc It will be available in 7.6.6. 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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/b5a5cae0e78e989c421a376bb55a724981c74d87 tdf#101313 Copy-paste table from writer to calc It will be available in 24.2.2. 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.
Verified fixed on master.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d0ced35e7a3e2921febe6dacc42fa5d1390b2846 tdf#101313: sw: Add UItest It will be available in 24.8.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-24-2-1": https://git.libreoffice.org/core/commit/7564f8651012ed0cbfbe6d37cd4effba308a2cd4 tdf#101313 Copy-paste table from writer to calc It will be available in 24.2.1. 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.