<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 14/12/12 21:33, Martin wrote:<br>
</div>
<blockquote cite="mid:50CB7EFC.8040902@mfriebe.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 13/12/2012 14:39, Martin wrote:<br>
</div>
<blockquote cite="mid:50C9E887.7060903@mfriebe.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><br>
</div>
Ok, bad news, I did some more testing myself, and it turns out,
that WIndows allocates the extra space (song connection line)
just anywhere in the word, or at the end of it, but not always
where the ligation is.<br>
<br>
</blockquote>
.....<br>
<blockquote cite="mid:50C9E887.7060903@mfriebe.de" type="cite"> So
what's next. <br>
The only way to support this, is to make SynEdit aware of the
ligatures. And that is a lot of work, so it will take more time.
And I don't yet know when I will schedule it....<br>
</blockquote>
<br>
Ok, I found a quick way to get a use-able behaviour.<br>
</blockquote>
:)<br>
<blockquote cite="mid:50CB7EFC.8040902@mfriebe.de" type="cite"> <br>
* it is currently WINDOWS ONLY<br>
</blockquote>
:(<br>
<blockquote cite="mid:50CB7EFC.8040902@mfriebe.de" type="cite"> * It
will NOT be enabled by default in the IDE (but if anyone needs it,
you can add it for your own projects, or even the IDE)<br>
<br>
- define WithSynExperimentalCharWidth and it should work (need to
recompile SynEdit package)<br>
- define SynSystemWidthChars for log messages (should there be
problems)<br>
<br>
- Adds a small slowdown, but hardly noticeable <br>
- not limited to Arabic, should do all languages, if windows does
<br>
- according to my tests it works for lines up to 32001 chars.
After that the OS does not handle the line (SynEdit would need to
split it) <br>
In this case SynEdit behaves (for that line) as if the define
was not present. <br>
- ligatures are handled as follows. <br>
There is no middle caret <br>
Depending on the caret being before or after (and accordingly
backspace or delete being used) the first or 2nd char is deleted <br>
# So it is 2 chars, but any caret move will just be translated
into skipping the middle pos <br>
</blockquote>
<br>
When you mention ligatures, do you mean any 2 connected characters
(ex: يحب), or characters that combine such as Lam Alef (لا)?<br>
<br>
I tested the behaviour of Libre Office Writer (Ubuntu):<br>
<br>
- Damma or shadda or similar will combine with the affected
character and form one character as far as the cursor movement is
concerned. Backspace after the combined character will remove the
damma. Delete before the character will remove both.<br>
<br>
- Lam Alef produced by pressing a single keyboard key (ﻷ) acts as a
single character in all aspects.<br>
<br>
- Lam followed by Alef will combine visually into one character (لا)
but acts as 2 characters in all aspects.<br>
<br>
Stephano<br>
</body>
</html>