Created attachment 125063 [details] This document has tables in it where I can reproduce the bug I am running 5.0.6.3 writer (normally using german language interface). I have a table and I found that the column width were inappropriate. I tried to change the column width. I was always directed to the table properties pane (after selecting the entire table or selecting just a column or what ever I tried). There is a tab for columns. I try to enter my desired values - strange things happened. More on this below. The only procedure that did what I wanted is tedious and certainly not intended: Place cursor in one of the rows of the table, go to table properties /columns choose modify table width, start with setting values for columns where the width is reduced and only then make some columns wider - never overuse your width-budget. enter ok ->: result is that in the row where the curser was the cell width is changed as desired. ... Repeat that procedure for every row. Strange effects observed: - after changing one width value other values were changed to strange values positiv ones, negative ones, measurements far beyond paper size. - after klicking ok the row showed what looked to me like combined cells and in a subsequent invocation of table properties fewer columns were shown. - change a width value (whithout setting option to change table width) always changes the value of the next column, normally spoiling a previous correct value. If there was a defined column to fill the gap maintaining table width I could correct values without spoiling correct ones. I hope you can reproduce the effects with the submitted odt. If there is a problem reproducing strange effects I certainly can give more precise directions.
You do not mention which table we should manipulate. You don't have clear steps to reproduce the problem or an image of the problem. I tried with the first table. All the rows are affected. By row I take it you mean the horizontal rows (some people confuse them and talk of rows when they mean columns). Set to NEEDINFO. Change back to UNCONFIRMED after you have provided more detailed information. Win 7 Pro 64-bit, Version: 5.1.3.2 (x64) Build ID: 644e4637d1d8544fd9f56425bd6cec110e49301b CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Locale: fi-FI (fi_FI) Version: 5.2.0.0.alpha1+ Build ID: 3d27afd26f7b85c46a7c7d08498000b9dbcea1c8 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-05-09_02:42:15 Locale: fi-FI (fi_FI)
I tried to reproduce observed misbehaviour. I could not reproduce all of the observed problems with my initial effort. I hereby submit a detailled documentation of the steps done to show both - it can work but, see on page 2 there is also something wrong. May be the misbehaviour is linked to tables with joined cells...
Created attachment 125149 [details] Detailled test sequence documentation
(In reply to Heinrich Hartl from comment #3) > Created attachment 125149 [details] > Detailled test sequence documentation Hello, tested: click in table „Zivile Sterbe...“ col 1 row 1 choose table select entire table choose table properties column width update values – choose adopt table width, col 1 3cm, all remaining 1.4 cm, click ok only first row is affected! but this table has first row with merged cells, so I mean the program works correctly. For example when you try to change width with the same steps in table "Jahresbruttoeinkommen" (first table), then it works as you want.
NOTABUG per comment 4
Created attachment 125476 [details] small document for reproducing the bug
Created attachment 125477 [details] Step by Step doku for reprodcing bug using small document
uploaded documents should be more precise for reproducing the problem
(In reply to Heinrich Hartl from comment #7) > Created attachment 125477 [details] > Step by Step doku for reprodcing bug using small document You are talking about the problems of selecting columns after staggering the topmost row which has merged cells. What do you actually propose then for the desired behavior of selecting columns in such a table containing merged cells? Currently the program is apparently trying to make a best guess in such a situation. Do you have some suggestion on making it guess even better? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Created attachment 125558 [details] my suggestions for improvements please find my suggestions in attachment Bug-99864_suggested-improvement.odt. I also include Bug-99864_Table-Z.xml which is derived from Bug-99864_Table-Z.odt by storing as xml format. I used MS-XML-Notepad to look at this file.
Created attachment 125559 [details] xml version of small document
hope my suggestions are helpful
Created attachment 125613 [details] Clear evidence of better information in database An analysis of xml (save/DocBook.xml and MSWord2000.xml) reveals that required information for suggested solution is part of the databasis. Moreover it makes clear that Docbook and MSWord both use the suggested solution.
Created attachment 125614 [details] Demo file
Created attachment 125615 [details] saved DocBook.xml
Created attachment 125616 [details] saved MSWord2003.xml
Created attachment 125617 [details] exported Writer Layout.xml
Created attachment 125618 [details] absolets prior version adds analysis .odt and strange row2 discussion extracting content.xml from the .odt archive allowed for database analysis of .odt without relying on export or save in other formats. The analysis of content.xml confirmed the results sofar obtained. The analysis was extended for non trivial splits of cells. The demo file for this is Bug-99864_Table-Z _strangeRow2.odt MergersInRow2_content.xml and strangeRow2_content.xml are also attached
Created attachment 125619 [details] content.xml extracted from .odt
Created attachment 125620 [details] content.xml extracted from ...strangeRow2.odt
Created attachment 125621 [details] demo file strangeRow2.odt
I suggest this bug be closed as INVALID (it was originally an invalid report with multiple issues reported in a single bug) and then the original reporter should report new bugs (1 issue per report) with clean reproducible steps and simple test documents. I won't close it myself but I suspect that the bug will never be looked at by a developer if it's not closed and new clean bugs created.
I agree the initial bug report was not as targeted as desirable. However the test scenario and instructions for reproduction were refined. There were never multiple issues in the case - the only issue is that change column width sometimes has strange results. During refinement it turned out to be linked to merged cells. After comment #3 and associated attachments the issue is precisely documented. Comment #9 requested suggestions how to improve. I think it also confirms that the given small demo and instructions were adequate for reproducing. In comment #10 this request was answered with a very carefully compiled suggestion. All the other additions later on do not modify or extend the bug issue. However these are documenting careful refinement work to help with evaluation and to check for viability.
I tried to follow the advice of Joel Madero (Comment 22) and set up another bug 101019 for the key issue - change column width doesn't change all rows. I agree this bug should be closed now. Contained materials mostly helped me to understand what was happening.
Alrighty, closing.
'needsConfirmationAdvice' is only used for unconfirmed bugs. Removing it from this bug. [NinjaEdit]