Description: Currently, “adapt table width” isn’t active by default. This leads to the problem, that each time we modify the width of one row, the next one is affected exactly inverse by default, too. This is a very bad practice, because in by far the most cases, one doesn’t want to affect the next column inversely. This gets extremely cumbersome, in case you want to narrow the first column, but widen the fifth one. Then you have to edit the first column, then iterate through every column unto the fifth and retain their width (because they all get altered by each step), and then finally alter the fifth one (or activate the here proposed to be standard mode). So I’d like this aforementioned setting to be enabled by default – but it seems that alignment needs to be different from “automatic”, too. I suppose centered is the mostly reasonable case here. Furthermore, I don’t quite understand what “automatic alignment” should mean? Is far as I understand it, “stretched” or “spanned” seem to be better terms for describing this setting. Steps to Reproduce: 1. Create a table. 2. Alter the width of one column of the table. Actual Results: Another column gets altered, even if nobody triggered this change. Expected Results: Other columns shouldn’t be affected. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
I have been tried it. Widen column works well but alter the width of rows affects the width of next rows if you have been altered its default width. Version: 5.4.3.2 (x64) Build ID: 92a7159f7e4af62137622921e809f8546db437e5 CPU threads: 8; OS: Windows 6.19; UI render: default; Locale: en-US (en_US); Calc: group
Page A4, new table with 5 columns: 3.4cm + 0cm remaining Alignment automatic: Cell 1 = 2cm: cell 2: 4.8cm, 3-4: 3.4cm Remaining: 0cm Alignment center, [x] Adapt table width: Cell 1 = 2cm, 2-5: 3.4cm Remaining: 1.4cm Alignment center: Table is placed horizontally centered (given remaining space >0) What you expect is, from what I understand, check [x] Adapt table width, configure the width of col 1 (remaining size goes into the extra field), adjust the last or any other column (taken from remaining space. Worksforme. I doubt that changing col 1 should affect the last col in all use cases. What I could imagine is you want to make col 1 smaller and adjust all other cols equally with no remaining space. This could be done with bug 113604. If you accept, Zyklon, I would make this ticket a duplicate of the other.
Thanks for your comment, but I actually meant, that it is annyoing, that a change to one column (no matter which) affects other columns. This behaviour is due to the option “adapt table with” not being checked by default. What I want is, that a change to a column width should NOT affect ANY other column – but instead the complete table with. So if my table spans over the whole screen, and I shrink any column by a several amount, I want the whole table being shrinked by exactly this amount, because the width of all other columns should persist. The solution is pretty easy: Just make the checkmark default. The mode with that unchecked checkmark (i.e. altering one column’s width changes another one) being completely useless is another bug. But I don’t care about that, because I would never use that.
I beg you, please fix that bug. This week I had to edit some tables and the experience was incredible annoying. First problem is, that both settings “Alignment = center” and “Adapt table with = true” don’t get saved. …or get overwritten? So after about every modification of column widths, the alignment of that table gets weirdly displaced. Second issue is, that the insertion or the removal of a column completely changes all(?!) column widths, as there obviously applys the constraint, that the table width has to stay the same…?! This logic is totally uncomprehensible, is this would just replicate a special case for e.g. text-embedded tables, that should not modify the text layout and therefore have to retain the size. In total, for altering a column, I always need several minutes for adapting all the widths again – as these have to keep exact widths for avoiding line breaks. I don’t understand this.
Trying again I wonder how you achieve to resize the table width when adjusting a column. What works is when I configure columns in the dialog (as discussed in comment 2) but never for manual resizing.
(In reply to Heiko Tietze from comment #5) > Trying again I wonder how you achieve to resize the table width when > adjusting a column. What works is when I configure columns in the dialog (as > discussed in comment 2) but never for manual resizing. For manual resizing do not use the mouse but the keyboard. It is Alt+Arrow_right and Alt+Arrow_left. The behavior of this shortcuts can be configured in the options.
The problem exactly is, that the table width is _not_ altered, after making a column smaller or bigger – instead other columns get modified, what I absolutely don’t like, as I in about all cases set up my column width exactly to my needs. And I don’t like to do that process all the time again. :/ And oftentimes, the table alignment also gets altered. When I set a table to be centered, I don’t like that to be changed. Only the table width (not the column widths) need to change with content. There just is the default “automatic” mode, which may allow the column width to adapt sizec – ok – but please don’t do that in all other modes! If you browse on one website, you also won’t like Firefox to alter the contents of other websites. (Just for giving some random analogy.)
If there still is some unclarity, I’ll do a screencast. ;)
(In reply to zyklon87 from comment #8) > If there still is some unclarity, I’ll do a screencast. ;) The request is clear and apparently there is no option except the alt+cursor shortcut. Option 1: Rework the table properties dialog and keep the table width setting on close; resizing a column affects the table with if this checkbox is set Option 2: Introduce a modifier key such as shift that can be used together with the mouse to change the table width likewise it's done with the checkbox Supplemental: Provide a configuration at Tools > Options to define the default
*** Bug 116609 has been marked as a duplicate of this bug. ***
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Dear Frank Brütting, 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
I started this issue more than 6 years ago. And I am certainly tired of this stupid bot closing all issues after a while. I try things, report them, answer months and years later with everytime getting into an issue again and spending a lot of time (mostly superfluous because not seeing any results in most cases). I’m tired of this, please test for yourself. I wanted to help, but not this way.
(In reply to Frank Brütting from comment #13) > I started this issue more than 6 years ago. And I am certainly tired of this > stupid bot closing all issues after a while. I try things, report them, > answer months and years later with everytime getting into an issue again and > spending a lot of time (mostly superfluous because not seeing any results in > most cases). I’m tired of this, please test for yourself. I wanted to help, > but not this way. The stupid bot will not close any issue that is in NEW status. However, with methodical testing we have found that 25% of pinged NEW reports could be closed as the bug was gone. Surely you admit such a nice result is worth the effort and annoyance. A clean bug tracker helps developers work more efficiently.