Created attachment 171362 [details] test columns/rows Hi there, I created a table with unequal column widths by merging the cells in some non-adjacent rows and then vertically splitting those merged cells into different numbers of columns. The problem occurs when adjusting the width of those columns, they snap to the width of other non-adjacent columns and as far as I can tell there is no way to separate them again. In my test document, to resize the column next to the cells with "c" and put it close to the cells with "a", and see how they snap and become linked. Try the same with all the other unequal columns and they will all eventually become linked in their width.
I tried to reproduce it based on your description, but failed. Could you attach a screen recording video, where you do it? Arch Linux 64-bit Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 3199182588fecac8a1c1fe202ca55702a3aab6ab CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 23 April 2021
Created attachment 171375 [details] screen capture video Sure, attached.
Created attachment 171376 [details] screen capture video Sorry, this is the correct attachment.
(In reply to S. from comment #3) > Created attachment 171376 [details] > screen capture video Thanks, now I get it. The behaviour is already in version 3.3.0 (tested on Win 10). It seems rather deliberate. I was unable to find older reports about it. I am sure some would say this is a feature rather than a bug, but of course it is annoying that the behaviour can not be turned off or the snapping reversed. Adding design team into the loop for all the philosophical considerations.
The content of attachment 171375 [details] has been deleted for the following reason: user request
I think the feature itself is desirable - how else would you join individual cells into a column? The question is likely the other way around and you want to split a column aka change the width of one single cell. Is this correct, S? Don't see how this works (except splitting the table and merging back after resizing). I would expect to change only selected cells if some are marked (the resize interaction is available at the horizontal ruler) but it doesn't work either.
(In reply to Heiko Tietze from comment #6) > I think the feature itself is desirable - how else would you join individual > cells into a column? The question is likely the other way around and you > want to split a column aka change the width of one single cell. Is this > correct, S? Hello, thanks for the reply. I was trying to reproduce a complex table from a physical form, and I ended up ruining it because I simply went cell by cell, merging/splitting cels and/or resizing the column width as needed, and I only use the row directly above it as a reference. But I didn't notice that at some point it had automatically snapped to cell width with another one that was many rows above it, which was wrong and didn't allow the text to fit. Sorry it's hard to explain. But I eventually saved the document and closed it and then re-opened it, and I realized that the widths of the cells in the first rows had been changed by the width of other cells many rows farther down, and I would have had to delete a bunch of information typed into each of those cells in order to merge them and split them again so that the width is independent. So, I would say that this feature is not desirable or should at least be an option that is disabled by default. Because it only applies to complex tables with very precise levels of individual cell formatting, and if the user went through so much deliberate effort to merge/split/resize cell widths (s)he probably doesn't want them to ever be linked anymore.
[Automated Action] NeedInfo-To-Unconfirmed
I still believe the other way around, snap by default and resize selected cells individually on demand, is easier than snapping per special interaction (eg with ctrl being pressed). Most users need simple tables and are accustomed to the current behavior too. Could imagine that a "cells" tab in the table properties dialog (or better an extra dialog) to enter precise values for the selected cells is needed as well.