This bug is confirmed under Writer 6.4.4.2 and 7.0beta2. When configuring Options for a Section (Context menu: Edit Section... Options...), the first two tabs are Columns and Indents, which are interrelated for the section just as the Columns and Table (Width) tabs are interrelated when configuring a Table. For a Table, the configuration recognizes the connection between the two tabs: Table > Width is specified under the Table tab, and constrains the sum of the Column widths, unless one checks "Adapt table width" to column width changes. However, for the Section Options, where Section width is specified indirectly, the Columns tab does not recognize changes made to the Indents tab, so the final Section configuration is not known until the user exits the configuration tab and sees the result (which is then reflected on the /next/ "Edit Section..."). Note that the calculation of Section width: Section_width = Page_width - (L_margin+R_margin) - (L_indent+R_indent) is already done on /entering/ Section configuration. What prevents that simple calculation from being done whenever the Indents are changed, so that the Columns tab reflects any changes to the Section width? Should Section width treated differently from Table width? [Note: the third such object type, a Frame, is handled again slightly differently: The Frame Width (Edit Frame: Type > Width) can be specified in either absolute units or relative (%) to either page width or page text width (page_width - margins). Regardless how the Frame width is specified, column widths are always specified under Columns relative (%) to the Frame width, and the Frame width never adapts to the sum of column widths. I doubt that this model offers anything to help fix this bug, but want to mention it for completeness if we begin to try to normalize methods.]
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 163021 [details] 3-column section, table, frame - different methods for object width. This just takes the initial report and inserts examples for the object types.
[Automated Action] NeedInfo-To-Unconfirmed
Just for clarification: Is your idea a) Section option should be an option to set section width directly (and not indirectly with indent) b) Change of indent should also cause direct and visible change in column width in column tab of options dialog => NEEDINFO
(In reply to Dieter from comment #4) > Just for clarification: Is your idea > a) Section option should be an option to set section width directly (and not > indirectly with indent) > b) Change of indent should also cause direct and visible change in column > width in column tab of options dialog > > => NEEDINFO More (b) than (a). Setting width directly would still require a second "offset" setting to accomplish what Left- and Right-indents accomplish. But however this is done, column widths should reflect any change in total indents or margins.
(In reply to Dieter from comment #4) > Just for clarification: Is your idea > a) Section option should be an option to set section width directly (and not > indirectly with indent) > b) Change of indent should also cause direct and visible change in column > width in column tab of options dialog More (b) than (a). Setting width directly would still require a second "offset" setting to accomplish what Left- and Right-indents accomplish. But however this is done, column widths should reflect any change in total indents or margins.
(In reply to John Kaufmann from comment #6) > More (b) => I confirm it with Version: 6.4.5.2 (x64) Build-ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6 CPU-Threads: 4; BS: Windows 10.0 Build 19041; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded Steps to reproduce 1. Open attachment from comment 2 2. Put cursor into first section and open context menu 3. Edit Section => Option 4. Column tab: See settings in column width 5. Indent tab: Change settings to 0 cm 6. Back to column tab Actual result: Same column width as in step 4 is shown Expected result: Column width should respect changes of indent
Dear John Kaufmann, 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
Still present in Version: 7.3.5.2 (x64) / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Additional informations Lo freezes, if you deselect and reselect Auto Width in column tab after step 6.
(In reply to QA Administrators from comment #8) > Test to see if the bug is still present with the latest version of > LibreOffice from https://www.libreoffice.org/download/ Sorry to need a couple days to reply. As Dieter said in Comment 9, using 7.3.5.2, I confirmed under 7.3.4.2 that issue remains: A change in Section indents is not reflected in the section's column widths until the indent(s) change is executed. Something similar happens in Frames. A frame width may be specified in absolute units or as a percentage of either: (a) the full page width or (b) the paragraph area = full page width minus (left + right) margins. If the frame width is absolute, then the column widths are also specified in absolute units. [I believe this may be a change from LO 6.4.4.2 to LO 7.3.4.2, but can no longer check 6.4.4.2.] However, once established, the column percentages remain the same, so changes in frame width affect the columns proportionately. If frame width is specified as a relative percentage (either a or b), then column widths are specified as percentages of the frame width, and of course those percentages remain unchanged with changes in frame width. However, if frame width is absolute, and then changed to relative, and then the relative reference changed between (a) and (b), the relative percentage does NOT change with the reference basis, as it should. So the relative percentage does NOT reflect the absolute measurement until the frame width change is executed.
Still present with Version: 24.8.1.2 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded