Bug 159887 - Add option to freeze column widths in Writer tables
Summary: Add option to freeze column widths in Writer tables
Status: RESOLVED DUPLICATE of bug 145739
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.6.4.1 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Cell-Management Cell-Add-Delete
  Show dependency treegraph
 
Reported: 2024-02-25 18:46 UTC by William Friedman
Modified: 2024-06-21 12:16 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Friedman 2024-02-25 18:46:36 UTC
Description:
When a column is added to a Writer table, all of the column widths change to accommodate the new column. This is problematic if certain column widths have been manually set and changing them is undesirable. There is currently no option to freeze the width of a column in a Writer table to prevent it changing if other columns are added or deleted.

My suggestion would be to add an option to Table Properties | Column under each column, "freeze column width."

What if a user froze all the columns and then tried to add a new column? I can think of two possibilities: 1) disable adding columns if all columns are frozen; 2) if all but one column is marked frozen, disable the ability to freeze the last column.

Steps to Reproduce:
1. Create a table with multiple columns.
2. Manually adjust the width of some of the columns.
3. Insert a new column anywhere in the table.
4. See that the widths of all the columns change.

Actual Results:
Widths of all columns change.

Expected Results:
Allow the option to freeze the width of columns.


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.6.4.1 (X86_64) / LibreOffice Community
Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 1 Dieter 2024-03-10 15:39:22 UTC
William, so do you expect, that width of the whole table changes (this is bug 125736)? What do you expect, if table width has the width of the whole text area?
=> NEEDINFO

See also bug 128279
Comment 2 William Friedman 2024-03-12 14:34:53 UTC
There should be an option to freeze the width of the whole table as well (IMO, this should be the default), which is how tables currently act when they take up the width of the whole page. If a column is added or deleted when the total table width is frozen, then the unfrozen columns should be redistributed within the remaining width to accommodate the added or deleted column, either by shrinking (if a new column is added) or increasing (if an existing column is deleted). If the total width is variable, then adding/deleting columns can adjust the total table width as they currently do with tables that don't take up the whole page width.

I also agree with bug 128279 that a table should be settable to automatically equidistribute column widths. And I would add that in addition to the option to freeze a column's custom width, column widths should be settable to min width, expanding and contracting according to the longest string in the column.
Comment 3 Dieter 2024-06-16 16:25:08 UTC
(In reply to William Friedman from comment #2)
> If a column is added or deleted
> when the total table width is frozen, then the unfrozen columns should be
> redistributed within the remaining width to accommodate the added or deleted
> column, either by shrinking (if a new column is added) or increasing (if an
> existing column is deleted).

But this is more or less the actual behaviour you want to change.

Anyway, let's ask design-team for their opinion.
Comment 4 Heiko Tietze 2024-06-17 08:39:38 UTC
My STR would be:
* create a table with 2 columns
* table properties > Left or From Left and Width = 2cm (makes the two columns 1cm each)
* run Insert Columns After
=> columns resize, width remains constant while the opposite is expected (in this case)

We had a lot discussions around this topic and I'm pretty sure there are duplicates. But I don't get why it shouldn't be bug 125736.
Comment 5 Heiko Tietze 2024-06-20 08:10:36 UTC

*** This bug has been marked as a duplicate of bug 125736 ***
Comment 6 William Friedman 2024-06-20 16:14:50 UTC
(In reply to Heiko Tietze from comment #4)
> My STR would be:
> * create a table with 2 columns
> * table properties > Left or From Left and Width = 2cm (makes the two
> columns 1cm each)
> * run Insert Columns After
> => columns resize, width remains constant while the opposite is expected (in
> this case)
> 
> We had a lot discussions around this topic and I'm pretty sure there are
> duplicates. But I don't get why it shouldn't be bug 125736.

I think this bug/enhancement is a more generalized case than 125736. That bug, as I understand it, relates to whether adding columns changes the table width if there is more space. My request here focuses on what happens if the total table width is frozen and/or already spans the full page width. My enhancement request is to add the ability to freeze the width of certain columns, such that adding or deleting columns would not change their width. Dieter's comment 3 seems to miss the point. Obviously in order to add columns to a frozen-width table *some* columns will need to have their widths reduced. My request is to be able to fully customize *which* columns would have their widths reduced, by marking some columns as frozen.
Comment 7 Heiko Tietze 2024-06-21 12:16:12 UTC
(In reply to William Friedman from comment #6)
> My request here focuses on what happens if the
> total table width is frozen and/or already spans the full page width...
> My request is to be able to fully customize *which* columns
> would have their widths reduced, by marking some columns as frozen.

We likely cannot have tables exceeding the page width. And to freeze individual cells in order to keep their width sounds to me cumbersome. However, table management needs a complete overhaul - and this has been discussed including a lock functionality in bug 145739 with a blog post at https://design.blog.documentfoundation.org/2022/04/11/improve-the-table-configuration-in-libreoffice-writer/. Perhaps that's a better fit for your request.

*** This bug has been marked as a duplicate of bug 145739 ***