Created attachment 170861 [details] Example file from Writer Attached document contains a simple, centered table with a few rows. When a user copies the first row and inserts it in the second rows first cell (and not at the beginning of it), a nested table is inserted. This is partially visible on screen, as much as it fits in the first cell of the second row. In the print dialog however the whole nested table is visible, overlapping the margin and second column. Note: There are simpler solutions to achieve what the user wanted, such as Table toolbar – Rows above/Below or Right click – Paste Special – Rows above, but they found the most intuitive yet somewhat broken method available. Steps to reproduce: 1. Open attached file 2. Select and copy the first row of the table 3. Go to the first cell of the second row and paste under “Hello World1” 4. Ctrl-P to see it in print preview Actual results: A nested table is inserted and overlaps neighboring areas. Expected results: Screen and print view should match. LibreOffice details: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 6b3f0866e9eddd5553857741862ca0d7d5b2ec2b CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: CL Also happens back to 5.0, but not yet in 4.4 Additional Information: Bibisected using bibisect-win32-5.0 to: URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=7600a2942ce2b9dac66836105bed6620d55abec2 author László Németh <laszlo.nemeth@collabora.com> 2015-03-13 22:05:56 +0100 committer László Németh <laszlo.nemeth@collabora.com> 2015-03-13 22:32:49 +0100 fdo#37156 insert table copy as nested table in non-starting cell position Before this change the whole row was overwritten and print view was okay. This behavior change likely just uncovered something pre-existing.
Created attachment 170862 [details] The file before copying a row as nested table.
Created attachment 170863 [details] Screenshot of the problem in Writers Print dialog
I confirm it with Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 807d059d99e7b99fe45a712428befa17ffa44858 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
Side note: Just checked what happens in Word. In the first column of the table, the copied row is inserted as a new row above. In other columns of the table, the copied row is inserted to overwrite existing cell contents and adds a new column to the table. I guess we could go towards what our user wanted: insert a new row above, like the "Right click – Paste Special – Rows above" command does. This would avoid loss of existing data and bad look in the print view.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b97116791047f89b768ab4aa8126e543df826be3 tdf#141391 sw: don't paste as nested table in first cell paragraph 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.
The committed patch fixes the original problem for the typical UX regression: positioning text cursor not exactly at beginning of the cell content resulted not intended nested table insertion (which has also a printing problem, too). If it needs to solve the secondary problem, the printing difference at nesting extreme long table, I suggest to file that again. Commit description: tdf#141391 sw: don't paste as nested table in first cell paragraph Paste table content overwrote cells of the row(s) only if the text cursor was at the beginning of the table cell, otherwise the table cells on the clipboard were inserted as a nested table. This was a UX regression from commit 7600a2942ce2b9dac66836105bed6620d55abec2 "fdo#37156 insert table copy as nested table in non-starting cell position" especially when the user clicked not exactly at the beginning of a cell, which containing a 1-line text or data. Since commit 1e278d1d0cfb1d5375195aa764739f00633f21e8 "tdf#37156 Writer menu: Paste as Nested table" it's possible to force nesting (but not overwriting yet), this commit revert partially commit 7600a2942ce2b9dac66836105bed6620d55abec2: if the text cursor is there in the first paragraph of the cell, Paste table content overwrites the row, not embedding a nested table in the cell at the cursor position. This change results also better interoperability with the existing document editors. Note: table and text selection were checked with the change, too. Details: Heuristics to allow copying table rows or nesting tables without using Edit -> Paste Special -> Paste as Nested Table: At "table selection" (i.e. when cell(s) completely selected), or if the text selection starts in the first paragraph, or if there is no selection and the text cursor is there in the first paragraph, overwrite content of the cell(s). Otherwise insert a nested table, i.e. if nothing selected and the cursor is not in the first paragraph, or the selected text doesn't contain the first paragraph of the cell.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/f0254aaea7d4a6a261731f76c99cb06f1b5ab2b1 tdf#141391 sw: don't paste as nested table in first cell paragraph It will be available in 7.3.4. 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 in: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 67d8c245daf7c6ee33e908255f2bbd0ea8d08206 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: hu-HU (hu_HU); UI: en-GB Calc: CL