Bug 104921 - Make Arabic text justification more robust
Summary: Make Arabic text justification more robust
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 87731 106309 106653 108604 112849 114257 116969
  Show dependency treegraph
 
Reported: 2016-12-25 11:05 UTC by Khaled Hosny
Modified: 2018-04-12 18:17 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Khaled Hosny 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 Khaled Hosny 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.