SynEdit input chinese symbel problem patch.
lazarus / 9-Editor

----------------------------------------------------------------------
steven2 · 2013-07-01 07:38

Hello,every body!

  I was found a bug for input chinese ,below is my patch !

  My env:
  windows xp sp3
  lazarus 1.0.8

  The below .zip file contain two files:

  synedittextdoublewidthchars.pas  is modified file, and
synedittextdoublewidthchars2.pas is a new unit file.

  You can compare them with lazarus org. file.

  I think you can use it for new versions.

  I am a chinese.

----------------------------------------------------------------------
Martin_fr · 2013-07-01 08:17

Also please upload it to http://bugs.freepascal.org/ instead of the
forum. It may be forgotten, if on the forum.

Please also add what the problem is? I assume some chars are displayed
overlapped? Please indicate (in hex) which chars.

If it is full versus half width issue:
What property do the chars have in
http://www.unicode.org/Public/5.1.0/ucd/EastAsianWidth.txt

Some chars are "ambiguous", I have not yet checked where the unicode
standard defines how to resolve them. If your patch deals with them we
need to find where this is defined.

------
I will be away for 2 weeks, so there may not be a reaction in that
time.

----------------------------------------------------------------------
Martin_fr · 2013-07-01 08:30

Just looked at the patch.

----
The list contains items like 0x0300 (accent) which are ambigious.
(Though it seems, this is for combining, which is not handled in that
file.)

On the other hand
Code: [Select]  if Line^ < #$e1 then continue;It is not called for
them anyway. So why include them?

----

Code: [Select](ucs  > $2329) and (ucs <$a4cf)or
This range contains a lot of codepoints that are not fullwidth
according to the copy of unicode documentation that I found.
Where did you get this?

----
Why throw away the existing code entirely? How many codepoints are
missing or wrong?

----------------------------------------------------------------------
steven2 · 2013-07-01 08:34

Thanks for your reply.

----------------------------------------------------------------------
Martin_fr · 2013-07-01 08:38

I edited the last note

----------------------------------------------------------------------
Martin_fr · 2013-07-01 08:42

Maybe you want to experiment with this (windows only)

 {$IFDEF WithSynExperimentalCharWidth}
  SynEditTextSystemCharWidth,
  {$ENDIF}

It can probably be extended.

However, this is experimental, and will not  make it into production
code any time soon.

------------
Note:
About combining codepoints. They must be known in
Code: [Select]function TSynEditStringList.LogicPosIsCombining(const
AChar: PChar): Boolean;

Or backspace and delete will not work

----------------------------------------------------------------------
steven2 · 2013-07-01 08:44

I use the function convert UTF-8 charator to Unicode ,and then use the
second unit to search the double width charactor ,return not a double
charactor result while the charactor is not a UTF-8 charator.

----------------------------------------------------------------------
Martin_fr · 2013-07-01 08:48

But the 2nd unit seems to contain a lot of unrelated functionality,
that i not needed?

Where did it originate from (seems to be copied from somewhere?)

Again, which codepoint are missing in the original.

----------------------------------------------------------------------
steven2 · 2013-07-01 08:55

I was found this code from Internet ,forgot it's URI now.

May be the code have a lite bugs.

Buy I use this patch in my tools is very well.

----------------------------------------------------------------------
Martin_fr · 2013-07-01 09:06

Well I can not take a patch without knowing the origin.
I need to be able to verify that using it does not violate any
licenses.

Also as I explained, I would rather fix the existing code, than
replace it.
So, if you know which chars are causing the problems?

And, looking at the line I pointed out, the code seems wrong, and will
risk breaking none Chinese text.

All chars must be handled according to the unicode standard.
If that does not work for you, then you may have a font, which is
incorrect.

----------------------------------------------------------------------
steven2 · 2013-07-01 09:13

Thank you very much.