Download it now!
Bug 101019 - Table - changing column width in a table with merged cells is effective only in one row
Summary: Table - changing column width in a table with merged cells is effective only ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
Reported: 2016-07-19 18:30 UTC by Heinrich Hartl
Modified: 2019-02-01 21:14 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Detailled test sequence documentation. Demo example (42.95 KB, application/vnd.oasis.opendocument.text)
2016-07-19 18:36 UTC, Heinrich Hartl
Demo example showing bad effect onto column selection. (91.58 KB, application/vnd.oasis.opendocument.text)
2016-07-19 18:42 UTC, Heinrich Hartl
Sample table to be used for steps to reproduce bug (11.16 KB, application/vnd.oasis.opendocument.text)
2016-07-30 09:47 UTC, Heinrich Hartl

Note You need to log in before you can comment on or make changes to this bug.
Description Heinrich Hartl 2016-07-19 18:30:58 UTC
following advice by Joel Madero in comment 22 of Bug 99864 I isolate a defect here.
Comment 1 Heinrich Hartl 2016-07-19 18:36:56 UTC
Created attachment 126308 [details]
Detailled test sequence documentation. Demo example
Comment 2 Heinrich Hartl 2016-07-19 18:42:48 UTC
Created attachment 126309 [details]
Demo example showing bad effect onto column selection.
Comment 3 Joel Madero 2016-07-30 03:38:42 UTC
Hi Heinrich - 

I got your email and have been really busy. Looking at this I'm sorry but I don't have the time to dig through a bad bug report. A few points:

(1) *simple repro steps should *always* be in the bug itself, not in attachments

(2) the steps should be really as simple as possible to demonstrate the problem

(3)) Attachments should equally be as simple as possible, no extra words, superfluous examples, etc....

You'll find way better success in terms of getting people to take the time to triage your bug reports if they are proper. For some good examples see:
Comment 4 Heinrich Hartl 2016-07-30 09:47:20 UTC
Created attachment 126485 [details]
Sample table to be used for steps to reproduce bug

steps to reproduce bug
1. open attachment  Sample-table-for-bug-101019
2. put cursor somewhere in row 1
3. Table properties / tab Columns: mark Adjust table width; 
change column 1 to 3 cm, 
       column 2 to 6 cm, 
       column 3 to 6 cm. 
4. OK
# only the width of cells in row 1 are changed as requested.
# the cells in the other rows except the last column are unmodified
# the cells in the last column of the other rows are adjusted to meet the new table width (3+6+6=15)
# the double columns (Unit, Quantity) under the merged heading cell holding the Year (2015, 2016) are no longer aligned under the heading cell
# certainly not a result appropriate for the changed values in table properties!
Comment 5 Joel Madero 2016-07-30 16:47:04 UTC
Build ID: fc305bb6d656736bedc2f89789e18d8c9a3bbf2c
CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group
Those instructions are way better - thank you.

So what I did:
1) Downloaded new file;
2) Put cursor in first row/first column
3) Right click -> table properties
4) Columns (tab)
5) Changed values of three columns to 1" (imperial system, not metric)

Observed: What you pointed out

6) Went back into table properties and columns tab
7) Checked the box "Adapt table width"
8) Changed values again

Observed: Different wonky behavior

So I'll go ahead and confirm.

New - confirmed
Minor - will slow down but will not prevent high quality/professional work (you can manually still adjust all)
Low - default for minor bugs

Just to head off any complaints about the minor priority:
(1) this is an objective standard - the bug will not *prevent* high quality work although it may make it a tad bit more annoying to get to the end result that you want

(2) "Minor" in no way indicates that developers will ignore it. Developers are volunteers so they fix what they want to fix (or are paid to fix by third parties). Thus, sometimes volunteers tackle trivial bugs that interest them, other times, a trivial or minor bug can sit for years without movement. The options are always the same: (1) fix it yourself - "Libre" means the code is available; (2) pay someone to fix it (usually not an option for an individual as it can cost thousands); (3) find a friend or family member who can code to fix it for you and offer them a nice meal in return; (4) wait patiently for a volunteer developer to tackle the problem.

Finally - I wouldn't be at all surprised if this is a duplicate.
Comment 6 Joel Madero 2016-07-30 16:48:54 UTC
Pretty much the same behavior going back to LibreOffice 3.3 (slightly different but still not right). In 3.3 the first two columns adjust, the last column does not.

Marking as "inherited from OOo"
Comment 7 QA Administrators 2017-09-01 11:18:03 UTC Comment hidden (obsolete)
Comment 8 Heinrich Hartl 2018-02-15 11:35:48 UTC
Comment on attachment 126308 [details]
Detailled test sequence documentation. Demo example

Problem still exists, tested with Bug_101019-cha-col-w_sample-document1.odt.
Behaviour is not changed in
Version: (x64)
Build-ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059
CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu; 
Gebietsschema: de-DE (de_DE); Calc: group
Comment 9 Heinrich Hartl 2018-02-17 17:47:05 UTC
The bug "only one row changed when column width is changed" is really annoying. Yes there is a possibility to do the right thing but I think it is much harder to explain the bypass solution to the user community than to correct the bug.

Moreover the strange table modification entails at least the next problem that selecting columns in table can behave strange.
Moreover the complexity of the document is increased -  in the example implicitely 2 new columns are created and consequently more merged cells have to be created.

The solution of the problems seems to me a simple correction of the code. For the desired modification of the table in attachment Sample-table-for-bug-101019.odt only a few values have to be changed in the document:
hkh@hkh-THINK /cygdrive/c/users/hkh/HH_2018/Aktivitäten_2018/BUG_101019
$ sdiff  -s -w 160 Sample-table-for-bug-101019/content_ori.xml  Sample-table-for-bug-101019/content.xml
      <style:table-properties style:width="17cm" table:align="center" />      |       <style:table-properties style:width="15cm" table:align="center" />
      <style:table-column-properties style:column-width="3.397cm" />          |       <style:table-column-properties style:column-width="3cm" />
      <style:table-column-properties style:column-width="3.401cm" />          |       <style:table-column-properties style:column-width="3cm" />
      <style:table-column-properties style:column-width="3.399cm" />          |       <style:table-column-properties style:column-width="3cm" />
      <style:table-column-properties style:column-width="3.403cm" />          |       <style:table-column-properties style:column-width="3cm" />
To do this editing I extracted content.xml from the .odt archive and used XML-Notepad for the editing. The edited file then was brought back into the .odt archive

There is really no need to make structural changes to the table.
There is really no good reason for restricting the change to a single row.

The tab columns in Table properties is not my favourite. I would like to see it redesigned. But there is no need to do so for correcting the bug. As is the column (-width) tab allows to enter width values for the visible cells (of the row where the cursor was when opening the properties). Therefore in a row with merged cells there are fewer cells in the displayed list. This however is not a problem. The current width is the sum of the cell-width spanned by the merged cell Wm=Sum(width of spanned columns). If Wm is changed (by input) this change can be distributed proportionally over the spanned columns. Doing so is consistent with what is done when the table width is changed.
Eg. for the demo table and the table property tab is referring to row 1 only three values are displayed: 3.30 6.80 (=3.401+3.399) 6,80 (=3,401+3.403)
# colum 4 in this demo refers to the style TablePlay-1.B of col 2. 
# style TablePlay-1.D  is not in the database.
# A separate style TablePlay-1.D for col 4 may be required 
If the second  cell in row 1 now is assigned width 6,00 this could be mapped 
to a width 3,401* (6,000/6,800) for column 2 and 3.399 * (6,000/6,800) for col 3