Created attachment 199528 [details] Presentation with the bug manifesting Consider the attached presentation. It consists a single slide with some animation effects, with auto-generated names. Some of the generated effect names contain both LTR and RTL text; if you open the animation sidebar, you'll notice these effect names are mis-rendered: The RTL and LTR text overlap.
Created attachment 199529 [details] Impress 25.2.0.3 with attachment 199528 [details], showing garbled labels
Thank you for reporting the bug. I can confirm that the bug is present in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7b9e27da2033192c628b23e4e1686209e951dadb CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded However, I cannot reproduce it in windows 11.
(In reply to Brandon H. from comment #2) > However, I cannot reproduce it in windows 11. Ok, so, I also reproduced with another VCL: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 331ea32ec181aff739eaebee328281b190cad003 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-IL (en_IL); UI: en-US so it's not a GTK-specific issue.
Also reproduced in: Version: 24.8.5.2 (X86_64) / LibreOffice Community Build ID: 27b361b745d0ea8f99bc93dfcb7a39098dfa5fff CPU threads: 32; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded and with the gen backend: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 98c8077893044453ca76ad2a34c6d86d9be0c2c7 CPU threads: 32; OS: Linux 6.11; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded but could not repro with MacOS: Version: 24.8.1.2 (AARCH64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 CPU threads: 12; OS: macOS 15.3.2; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded Another data point suggesting this is Linux-specific.
The platform-specific results were red herrings. This is a general VCL bug in drawing bidi text when fallback runs have a different direction than the preceding character in the base layout. Whether this bug triggers depends on the string and UI font. The buggy code is also quite old. It's somewhat surprising that it hasn't been reported before, but it may just be luck: it's only possible in a few places, for example the GUI and metafiles. Writer and Edit Engine avoid the bug by having to split the text at the position where the bug would happen, because that's a script family change.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/98057a0e54f39160121f7c88b19250e6085d5343 tdf#165510 vcl: Fix incorrect adjustment of bidi MultiSalLayouts It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 73494 has been marked as a duplicate of this bug. ***
(In reply to Jonathan Clark from comment #5) > It's somewhat surprising that it hasn't been reported before So, we now know it was reported on 2014-01-11 at the latest. Thanks, Khaled, for the find.