Hello Mr. Eric Muller, > It is in Unicode 4.0, section 10.3, page 273, and you can see it at: > <http://www.unicode.org/versions/Unicode4.0.0/ch10.pdf#G24999>
Thank. > > 1021 1013 1031 101B 102D 1000 1014 1039 200C 1012 1031 102C 1039 200C 101C > >102C 0020 1042 1048 0020 1042 002C 1040 1040 1040 0020 1000 1030 100A 102E=> > >"US$28 2,00 ...?" I think help? 1000 1030 100A 102E 1015 102C > > > >Just one character wrong 1031on third place should be 1012. > > > my original: 1021 1013 1031... > your correction: 1021 1013 1012 ... > > I am a bit confused, and looking more carefully, my new guess is: 1021 > 1019 1031... Apparently, that makes the first word sound like "american". Sorry, my misstake. It should be second place 1013 -> 1012. You may be right with your sample but currently $ use with 1012. > >1010 102D 101B 1005 1039 1006 102C 1014 1039 200C 1025 101A 1039 101A 102C > >1025 1039 200C 1018 102F 102D 1037 0020 2018 1015 1004 1039 200C 1012 102C > >1014 102E 2019 0020 101B 1031 102C 1000 1039 200C => " 'PandaNi' for zoo..." > I think I understand. Also, I corrected 1018, which should be 101E. 1018 102F 102D 1037 (for), 101E 102F 102D 1037 (to) Both is useable. > Just to be clear, I am not proposing any modification to the encoding > model. At best, I can think of clarifications that could help people > like me, who have limited knowledge of the script. I am also not to try to change the standard. I am currently trying to figure out currenting encoding limitations and looking for ways to extend it. > In another place in your message, you mention that the current model is > not optimal for sorting. I am not a specialist of sorting, but this is > not an entirely unusual situation. It is in general not possible to make > the encoding model such that it is optimal for all processings > (rendering, sorting, etc.) You may want to check carefully the UCA, to > see if and how it can handle proper sorting. Yes I know and thank for your advice. I'm finally accupting the encoding model is not optimal for rendering and sorting. But there is still two thing I am still afraid,... One: encoding model must have abality to quick word cutting for sort, wrap, search. -Currently I see posibility with wraping at graphite. Two: encoding model must useable with current rendering systems or it will be in paper tiger, (three years!). -I see it can work with Graphite with intelligent input method. But what about other system? OpentypeFont doesn't handle line wraping Uniscribe did. But what about Vowel Sign E (1031) handeling? to move front and back? Sorry I put up too much feeling. Maung TunTunLwin [EMAIL PROTECTED]
