Bug 111421 - Option to set all columns of a table proportinally is not accessible
Summary: Option to set all columns of a table proportinally is not accessible
Status: RESOLVED DUPLICATE of bug 100537
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
Depends on:
Reported: 2017-08-06 20:38 UTC by Adalbert Hanßen
Modified: 2017-08-12 11:56 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Adalbert Hanßen 2017-08-06 20:38:16 UTC
This problem also pertains to version 6 under development:

I have a table in Writer with a lot of columns (i.e. >6). I want to set the width of all columns to be equal. 

But I can not access the upper two choices in the dialog to set the column width. They are greyed out. I only can enter widths for the columns and if I decrease one of them, the extra space is automatically attributed to the next column. That's not very practical.

One should be able to distribute the space evenly. If done so, one should be able to chance to set widths of individual columns without influencing the other ones. If in doubt, the right table border should e adjusted and if it extends past the page width, a Warning should be shown.
Comment 1 Regina Henschel 2017-08-07 01:32:02 UTC
You need to set the table alignment to another value than "Automatic" to get the check-boxes enabled, see bug 100537.

*** This bug has been marked as a duplicate of bug 100537 ***
Comment 2 Adalbert Hanßen 2017-08-12 11:36:59 UTC
Yes is the same bug. Why didn't I find it before to hook into that discussion. But the bug is not resolved there!

I tried this (With Libre Office Linux):

Open LO Writer.

Make a table with 21 columns.

Go to the table properties dialogue in the tab "columns" and enlarge the width of the first two columns to something larger than 3 cm. "Remaining space" was 0 before and remains 0 after this step.

Some of the adjacent columns to the right shrink to almost zero by this (they shrink to 0,04 cm.  Those to the right of the shrinkage area remain unchanged). This is my test case.

I left the table properties dialogue clicking the OK button.

I marked the table again and then is inquired its properties dialogue to enter the tab "Table". As proposed, I switched Alignment from Automatic to Left. I left the check-mark "relative" unchecked.

Then I went to the columns tab. Yes, the first two options "Adapt table width" (German: "Tabellenbreite anpassen") and "Adjust columns proportionally" (German: "Spalten gleichmäßig ändern") are no longer greyed out. If I check the second one, the first one automatically gets checked too. 

But nothing happens to the displayed column widths, nor does anything happen to the table and its columns. Even after I have left the dialogue (OK button), nothing happens to the table. The columns do not become distributed equally!

I repeated the trial with Alignment Center in the table tab rather than Left. Same result!

Please fix this bug. 


BTW: From a logical standpoint, the question of alignment of the whole table has nothing to do with the distribution of columns in it. All questions on the alignment in the Table tab refer to the right and the left boundary of the whole table. The distribution of columns within that range is an independent issue. Therefore the overall structure of the table properties dialogue is logical. However, the restriction is not logical at all to disable "Adjust columns proportionally" in the Columns tab when Automatic alignment in the Table tab is selected for the whole table. 

The best thing for the user would be to make the dialogue also available for a selection of adjacent columns. If it is invoked for less than the whole table, one should then disable the „Table tab“, but the tab Columns should still be accessible. This would offer to the user the option to proportionally distribute the column width between the left and the right boundary of the selected columns or enter widths values for the selected columns, such that the widths of the not selected columns remain unaltered in this dialogue. 

Apparently at the moment, setting a column width triggers adaptation of columns to the right, if the maximum size would be exceeded. This is apparently done by shrinking as many columns down to 0,04cm such that the total table width would not exceed its maximum. 

If you accidentally enter a too large number, the whole table to the right gets messed up! In order to repair it, you have to manually enter all column widths, since „Adjust columns proportionally“ is currently not available.

If the width of the whole table (or the width of the selected columns) exceeds its maximum, I would prefer to first leave it that way and indicate a negative margin (possibly in red) in the field „Remaining Space“ and also I would indicate the widths of the columns to the right which hit the right boundary (of the selection or of the whole table) or go beyond it in red. The user might want to correct his chosen column widths accordingly. Only when he clicks on „ok“, a valid choice must be coerced (like it is done currently, but too early in the decision process). 

If some columns shrink to almost zero then, the user may select them together with some adjacent ones and re-enter my amended dialogue to select „„Adjust columns proportionally“ to the selected columns, leaving all other columns unchanged.

I further propose to show the widths of the unchangeable (because not selected) columns in the dialogue as greyed out and I would restrict the column selectors such that they confine the user to display at most one greyed out column at the left and at most one at the right of his selection. One might change the headline to "Widths of selected columns" if the dialogue is invoked for less than the whole table and leave it as "Widths of columns" (or whatever the English version displays).
Comment 3 Adalbert Hanßen 2017-08-12 11:56:05 UTC
I also tried it with Version: Build ID: e0bafa78e3ad0df397d78cd65ad19bd5b07dc5f2. It also features the same bug.