Description: If a table has text in different cells with mixed alignments (e.g., the header row is center-aligned but the rest of the rows are left- or right-aligned), selecting the entire table to change the direction of the text from LTR to RTL or RTL to LTR changes the alignment of the center-aligned text to right- or left-aligned. This doesn't happen if the entire table is center-aligned. It also doesn't happen if only the cells with center-aligned text are selected and the text direction is changed; in that case, center-alignment is retained. Steps to Reproduce: 1. Create a 2x2 table, with Heading checked. 2. Type some text in the header row. 3. Select the entire table and change the text direction. Actual Results: The centered header row text becomes left- or right-aligned with the text direction change. Expected Results: The centered text should remain centered. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
I can't confirm it with Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Not sure, how you change text direction. I did it with Format -> Paragraph -> Alignment -> Properties
Created attachment 183449 [details] Video demonstrating the bug You can see in this video the bug in action. I use only menu options / toolbar icons to set the text direction and alignment.
(In reply to Dieter from comment #1) > Not sure, how you change text direction. I did it with > Format -> Paragraph -> Alignment -> Properties I see, I have to activate Complex text layout in Languages settings. And I can confirm it, when using the RTL-button in toolbar or the shortcut Strg+Shift+D. So it's a problem of command .uno:ParaRightToLeft. If you change text direction in table properties dialog, problem ist not reproducible.
Confirming that this bug still appears in: Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded In response to Dieter's comment #3 "If you change text direction in table properties dialog, problem ist not reproducible," I want to point out that there is a major difference between changing the text direction of the table as a whole and changing the text direction of the individual cells. Changing the text direction of the table reverses the order of the columns and changes navigation through the table, e.g., pressing tab now moves to the left cell rather than the right cell (if going from LTR to RTL). But changing the text direction of all the cells doesn't affect either of those. The problem here is that selecting all of the *cells* and changing text direction when the cells have different alignments results in the loss of the non-left/right alignments. This has nothing to do with the text direction of the table as a whole. I hope this problem can receive some attention.
Heiko/Xisco: not sure if it's a bug. Indeed LO goes into to apply the command: 379 case SID_ATTR_PARA_LEFT_TO_RIGHT : 380 case SID_ATTR_PARA_RIGHT_TO_LEFT : 381 { 382 SfxItemSetFixed<RES_PARATR_ADJUST, RES_PARATR_ADJUST> aAdjustSet( GetPool() ); 383 GetShell().GetCurAttr(aAdjustSet); 384 bool bChgAdjust = false; 385 SfxItemState eAdjustState = aAdjustSet.GetItemState(RES_PARATR_ADJUST, false); 386 if(eAdjustState >= SfxItemState::DEFAULT) 387 { 388 SvxAdjust eAdjust = 389 aAdjustSet.Get(RES_PARATR_ADJUST).GetAdjust(); 390 bChgAdjust = (SvxAdjust::Left == eAdjust && SID_ATTR_PARA_RIGHT_TO_LEFT == nSlot) || 391 (SvxAdjust::Right == eAdjust && SID_ATTR_PARA_LEFT_TO_RIGHT == nSlot); 392 } 393 else 394 bChgAdjust = true; (See https://opengrok.libreoffice.org/xref/core/sw/source/uibase/shells/txtattr.cxx?r=d384ccdb#379) It goes in the "else" case (line 394) because selecting the whole table "eAdjustState" var has DONTCARE value DONTCARE corresponds exactly to the whole table: 90 /** Specifies that the property is currently in a don't care state. 91 * <br/> 92 * This is normally used if a selection provides more than one state 93 * for a property at the same time. and DONTCARE < DEFAULT (see "SfxItemState" definition at https://opengrok.libreoffice.org/xref/core/include/svl/poolitem.hxx?r=c351f920#82) Once the direction is modified with: 396 SvxFrameDirection eFrameDirection = 397 (SID_ATTR_PARA_LEFT_TO_RIGHT == nSlot) ? 398 SvxFrameDirection::Horizontal_LR_TB : SvxFrameDirection::Horizontal_RL_TB; 399 aSet.Put( SvxFrameDirectionItem( eFrameDirection, RES_FRAMEDIR ) ); 400 the next block tests "bChgAdjust" to know if alignment should be modified: 401 if (bChgAdjust) 402 { 403 SvxAdjust eAdjust = (SID_ATTR_PARA_LEFT_TO_RIGHT == nSlot) ? 404 SvxAdjust::Left : SvxAdjust::Right; 405 SvxAdjustItem aAdjust( eAdjust, RES_PARATR_ADJUST ); So if we don't want to change the alignment when selecting the whole table, this patch seems ok: diff --git a/sw/source/uibase/shells/txtattr.cxx b/sw/source/uibase/shells/txtattr.cxx index 68f4197f5437..6d9011d3f47c 100644 --- a/sw/source/uibase/shells/txtattr.cxx +++ b/sw/source/uibase/shells/txtattr.cxx @@ -390,8 +390,6 @@ SET_LINESPACE: bChgAdjust = (SvxAdjust::Left == eAdjust && SID_ATTR_PARA_RIGHT_TO_LEFT == nSlot) || (SvxAdjust::Right == eAdjust && SID_ATTR_PARA_LEFT_TO_RIGHT == nSlot); } - else - bChgAdjust = true; SvxFrameDirection eFrameDirection = (SID_ATTR_PARA_LEFT_TO_RIGHT == nSlot) ? any thoughts?
Eyal, what do you think?
(In reply to Heiko Tietze from comment #6) > Eyal, what do you think? If table cell had alignments Left, Right, Center, Start, End, then switching directions of multiple tables should not trigger any change to the alignments - since Start and End would now mean the opposite side. So, the most important thing to do here is get started working on bug 131192. With that not being possible yet, the semantics should be: Left, Right => flipped Center => unchanged there is no sense in "clearing" the alignments like we see now; the user can always do that on their own if they want to.