Created attachment 188277 [details] Text with Persian double quotes Description: If you remove a text between Persian double quotes «» and then press ctrl+z, the other text between «» faces problem of bad horizontal lines (kashida). Steps to Reproduce: 1. Open attachment 2. Select text between «», in this case لذا and remove it 3. Press ctrl+z Actual Results: Bad horizontal line (kashida) in the other text between «», in this case برای همين. This problem IS visible in the PDF output if you do exporting. One side note: I found a Firefox an RTL/CTL bug while writing the above paragraph which has a Persian text that is broken across two lines! Expected Results: The text should be rendered as it was when loading the document, without badly positioned horizontal line. Reproducible: Always User Profile Reset: No Additional Info: $ instdir/program/soffice --version LibreOfficeDev 24.2.0.0.alpha0 81726f5af5fda25f0d92ffc8458d7f24eb16f408 I can not open Help > About as it leads to the LibreOffice hang.
Issue is zoom-dependent. I re-saved the example document at 550× zoom to be able to bibisect it. I was looking at the horizontal line poking out to the right of the quoted string. Repro in: Version: 7.3.7.2 / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Not in 7.2: Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Bibisected with linux-64-7.2 repo to first bad commit 74abd7e58426f871b3d9c240c781ffd08d3eedcb which points to core commit: commit 56186db93b7777f7b99a8fbfce82b775e24b7695 author Caolán McNamara <caolanm@redhat.com> Tue Dec 14 21:27:14 2021 +0000 committer Caolán McNamara <caolanm@redhat.com> Wed Dec 15 11:30:55 2021 +0100 tdf#145934 workaround rounding causing 'dancing characters' Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126870 However, before that commit, I could follow the steps and then change the zoom to 490× and see a rogue horizontal line on the "ی". So I don't think that's coming from Caolán commit. The horizontal bar on the "ی" at 490× I can reproduce in 5.3.0.1. 5.3.0.0.beta2 had horizontal lines all over the place at fileopen. I could not reproduce in 5.2.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9d9e3b439883c3c315501f56bb613e080863db64 tdf#156211: Don’t round Kashida width when doing subpixel positioning It will be available in 24.2.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.
The situation seems to be improved/fixed on hipdpi screens, but not in lodpi ones. I’m investigating why screen resolution is still making a difference here.
Created attachment 188522 [details] Screenshot from the glitch in the justified Persian text on Windows U=(In reply to خالد حسني from comment #3) > The situation seems to be improved/fixed on hipdpi screens, but not in lodpi > ones. I’m investigating why screen resolution is still making a difference > here. I still see the problem in hidpi display with 3x scaling Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 56edc523a4aa2a99ce15c66d42a8c7ba55bf1580 CPU threads: 20; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_DE); UI: en-US Calc: CL threaded
It is fixed for me on macOS.
Created attachment 188524 [details] Screenshot from the glitch in the justified Persian text on Linux I also see (In reply to خالد حسني from comment #5) > It is fixed for me on macOS. Also, I still reproduce the problem on Linux with HIDPI and 2x scaling: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 56edc523a4aa2a99ce15c66d42a8c7ba55bf1580 CPU threads: 12; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded
I think this can be related to how the document is processed with undo-redo and also when loaded. Here, if you paste the text "لذا" instead of "redo", which should lead to same content, you will get different output. In other words: Remove, then ctrl+z -> glitch Remove, then paste removed text -> rendering is OK Sometimes, it is reverse. The initial rendering is correct. But when you change and then undo, you will get the correct rendering. tdf#146713 - RTL language overlap problem when mixed with LTR language https://bugs.documentfoundation.org/show_bug.cgi?id=146713 In other words: Initial output -> glitch Change, and then undo -> rendering is OK In both cases, the problem is visible in the PDF output, so it should be possible to safely test if the output remains the same before and after change and undo.
To be honest, I still have no idea what is going on. It seems like under certain circumstances Writer gets the wrong text widths, how and why this happens is not something I was able to identify yet.
Unassigning. I don’t seem to make any progress every time I look into it.