Created attachment 176612 [details] Current Table tab of the Table Properties dialog The Table tab of the Table Properties dialog has, on one side, a set of radio boxes: **Alignment** ( ) Automatic ( ) Left ( ) From Left ( ) Right ( ) Center ( ) Manual Disregarding for a moment other controls in this dialog, this list is confusing: Some items are vague/confusing in themselves, while some confuse me in the context of the other choices. Let's start at the purely linguistic level. There is no way you could create a valid phrase with "alignment" and "from left": "Aligned from left", "Aligned with From Left", "From-Left-Aligned"? Nope. You simply can't put "From Left" on the list of options. Now for semantics. The user can (?) be assumed to know what alignment means, based on the alignment of paragraphs. The options there are: Left, Right, Start, End, Center, Justified. Start and End are sadly not yet implemented; that is bug 131192; so let's ignore them; and Justified could be forced to have a meaning for tables, but that's not necessary, so forget about that too. That leaves us with "Left", "Right" and "Center" as notions the user is familiar with, and could (if we're very optimistic) guess what happens when they are chosen. But if these terms are used differently than for paragraphs, or even if they are offered along with other, non-paragraph-like options - even these 3 options, and certainly any other ones, must be explained at least as clearly and in a straightforward manner as paragraph alignments are in the paragraph dialog. That is to say: -> Some visual illustration of the aligned table on a page, within surrounding text, is necessary in this dialog in support of the choice of alignment. Now for the worst part: "Automatic alignment" - While this _sounds_ nice, it is actually _meaningless_, or rather - conflicts with the meaning of alignment we know from paragraphs. For the life of me - to this day I don't understand what exactly is automated in automatic alignment. And I'm not the only one; to quote Frank Brutting from bug 113960: > Furthermore, I don’t quite understand what “automatic alignment” should mean? Considering how tables behave with this mode - wouldn't it be better to call it "No Alignment" or "None"? i.e. the table is never actively moved or stretched due to alignment considerations? Then there's the second travesty, which is "Left" vs "From Left". WTF? And my only guess would be that "From Left" is perhaps a synonym for "Right"; but then - we have "Right" alignment. It doesn't help that "From Left" and "Right" offer the same combination of non-grayed-out controls. This situation probably means that the illustration of alignment mode should make it clear how these three modes differ (if they all should even exist, which I'm not 100% sure of). An illustration may also allow placing the other controls near the regions they affect, which would make their graying-out or hiding make more sense. It might also allow setting offsets/sizes by dragging the edges of the mock table, or dragging the whole table etc; and would help clarify and contextualize how different values affect each other.
You may consult the help https://help.libreoffice.org/7.4/en-US/text/swriter/01/05090100.html (which has different terms). We could change it to *Position* (o) Full page size ( ) Start from left ( ) Start from right (I see no difference between "From Left" and "Right"; the code [1] proves wrong; it needs more testing) ( ) Centered ( ) Manual Is this worth the effort for documentation and l10n? We could also drop everything and have (o) Automatic Spacing ( ) Manual Spacing Left [ } Right [ ] ... meaning either full size or to always start with zero distance from the left page border for LTR resp. from right in case of RTL. If users want something else it can be done manually. Since the table size is relevant for the column size we should merge both tabs (see also bug 145739). [1] https://opengrok.libreoffice.org/xref/core/sw/source/ui/table/tabledlg.cxx?r=457a67a5#291
(In reply to Heiko Tietze from comment #1) > You may consult the help > https://help.libreoffice.org/7.4/en-US/text/swriter/01/05090100.html (which > has different terms). Yes, that does help, but as always - I'm against it being used as a crutch, and the UI must be somewhat, even if not perfectly, clear; and consistent. > We could change it to > > *Position* > (o) Full page size > ( ) Start from left > ( ) Start from right (I see no difference between "From Left" and "Right"; > the code [1] proves wrong; it needs more testing) > ( ) Centered > ( ) Manual This would already be an improvement. Some bikeshedding: "position" -> perhaps "positioning"? Not sure which is better. "full page size" -> "full page width" or "entire page width" are better. "Start from left" -> perhaps "Extend from left"? Not sure which is better. > We could also drop everything and have > > (o) Automatic Spacing > ( ) Manual Spacing > Left [ } > Right [ ] > ... > > meaning either full size Ah, but "automatic spacing" does not mean full size. It means that LO will add some (horizontal) space outside the table. Also, the use of "spacing" isn't clear enough in your proposed controls. It's already a bit unclear in the existing controls (instead of "Spacing" I would say "Space around table" or "Spacing around table", but in your proposed control it's really unclear what kind of spacing this is supposed to be: vertical/horizontal, inside/outside. Also, a centered table is not covered by your suggestion. I would like to suggest an alternative, but whatever I think of, I come up against the fact that the table width controls on the Columns tab actually also control the spacing for the Centered case, while choosing "full page size" here sets those width controls. This is why your saying that: > Since the table size is relevant for the column size we should merge both > tabs (see also bug 145739). resonates with me. Anyway, here's my current thought. It doesn't go all the way with the tab merging, but it could be part of a merged tab: Option 1: > *Horizontal Position:* > > [ _____ ] [ _________ ] [ _____ ] > Left Table Right > Margin Width Margin > > Automatic settings: > ( ) Fill page width > ( ) Center > ( ) Align left > ( ) Align right > ( ) None > > -------------------------- > > *Vertical Positioning:* > > [ _____ ] Top margin > > [ _____ ] Bottom margin Option 2: > *Horizontal Position:* > > [ _____ ] [ _________ ] [ _____ ] > Left Table Right > Margin Width Margin > > Positioning mode: > ( ) Center table > [ ] Fill page width > ( ) Align to one side: > ( ) Left > ( ) Right > ( ) Manual > > -------------------------- > > *Vertical Positioning:* > > [ _____ ] Top margin > > [ _____ ] Bottom margin Now, the actual margin and width controls in my proposal could be simple text boxes; or the horizontal part could constitute or augment illustration (like right and left indentation and the ruler illustration for paragraphs) ; or you could merge the horizontal and vertical controls to constitute or augment a 2D illustration. Also, and regardless of whether the controls change, I still think an illustration is in order regarding how the table will look on the page. > > [1] > https://opengrok.libreoffice.org/xref/core/sw/source/ui/table/tabledlg. > cxx?r=457a67a5#291
Mockup for a solution in bug 145739 with discussion at https://design.blog.documentfoundation.org/2022/04/11/improve-the-table-configuration-in-libreoffice-writer/
Dear Eyal Rozenberg, 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