Bug 104921 - Make Arabic text justification more robust
Summary: Make Arabic text justification more robust
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: خالد حسني
URL:
Whiteboard: target:7.5.0
Keywords:
Depends on:
Blocks: 116969 Kerning Kashida-Justification 87731 106309 106653 108604 112849 114257
  Show dependency treegraph
 
Reported: 2016-12-25 11:05 UTC by خالد حسني
Modified: 2022-09-30 14:55 UTC (History)
5 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description خالد حسني 2016-12-25 11:05:30 UTC
Description:
Currently finding kashida insertion positions and the width of each is done by Writer, but the actually kashida insertion is done by VCL. However, the positions and widths are not communicated explicitly between the two; instead Writer will modify the DX array at the kashida insertion position by the required width, then VCL will guess based on the character and script whether a given DX adjustment is a regular width change or a kashida insertion. This is clearly very brittle and is a source of all kinds of hard to fix random kashida insertion bugs.

To fix this, Writer should explicitly pass the kashida insertion points and widths to VCL, separate from the DX adjustments.

Actual Results:  
 

Expected Results:
 


Reproducible: Always

User Profile Reset: 

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 Buovjaga 2018-02-18 18:20:33 UTC
*** Bug 114257 has been marked as a duplicate of this bug. ***
Comment 2 خالد حسني 2018-02-19 01:43:43 UTC
From bug 112849 comment 4:

> Kashida in LibreOffice is fundamentally broken:
> 
> // A note on how Kashida justification is implemented (because it took me 5
> // years to figure it out):
> // The decision to insert Kashidas, where and how much is taken by Writer.
> // This decision is communicated to us in a very indirect way; by increasing
> // the width of the character after which Kashidas should be inserted by the
> // desired amount.
> //
> // Writer eventually calls IsKashidaPosValid() to check whether it can
> insert a
> // Kashida between two characters or not.
> //
> // Here we do:
> // - In LayoutText() set KashidaJustification flag based on text script.
> // - In ApplyDXArray():
> //   * Check the above flag to decide whether to insert Kashidas or not.
> //   * For any RTL glyph that has DX adjustment, insert enough Kashidas to
> //     fill in the added space.
> 
> from
> https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=vcl/source/gdi/
> CommonSalLayout.cxx;h=8e8565717932088558ee7a4b31fc0bfe405e98e3;hb=HEAD#l698
> 
> The insanity described above together with the the whole DX array madness
> and the use of integers to hold glyph positions, makes is so that any
> rounding errors would cause VCL to think that writer wants to insert a
> kashida in this place.
> 
> Fixing kashida once and for all requires 1) making the communication between
> Writer and VCL explicit e.g. have a separate “kashida insertion points”
> array 2) Kill DX array for good and enter the 21 century (it is an API
> “inspired” by Windows 3.1 3) Fix rounding errors by preserving fractional
> glyph positions in a way or another.
Comment 3 QA Administrators 2019-04-13 02:51:20 UTC Comment hidden (noise)
Comment 4 خالد حسني 2019-04-13 11:32:31 UTC
Still an issue.
Comment 5 QA Administrators 2021-04-13 03:40:02 UTC Comment hidden (noise, obsolete)
Comment 6 Commit Notification 2022-08-14 19:11:21 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3901e029bd39575f700e69a73818565d62226a23

tdf#104921: Cleanup Kashida insertion logic

It will be available in 7.5.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.
Comment 7 Eyal Rozenberg 2022-08-14 21:08:11 UTC
Wow, 8 bugs down in one strike... nicely done! Thanks, Khaaled.