Created attachment 181639 [details] Justified Persian/Arabic text Description: As described (in Persian) below, the user could use the justified text until LibreOffice 4.4, but after that the output became incorrect: Problem with justified text in LibreOffice: https://forum.ubuntu.ir/index.php?topic=155184.0 Steps to Reproduce: 1. Open the attachment Actual Results: Text is not justified in page 1 Expected Results: Text should be justified in page 1 Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 56145f237b63a35c142dbccd434fd780badcf489 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 181640 [details] Correct justified text with LO 4.4
Created attachment 181641 [details] Incorrect justified text with LO 7.5 dev master
Created attachment 181642 [details] Vazirmatn font The latest version of "Vazirmatn" font, which is currently 33.003, can be downloaded from: https://github.com/rastikerdar/vazirmatn/releases
This is a regression, bibisected to: commit f0393d7ff69011a16b100541ef18e5090544e4a1 Author: Khaled Hosny <khaledhosny@eglug.org> Date: Mon May 6 16:54:53 2013 +0200 [harfbuzz] Fix text width calculation, 3rd try It turns out storing the width in the layout is not so good idea, because in some mysterious cases when font fallback is involved we call GetTextWidth() without calling LayoutText() first, and we return the width of the previous text run. It seems all I needed is to pass down the X offset with the glyph item, and take it into account when calculating the width.
I’m skeptical that the mentioned commit is the source of this. The formatting seems to be unstable, changing the font fixes the issue, but it shows up again after closing and opening the file. It seems to be related to the tab stops and/or the footnote numbers, which is higher level that the code this commit touches.
This seems to be similar to (if not a duplicate of) bug 138199.
(In reply to خالد حسني from comment #5) > I’m skeptical that the mentioned commit is the source of this. The > formatting seems to be unstable, changing the font fixes the issue, but it > shows up again after closing and opening the file. > > It seems to be related to the tab stops and/or the footnote numbers, which > is higher level that the code this commit touches. You're right. As the other problem with justified Arabic text (bug 146713), It was off by one, and the responsible commit was setting HarfBuzz as the default for the text rendering engine.
Created attachment 182120 [details] PDF Output after removing all footnotes As visible in the output, right after removing all the footnotes, the text goes out of the margin.
This happens with no justification at all.
I spent some time debugging this, but went no where. I have no idea what is going on here or even where to start.
(In reply to خالد حسني from comment #10) > I spent some time debugging this, but went no where. I have no idea what is > going on here or even where to start. We can call this a glitch, because upon requesting re-layout of the text (or even the paragraph), the problem goes away. For example, set Persian language for all text, change the numeral style, or use any other means to force LibreOffice re-layout the text. Then, the problem goes away, even in the output. But after save and reload, the problem is still there. Something is creating invalid data in the text data structures. But, how can we dump that data, and compare it to the situation where the problem is fixed temporarily? Even pressing ctrl+l, and then ctrl+j causes the paragraph to be displayed correctly.
Created attachment 182191 [details] Correct output after forcing re-layout of the text I just set the Persian language for the whole text, and then created the output. Please note that setting the language seems to be unrelated to the bug itself, because you can use any other means of forcing LibreOffice re-layout the text to achieve the correct output.
(In reply to Hossein from comment #12) > Created attachment 182191 [details] > Correct output after forcing re-layout of the text > > I just set the Persian language for the whole text, and then created the > output. Please note that setting the language seems to be unrelated to the > bug itself, because you can use any other means of forcing LibreOffice > re-layout the text to achieve the correct output. Did you try to re-open the file, for me re-opening the file shows the issue again.
(In reply to خالد حسني from comment #13) > (In reply to Hossein from comment #12) > > Created attachment 182191 [details] > > Correct output after forcing re-layout of the text > > > > I just set the Persian language for the whole text, and then created the > > output. Please note that setting the language seems to be unrelated to the > > bug itself, because you can use any other means of forcing LibreOffice > > re-layout the text to achieve the correct output. > > Did you try to re-open the file, for me re-opening the file shows the issue > again. Yes, this is true. The changes are temporary. I think we need to dump and compare the data structures for one of the paragraphs. I wish this could be possible using the UNO object inspector tool, but it is not (bug 142373)