Writer's table properties currently offers the following alignment options: ( ) Automatic ( ) Left ( ) From Left ( ) Right ( ) Center ( ) Manual this is problematic in many ways, see bug 145980. What that bug does not cover, however, is the need to be able to align the table with the Start or End, as opposed to aligning Left or Right. I believe Start and End in this context will correspond to the table's direction (currently appearing in the UI as its "text direction").
Just to be clear, of course - I don't think it's a good idea to have 8 (!) different alignments on offer. But that's a matter for discussion in bug 145980.
(In reply to Eyal Rozenberg from comment #0) > What that bug does not cover, however, is the need to be able to align the > table with the Start or End, as opposed to aligning Left or Right. As far as I can see, the mockup [1] already includes your idea, but perhaps instead of "From Start (Left)" something like "From Start (of paragraph direction)" would be more clear. So I don't see the need for a new bug report cc: Heiko Tietze
(In reply to Dieter from comment #2) > ...the mockup [1] already includes your idea Missing the reference. https://help.libreoffice.org/26.8/en-US/text/swriter/01/05090100.html Left: Aligns the left edge of the table to the left page margin. Left margin: Aligns the left edge of the table to the indent that you enter in the Left box in the Spacing area. Something like Left = Start at page margin and Left margin = Start at paragraph would be wrong. The From Left runs the table from a customizable left position to the end while Left starts at the exact page margin with an option to stop before the right edge. Guess it's the same for RTL and Right/From Right.
Is this not also handled/addressed in: bug 145739
(In reply to Telesto from comment #4) > Is this not also handled/addressed in: bug 145739 No, because that bug is about the UI for existing functionality, not about missing functionality. Note that these alignments are distinct from paragraph alignments, so the fact that we have Start and End for paragraphs does not automatically give us these two alignment settings for tables.
Ok, (In reply to Eyal Rozenberg from comment #5) > (In reply to Telesto from comment #4) > > Is this not also handled/addressed in: bug 145739 > > No, because that bug is about the UI for existing functionality, not about > missing functionality. FWIW: I get that and surely not intending to obscure the issue mentioned here by dumping it into a different bug, which at it's core is covering a different topic. Making things quite fuzzy Reason I brought it up is the mockup using Start/End terminology attachment 179458 [details] and well the UI design is - in my perception - to some extend entangled with what is asked for here. Implementing the topic here requires a changes to UI Although no clue whats required to be changed aside from the labeling.
(In reply to Telesto from comment #6) > Reason I brought it up is the mockup using Start/End terminology attachment > 179458 [details] and well the UI design is - in my perception - to some > extend entangled with what is asked for here. Implementing the topic here > requires a changes to UI That's a good point regarding that mockup. But the UI change for support of Start and End should be mostly orthogonal. For example, in that mockup, we would need 6 options instead of 4 (or decide the UI doesn't expose Left and Right, only Start and End). And also, with our current Table properties dialog, we need to add options for Start and End.
(In reply to Eyal Rozenberg from comment #7) > That's a good point regarding that mockup. But the UI change for support of > Start and End should be mostly orthogonal. For example, in that mockup, we > would need 6 options instead of 4 (or decide the UI doesn't expose Left and > Right, only Start and End). And also, with our current Table properties > dialog, we need to add options for Start and End. True. However splitting it sometimes feels as waste of resources. Spending time lots of time on dialog (discussion; code change, review and so) which in advance being known to be out-dated. Obviously it's a balancing act. Bundling not a panacea either: * to much effort, so bug being avoided because of being to large * to complex (or to many open ends regarding the implementation) Doing less * Incrementally means: only partial change; without another change for probably year. Lots of half baked stuff ---Meandering thoughts -- Discussions about multitude of aspects within a single bug report quickly resulting in a indecipherable mess. OTOH: having dozens of separated bugs which - in the end - are actually heavily interconnected but presented totally separated resulting in atomization/insight silo's. Meaning limited to no integration of the subtopics & lack of general overview. So at one hand I'm in favor in splitting discussion into dedicated bugs. OTOH I prefer those to be grouped into overarching actionable bugs (which more or less a conclusion/summary's off all the subtopics). This result in some static conclusion. It can evolve over time. However being a summary thread, not one for discussion [say end-conclusion of UX-meeting] It would be a slightly different meta-bug compared to the current meta-bug system. Which is actual nice to have. Reason: I'm personally unable to keep track of all related bugs. So quite some bugs I will not notice or forget about. Resulting out of sight, out of mind. I'm envisioning a meta-bug: the Table Properties dialog needs a revamp with in my perception implementing start/end being part of the change. [Yes, it's subjective]. Why didn't you create one already: I'm able to asses if's valid meta-bug. And I would singly handed introduce new type of metabug (action based); possibly interfering with current system. It would be a kind of UX change bug-tracking system. And well volunteers can't add more and more bugs freely. The meta-bug needs to be actionable. So a rigorous check of scope creep is needed. So each 'addition' to the meta-bug needs to be ultimately accessed by by some authority (for example during UX-meetings). And some standards: so no general rules. No more than 10 subtopics. --- FWIW: there was request for GsoC projects. Implementing Start/End function including UI might be something? Not sure if this is feasible.