Apache OpenOffice (AOO) Bugzilla – Issue 17624
Arabic Tashkeel (a.k.a. Diactric) bug : ZWSP characters are given spaces in some fonts!
Last modified: 2008-12-06 20:21:05 UTC
Hello, I'm using OpenOffice RC1 release , I captured some issues that I want to to report to you. The Taskheel must be Zero Width Spacing (ZWSP) character according to UNICODE. OO RC1, does not honor that and it adds a space, breaking the arabic word (as arabic letters with tashkeel should remain continuous). See the attached screen shot and the annotated screenshot. Steps to reproduce: a. Enabe CTL : b. Open the attached sxw arabic text file. ( you can download arabic fonts from ArabEyes.org and those fonts work fine with other software). c. You will notice (according to the annotated screen shot that there is a space caused by the tashkeel. [ in Arabic many letters are connected together unless there is as space ] thanks for all the developers who made OpenOffice possible . Best, Kefah and Hamzeh from freesoft.jo
Created attachment 8138 [details] Contains screenshots and an sxw file showing the bug.
cp->hdu: looks like something for you
elaboration: Tashkeel characters (diactrics : combining and format marks) are "transparent characters" according to Unicode 3.0 reference, chapter 8.2, cursive joining, R1 "Transparent characters do not affect the joining behavior of base (spacing) characters." and they give an example. Also Table 8-2 on the same chapter defines tashkeel as Transparent Class T. The fix is in giving those charcters zero width spacing and laying them on the previous letter. - Kefah.
Confirmed and setting target to 11pp1 For newer builds the problem is gone on win32 platforms, on unx platforms it is still there. The balancing of what to feed the external layout engines and how to merge the results back still needs some work. I also noted a regression when the multicolored words are used in CTL text.
In CWS vcl7pp1r2 there are now many fixes for this problem. When the view in the "Online Layout" view mode looks good, everything is fine. Unfortunately this is not always the case, since there still seem to be some problems when the text + opentype font fed to icu don't result in properly layouted glyph vectors. It seems in some cases a Latin layout is performed instead of the Arabic one even though an ArabicLayoutEngine is used. Example: U+0639 U+0635 U+0628 U+064A U+0629 in KacstLetter 1.4. Still analyzing...
Retargeting.
Because of limited resources for OOo1.1.2 we decided to shift this task to later release.
it seems that this issue will keep jumping to later releases. what can be done to have it included soon, can an OO developer point to the cause of this issue, and paybe a patch for it will come soon.
I tested with 1.1.3 and noticed that with some fonts this bug disappears. For example with Lucida family fonts: "LucidaBright", "Lucidasans", and "Lucidatypewriter", also with Tahoma every thing is Ok!!
Looks like this issue is a duplicate of http://qa.openoffice.org/issues/show_bug.cgi?id=14069 (the hebrew diacritics taking their own letter space instead of overlapping the previous letter)
Problems: 1.At end of line vocalization is not shown. 2.Vocalization not displayed after changing color of letter. 3.Before point, comma etc. vocalization is not shown. 4.1. and 2. at previous versions as well. 5.Error persists at any alignment chosen. 6.I encountered the same problem with end of line vocalization in Hebrew. Kind regards Shimshon
retarget to 3.1
Works in OOo3.0 (tested in CWS kashidafix). The only remaining issue when loading the bugdoc is that changing the attribute (like font color, text background, font size) of partial words is currently not supported especially in CTL scripts. E.g. the bugdoc contains the word U+062D U+0645 U+0651 U+0650 U+0634 The U+062D U+0645 (Hah + Lam) should get into one glyph, but after the U+062D there is an attribute change of the background color and the text color, and also after the U+0645 the text color changes. So what to do when the text color changes inside one glyph? @fme: I suggest that the WriterEngine/EditEngine should prevent attribute changes inside CTL words, because they don't make much sense. Should I write a followup issue for this enhancement? Other than that the most appropriate status of this issue is not reproducable anymore.
[...] @fme: I suggest that the WriterEngine/EditEngine should prevent attribute changes inside CTL words, because they don't make much sense. Should I write a followup issue for this enhancement? [...] Well, you can make some efforts to handle this case in the UI, but you certainly cannot suppress attribute changes on the file format level.
worksforme -> closed