From: Maung TunTunLwin (maungttlwin@myanmar.com.mm)
Date: Thu Sep 25 2003 - 13:14:39 EDT
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
maungttlwin@myanmar.com.mm
This archive was generated by hypermail 2.1.5 : Thu Sep 25 2003 - 14:31:08 EDT