following advice by Joel Madero in comment 22 of Bug 99864 I isolate a defect here.
Created attachment 126308 [details] Detailled test sequence documentation. Demo example
Created attachment 126309 [details] Demo example showing bad effect onto column selection.
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: https://wiki.documentfoundation.org/QA/BugReport#Good_Reports
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!
Version: 5.3.0.0.alpha0+ 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.
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"
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
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: 5.3.7.2 (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
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
Dear Heinrich Hartl, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still present in Version: 6.4.6.2, Build ID: 1:6.4.6-0ubuntu0.20.04.1 (=latest version Ubuntu LTS) Hint for users: Bug can be avoided by starting with cursor in a row with no merged cells, in demo example e.g. row 2. Then proceed with table properties -> colums. Mark adapt table width, enter for all five columns value 3cm. Pressing ok will result in a nice table where also the merged cells in first and last row are set to appropriate width.
Dear Heinrich Hartl, 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