Bug 151748 - Bad Horizontal lines (kashida) in Arabic/Persian text inside a text box
Summary: Bad Horizontal lines (kashida) in Arabic/Persian text inside a text box
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: RTL-CTL Kashida-Justification
  Show dependency treegraph
 
Reported: 2022-10-25 10:51 UTC by Hossein
Modified: 2022-12-10 20:25 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Example file that shows bad horizontal black lines (155.50 KB, application/msword)
2022-10-25 10:51 UTC, Hossein
Details
PDF output from LO 7.5 dev master (41.18 KB, application/pdf)
2022-10-25 10:53 UTC, Hossein
Details
LibreOffice 5.0 (62.71 KB, application/pdf)
2022-10-25 10:58 UTC, Hossein
Details
LibreOffice 5.3 (53.40 KB, application/pdf)
2022-10-25 11:00 UTC, Hossein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hossein 2022-10-25 10:51:03 UTC
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
Comment 1 Hossein 2022-10-25 10:53:06 UTC
Created attachment 183253 [details]
PDF output from LO 7.5 dev master

The output is not OK. There are kashidas which are placed incorrectly.
Comment 2 Hossein 2022-10-25 10:58:55 UTC
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)
Comment 3 Hossein 2022-10-25 11:00:19 UTC
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
Comment 4 Hossein 2022-10-25 11:08:17 UTC
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.
Comment 5 افشین 2022-10-25 11:12:36 UTC
I can reproduce this bug can and confirm this.
Comment 6 افشین 2022-10-25 11:13:54 UTC
There is this bug in LO 7.4.2.3 too.
Comment 7 Hossein 2022-10-25 12:20:03 UTC
(In reply to افشین from comment #5)
> I can reproduce this bug can and confirm this.
Please provide the build information from "Help > About LibreOffice".
Comment 8 افشین 2022-10-26 04:44:55 UTC
(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
Comment 9 Hossein 2022-11-21 23:45:31 UTC
@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.
Comment 10 خالد حسني 2022-11-22 07:14:08 UTC
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.
Comment 11 خالد حسني 2022-12-08 15:40:56 UTC
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().
Comment 12 Hossein 2022-12-08 23:51:03 UTC
(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.
Comment 13 خالد حسني 2022-12-10 20:25:08 UTC
(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.