Description: I have made a table in Writer and been using simple drawings on the left hand side beside the table. Simple electrical drawing like fuse, switch etc. These drawings are "connected" to table rows where the description is written. Occasionally when adding new rows to table, increasing the text of the table cell so that it expands to next row within the cell or adding/moving drawings on the left hand side, usually, one line (there are multiple lines but seldom more than one is affected) can move to a quite much different place. Seems that the line is somehow linked to the table and when that changes, the line changes (position - not line dimensions). Usually line moves vertically but I've seen it moving horizontally as well. I can move the line back to its place with mouse but it's very annoying to do this unnecessarily just because table content has been modified. Not sure if it means anything in relation to this but when I select a line I cannot move it horizontally with cursor keys. Vertical movement moves in large jumps only. Would be really nice to do fine tuning with keys instead of mouse. Don't recall how long this issue has been there but very long. I'm updating LibreOffice every now and then so many versions have been tried over the years. Steps to Reproduce: 1. Create a table (e.g. 5 columns, 20 rows) 2. Merge rows of the first column 3. Create drawing like electrical switch (horizontal illustration) of multiple lines 4. Move drawing to the first column so that horizontal line touches 2nd column table row border 5. Add copies of drawings connected to other rows or make different drawings 6. Modify table: increase text in line connected rows so that the row expands to 2nd, 3rd etc. line (cell height increases). Add rows, remove rows. Actual Results: One or more lines of a single drawing can jump to a different place (typically only horizontally). Expected Results: Drawing remains intact despite the changes in the table. Whole drawing may need to be moved manually to e.g. centre of the table row to maintain good outlook. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.beta2 Build ID: 00(Build:0) CPU threads: 16; OS: Linux 5.7; UI render: GL; VCL: kf5 Locale: fi-FI (fi_FI.utf8); UI: en-US Calc: threaded
A sample file (preferred) and/or screencast would be really helpful
Created attachment 162689 [details] Example file of jumping connector line Attached a file where jumping happens (a copy of part of larger diagram). Arrow points to a connector which at least jumps. Select connector and try to move vertical line to e.g. right. In my computer the line appears roughly 2cm on the left of the original position i.e. no where near where it should be.
Created attachment 162690 [details] Screenshot Screenshot of the line. This shows rerouted line as preview but still the line moves to pointer where mouse points (like it should). Interestingly enough, tried to move the line from box #2 to IN+ similarly (vertical part of the line). Preview was showing new route and was static all the time. Line moved to position where I released mouse but then the line got also disconnected from IN+ connector point. Undo did not reconnect it either so there's another issue apparently related to same connector line routing, preview etc. issue.
Filed two bugs and these attachments are for the other one (https://bugs.documentfoundation.org/show_bug.cgi?id=134500). Can someone move them? Sorry for the mistake.
Created attachment 162691 [details] Exanoke of text removal from cell removes also part of drawing See example 1: - removing yellow highlighted text (character by character or all at once - doesn't matter) from the cell removes also part of the diagram that is linked to the row (fuse part)
Created attachment 162692 [details] Moving line example Example 2: - adding more text to the yellow highlighted cell causes line to move (Affected row) downwards. Not the whole drawing but part of it (horizontal line).
For example 2 same happens also when adding text to cell below yellow highlight cell.
And another bug from the same example file. CTRL+A behaves erratically, in my opinion. - Step 1: Go to any cell and CTRL+A. All cells in table selected. Fine. - Step 2: Click at the bottom of the page outside table (cursor moves outside table). CTRL+A and something gets selected and immediately deselected (flicks). CTRL+V doesn't paste anything to a new document. - Step 3: In step 2 repeat CTRL+A twice and then everything gets selected. CTRL+V to a new document and part of the drawing is missing. Text is copied but not all drawings.
Created attachment 162694 [details] Bug is copying Screenshot of the copy bug. Not all gets copied.
(In reply to Pasi from comment #5) > Created attachment 162691 [details] > Exanoke of text removal from cell removes also part of drawing > > See example 1: > - removing yellow highlighted text (character by character or all at once - > doesn't matter) from the cell removes also part of the diagram that is > linked to the row (fuse part) I confirm it with Version: 7.1.0.0.alpha0+ (x64) Build ID: 52820b52b3bca45e2db527d1cc5f4488b2e0b9d0 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded Shapes are anchored to paragraph in highlighted table cell. I f you remove all characters of the paragraph, shapes are removed. I won't expect this, because paragraph is still there.
(In reply to Pasi from comment #6) > Example 2: Not a bug. In this example, the horizontal line is anchored to a paragraph in the table. When you add text to a row, the position of the anchor in the table is moved down, and the horizontal correctly moves with the anchor. If you, for example, anchor that horizontal line "to page", then adding text to the table will not move the line.
(In reply to Dieter from comment #10) > Shapes are anchored to paragraph in highlighted table cell. If you remove > all characters of the paragraph, shapes are removed. Isn't this case bug 146445?
(In reply to Pasi from comment #8) > And another bug from the same example file. CTRL+A behaves erratically, in > my opinion. Please file another ticket for this issue. The tradition with Bugzilla is to file one problem per ticket, where the original report here was about "moving lines", which I believe is NOTABUG. (similarly the problem in example 1 reflects another ticket which was resolved as WONTFIX). Before filing a new ticket, you might want to search a little in Bugzilla, because it is possible that there is already a report about Ctrl+A with a mixture of shapes, tables, and text not copying everything.