On 07/12/12 16:58, Martin wrote:
Did you use "Extra Char Spacing" = 1 ? This is what happens, if not!
(This and a few other real oddities)
And also, it can only be tested on windows. Because on GTK,QT,Carbon
"Extra Char Spacing" is faulty in an other way: It splits the
combining chars into individuals, but since SynEdit does not know.....
The problem is, that by current design, SynEdit has to calculate the
pixel pos of each char on it's own.If it does not calculate the same,
as the OS did when painting (SymEdit gives the OS tokens, fragments of
the line or the whole line) then obviously things will be odd afterwards.
- Long connecting lines are not what I would like, but this is a
monospaced font afterall.
Ok, but can you test them on windows, with "Extra Char Spacing" = 1
I use Ubuntu, and tested only monospaced fonts (source editor). I
understand extra char spacing is for Windows only.
To test proportional fonts, I put a TSynEdit on a form, set the font to
Arial, but the characters were all detached. Did I miss something here?
See that the caret pos is treadet correct, backspace and delete,
insert work (on the correct char) on them, Copying a selection will
copy the highlighted part (except column mode selection, which is not
done yet)
Column selection is fantastic for coding, but is not a prime feature for
Arabic at this stage.
About editing. (backspace and delete, insert)
- combining chars see below.
- ligatures. Caret and selection-wise the ligature, and the
long-connecting-line, are both treaded as one char. One is the 1st,
the other the 2nd char of the ligature (in the order they occur in
text). The behaviour for editing should reflect this. Does it.
- The 456 should have come to the left of the Arabic words.
Ok, that could dbe fixed. Depends on treating digits as weak or strong
LTR. Actually in this case, depends on treating the line end as such)
If the 456 were embedded in the middle of arab, it would have worked.
But they border the EOL, and SynEdit treats the EOL strong LTR (and
bordering weak 456 follows). This gives better result for pascal,
where Arab occurs in strings. "a:='arab';" The '; in the end will and
should be LTR due to bordering the EOL.
OK
This will be fixed eventually, when weak handling is made highlighter
depending
- If you put a shaddah or damma on a character, it gets displayed on
top of the character (correct behaviour). Pressing backspace at this
stage should only delete that addition, and not the character.
Ok, Also simple to fix. Not a painting issue so.
Those are combining codepoints. So backspace must act on codepoints.
The editor understands the diff between "Char" and "codepoint". It is
a question of assigning the right choice to each action (and that is a
question of writing testcases too)
----------------------
About "Long connecting lines are not what I would like."...
Longer connecting lines for monospaced fonts is acceptable especially
that the characters have a fixed width. But it is less tolerable with
proportional fonts.
I understand. And it would not be the final solution. But if all else
works (as described above) then this is a solution, that I believe, I
can reach without too much extra work from where I am now (Will still
be next year...).
And then we had something at least use-able.
The rest will be on my todo list, and has to await it's time, between
other features and debugger.
Excellent work!
Stephano
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
