Description: 1. Create a table with 5 columns and 3 rows. 2. Notice that the columns have the same width. 3. Remove column 3. 4. Notice that columns aren't the same width anymore. Before: |------------|------------|------------|------------| After: |------------|-------------------|------------------| Expected: |----------------|-----------------|----------------| Steps to Reproduce: - Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info:
Basically I agree with the request. One option is to introduce a new function/command "Distribute evenly". But we should try to keep code base and UI clean. So it could be realized as macro and maybe distributed per third-party extension. But there is also the option "Adjust columns proportionally" (Table Properties > Columns, disabled for "Automatic" alignment (under the Table tab). So far this checkbox controls only the UI interaction, meaning when checked it shares the width over some columns. This works far from what user expects (see bug 111421 and bug 100537) but could be improved and made persistent. It would remain checked and when columns are deleted the col width gets recalculated. See also bug 41817.
(In reply to Heiko Tietze from comment #1) > One option is to introduce a new function/command "Distribute evenly". The command "Distribute columns evenly" already exists. The only issue is that it doesn't work automatically. 5. Select all table with Ctrl-A. 6. Open its context menu. 7. Select "Size" > "Distribute Columns Evenly".
(In reply to John from comment #2) > The command "Distribute columns evenly" already exists. The only issue is > that it doesn't work automatically. Oh yes, forgot this. So it's a bug not an enhancement request (automatically resize after deletion).
(In reply to Heiko Tietze from comment #3) > (In reply to John from comment #2) > > The command "Distribute columns evenly" already exists. The only issue is > > that it doesn't work automatically. > > Oh yes, forgot this. So it's a bug not an enhancement request (automatically > resize after deletion). No - I don't think it is a bug. "Distribute columns evenly" is a command, not a setting. It is an action that the user can take every time he wants to "rebalance" the table. So you are back to the suggestion about adding an option to keep the table columns balanced. In general, I don't think that is necessary (unless ODF already has a specification that a table should do this). Designing tables is a user task, not a computer task. It is easy enough to re-balance the table once the infrequent "design change" is finished.
(In reply to Justin L from comment #4) > So you are back to the suggestion about adding an option to keep the table > columns balanced. In general, I don't think that is necessary (unless ODF > already has a specification that a table should do this). Designing tables > is a user task, not a computer task. It is easy enough to re-balance the > table once the infrequent "design change" is finished. Let me try to suggest a "compromise suggestion", which may satisfy both @John's initial expectation and agree with what you (@JustinL) have written. I believe John was expecting a rebalancing of widths based on that fact that he had not explicitly set the width of any column, nor done anything else to countermand his initial expressed wish of equi-distributed columns. So, one could argue that, for the special case of columns whose last width setting was an equi-distribution, a deletion could be expected to equi-distribute among the remaining columns; but in any other situation, only the two surrounding columns would gain width as is the current behavior. I'm personally of two minds regarding what I would feel meets my expectations as a user. Anyway, rephrased the title to better express what John seems to ask for.
Dear John, 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