If you have a textbox with RTL direction and only RTL text inside, and you select it - but not go into edit mode, the character deck/tab of the sidebar will show you the Western language group font family, size, bold Y/N and italic Y/N - instead of showing you these properties for the RTL language group font.
Hello, I doesn't see character tab when I select text box. Please, can you attach test file and printscreen? Thank you.
Created attachment 187622 [details] Screenshot of bug manifesting; note Character tab of sidebar
Created attachment 187623 [details] Presentation used for screenshot 187622 Attaching as requested.
[Automated Action] NeedInfo-To-Unconfirmed
Right Click - character, check Fonts tab. When I right click - character, Fonts and change font, then sidebar reflect this change. So in your case property of text box and property of inside text is different, but sidebar show font correctly?
(In reply to raal from comment #5) > When I right click - character, > Fonts and change font, then sidebar reflect this change. Where exactly did you right-click? If I change the textbox font using the menus (under Format | Character... | Fonts tab) - the sidebar does still shows the Western language group font. > So in your case > property of text box and property of inside text is different, but sidebar > show font correctly? No. At least, I think not, since I don't quite understand which properties you're referring to. I'm not changing any fonts. I just created a text box and typed in some Hebrew font; and there is nothing in the slideshow that should cause Impress to show may the Western font in the side - and yet the Western font is what I get.
I can reproduce. I don't see what raal sees. UX team: this needs some figuring out. Arch Linux 64-bit, X11 Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 445ab2355333ddb46081baffb8b0e3bb14fe00b3 CPU threads: 8; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 7 July 2023
I see exactly what raal suggests. With edit cursor focus on the Text box on canvas --> context menu --> 'Character...' dialog and select the 'Complex' tab the in use font and its size are shown. What doesn't happen for me, and I think is the issue, is for the SB Properties deck -> Characters content panel to shift to the Complex script mode when the edit cursor is simply *positioned* within a text run of the Complex text (Hebrew for this example). It should. Yet if I select any of the text run, the Properties deck will shift to show font for the Complex script doing the correct thing. So seems the issue is not with the SB Properties deck, rather is with the locale/script detection within spans within the sd Textbox objects. I expect an ICU wordbound based test of the Textbox object is needed to pass info to the SB Properties deck when the edit cursor is positioned within a text run, but no selection is made. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9fc0b2b9b96d87eb642a3b29e9dcb5d6273265eb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to V Stuart Foote from comment #8) > I see exactly what raal suggests. With edit cursor focus on the Text box on > canvas --> context menu --> 'Character...' dialog and select the 'Complex' > tab the in use font and its size are shown. > > What doesn't happen for me, and I think is the issue, is for the SB > Properties deck -> Characters content panel to shift to the Complex script > mode when the edit cursor is simply *positioned* within a text run of the > Complex text (Hebrew for this example). It should. > > Yet if I select any of the text run, the Properties deck will shift to show > font for the Complex script doing the correct thing. > > So seems the issue is not with the SB Properties deck, rather is with the > locale/script detection within spans within the sd Textbox objects. The report is not about positioning or selecting text. It is about selecting the text box. Positioning the cursor inside the text shows Nachlieli CLM as expected. Selecting the text box shows Liberation Sans.
(In reply to Buovjaga from comment #9) > (In reply to V Stuart Foote from comment #8) > > I see exactly what raal suggests. With edit cursor focus on the Text box on > > canvas --> context menu --> 'Character...' dialog and select the 'Complex' > > tab the in use font and its size are shown. > > The report is not about positioning or selecting text. It is about selecting > the text box. Positioning the cursor inside the text shows Nachlieli CLM as > expected. Selecting the text box shows Liberation Sans. No. With text box object selected you activate an edit cursor inside the text box. And then that edit cursor can be positioned outside or within the existing CTL text runs yet _not_ assert the script of the runs. That is wrong. Merely selecting the text box should not trigger the script change from locale default bcz the text runs within a draw object have no default script--put another way you can have multiple text runs in multiple scripts present in a single text box. But Would expect that, when edit cursor is positioned into one of the runs (by cursor movement or mouse pointer but no selection made), the script should be detected and update the SB Properties deck.
(In reply to V Stuart Foote from comment #10) > With text box object selected you activate an edit cursor inside the > text box. Not sure what you mean. I don't activate anything. That's not what this bug is about. > Merely selecting the text box should not trigger the script change from > locale default bcz the text runs within a draw object have no default > script-- 1. You mean "language group change". 2. If there's no default - why display the Western language group setting? > put another way you can have multiple text runs in multiple scripts > present in a single text box. If _no_ language group info was displayed, then I might buy your argument (and maybe not even then). But if a language group is chosen - the more appropriate one should be chosen. And with a textbox with RTL direction and only RTL-CTL text - the appropriate language group is RTL-CTL.
Objects have attributes that do not necessarily match the content, discussed recently for charts. And I guess this is what causes the issue here too. It's not only related to RTL but any attribute inside the text box like font name and size. See also bug 137828, bug 86432, or bug 125714. The expectation is clearly to show the content information, which needs to be taken into the object attributes similar to paragraph attributes (or do something similar to Writer and do not show unless in edit mode). I suggest to consolidate the tickets.