Created attachment 183252 [details] Example file that shows bad horizontal black lines Description: If you open the attachment, which is a DOC file, you will see bad Horizontal lines in Arabic/Persian text inside a text box. Steps to Reproduce: 1. Open the attachment Actual Results: Bad Horizontal lines (kashida) can be visible. The black lines should join the characters, and should not appear outside them. Expected Results: Kashida should be inserted in the correct position, Reproducible: Always User Profile Reset: Yes Additional Info: You may need "B Nazanin" font, but the problem should also be visible with other fonts. OK with LO 7.4: Version: 7.4.0.3 / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Reproducible with the latest LO 7.5 dev master: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fe1681b902caed0aaf9157ec31062d7627a1e1b9 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded The file is downloaded from: https://ie.aut.ac.ir/files/ie/files/%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8_%D9%88%D8%A7%D8%AD%D8%AF.doc
Created attachment 183253 [details] PDF output from LO 7.5 dev master The output is not OK. There are kashidas which are placed incorrectly.
Created attachment 183254 [details] LibreOffice 5.0 In LO 5.0, gaps are visible, but no extra black lines Version: 5.0.0.1 Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e Locale: en-US (en_US.UTF-8)
Created attachment 183255 [details] LibreOffice 5.3 In LO 5.3, there are no gaps, but bad positioning of black horizontal lines is visible. Version: 5.3.0.1 Build ID: 3b800451b1d0c48045de03b5b3c7bbbac87f20d9 CPU Threads: 8; OS Version: Linux 5.15; UI Render: default; VCL: x11; Layout Engine: new; Locale: en-US (en_US.UTF-8); Calc: group
I should add that I mistakenly written in comment 1 that it the output is OK with LO 7.4. Unfortunately it is not. The problem looks different in different zoom levels.
I can reproduce this bug can and confirm this.
There is this bug in LO 7.4.2.3 too.
(In reply to افشین from comment #5) > I can reproduce this bug can and confirm this. Please provide the build information from "Help > About LibreOffice".
(In reply to افشین from comment #5) > I can reproduce this bug can and confirm this. Version: 7.4.2.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fa-IR (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.4.2~rc3-0ubuntu0.22.04.1~lo1 Calc: threaded
@Khaled: Could I have your opinion/view about this issue here please? This is one of the few issues around kashida which is still remaining.
I believe it is a limitation of the justification algorithm of Edit Engine; when there is an Arabic text it will always try to use kashida even when the space that is needed is less than the kashida width. Writer is smarter and will skip kashida and use spaces in such cases. Text boxes, even in Writer, use Edit Engine.
If some one is looking for code pointers, look for GetMinKashida() use under sw/, and try to locate the corresponding code under editeng/ and make it do something similar with GetMinKashida().
(In reply to خالد حسني from comment #11) > If some one is looking for code pointers, look for GetMinKashida() use under > sw/, and try to locate the corresponding code under editeng/ and make it do > something similar with GetMinKashida(). I am certainly interested in fix this issue. :-) It seems to be this part of the code: https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit3.cxx?r=f9395a12#2270 Commenting 10 lines from 2272 to 2281 out removes the kashida completely.
(In reply to Hossein from comment #12) > (In reply to خالد حسني from comment #11) > > If some one is looking for code pointers, look for GetMinKashida() use under > > sw/, and try to locate the corresponding code under editeng/ and make it do > > something similar with GetMinKashida(). > > I am certainly interested in fix this issue. :-) > > It seems to be this part of the code: > https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit3. > cxx?r=f9395a12#2270 > > Commenting 10 lines from 2272 to 2281 out removes the kashida completely. Yes. Now this code does not check if the adjustment being added against Kashida glyph width. I think the simpler adjustment is to check if nMore4Everyone >= MinKashidaWidth(), else drop all kashida positions. A smarter fix is to drop enough Kashida positions to make the condition is true. None of this is tested, so their might be extra complication, and it might be god idea to check what Writer does (I haven’t checked what it does exactly, to be honest) and do something similar for consistency.