> At 22:51 +0100 2006-04-05, Richard Wordingham wrote:
>
>>As to Michael's point, it would be interesting to see the Mymyanmar
>>encodings for:
>
> Well, just to make certain, I will give you he encodings for these in the
> new model:
>
>>(1) Kinzi + WA
>
> NGA + ASAT + VIRAMA + WA
>
>>(2) Full NGA + tear drop-shaped WA (i.e. medial form)
>
> NGA + MEDIAL WA
>
>>(3) Full NGA + obligatorily round WA (i.e. stacked form)
>
> NGA + VIRAMA + WA
>
>>(4) to (6): (1) to (3) above but with RA instead of NGA.
>
> RA + ASAT + VIRAMA + WA (this is Sanskrit repha wa)
>
> NGA + MEDIAL WA
>
> NGA + VIRAMA + WA
>
>>(7) Burmese KA + medial LA
>
> Well, it depends what you mean by Medial La.
>
> KA + VIRAMA + LA would give the subjoined fullforms LA used in Pali.
>
>>(8) Mon KA + medial LA
>
> Mon KA does not differ from Burmese KA.
>
> KA + MON MEDIAL LA
>
>>Do they all have encodings? I suspect not. See
>>http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3043.pdf for a solution and for
>>other challenges.
>
> The MyMyanmar group supports the new encoding proposal. Htoo Myint Naung
> is preparing transcoding software which will handle the transition. Ngwe
> Tun is also preparing transcoding software for his customers. Everyone is
> hoping for the best and preparing for the best.
>
> I would like Ngwe Tun and Htoo Myint Naung to STOP FEUDING until after the
> WG2 meeting. They are professional competitors, which is fine, but right
> now there is posturing going on, and it is NOT HELPING. Behave yourselves.
>
> Thank you both.
> --
> Michael Everson * http://www.evertype.com
>
> Ngwe Tun wrote:
>
>> I'm very informed to have some pitfalls in mymyanmar (they called unicode
>> standard)
>
>> It should not be come right solution for myanmar user.
>
>>> According to Michael warning, "Linux will be accumulating data that will
>>> need transcoding to the new model if the UTC and WG2 accept the Myanmar
>>> fasttrack." So, If we use that solution in some database or application,
>>> we
>>> have to migrate to new encoding model. And It's still some problem in
>>> data
>>> interchange. If you type myanmar texts with myMyanmar, you will not see
>>> without myMyanmar Fonts. It's not truly unicode standard.
>
> Alas, it probably is. What is needed is an input editor that stops
> characters being stored in the wrong order, as is generally used for Thai.
> (The usual Thai checking is too strict, as Martin has pointed out.) For
> display, you either accept dashed circles for badly ordered codepoints or
> risk being unable to type the code sequence that is being displayed.
>
> Michael Everson wrote:
>
>>> I believe that now is *absolutely* the ***wrong*** time to be
>>> planning to release any software, since there is a change to the
>>> encoding model c
>
>>> Please clarify this issue for me as a matter of URGENCY.
>
> As to Michael's point, it would be interesting to see the Mymyanmar
> encodings for:
>
> (1) Kinzi + WA
> (2) Full NGA + tear drop-shaped WA (i.e. medial form)
> (3) Full NGA + obligatorily round WA (i.e. stacked form)
> (4) to (6): (1) to (3) above but with RA instead of NGA.
> (7) Burmese KA + medial LA
> (8) Mon KA + medial LA
>
> Do they all have encodings? I suspect not. See
> http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3043.pdf for a solution and for
> other challenges.
>
> Richard.
>
> Dear Ngwe Tun,
>
> I think that Michael is right. We can work on the software, make it work
> for the old model (at home), and even make it work for the new model, but
> you might want to wait for UTC and WG2 to decide on the proposal before
> you release it.
>
> You can easily convert data from the old model to the new one... but you
> will never know what happens to the non-coverted original data. Waiting a
> few months will not make a difference.
>
> Regards,
>
> Javier
>
> Ngwe Tun wrote:
>
>> Dear Friends,
>>
>> I'm very informed to have some pitfalls in mymyanmar (they called unicode
>> standard)
>>
>> It should not be come right solution for myanmar user.
>>
>> According to Michael warning, "Linux will be accumulating data that will
>> need transcoding to the new model if the UTC and WG2 accept the Myanmar
>> fasttrack." So, If we use that solution in some database or application,
>> we have to migrate to new encoding model. And It's still some problem in
>> data interchange. If you type myanmar texts with myMyanmar, you will not
>> see without myMyanmar Fonts. It's not truly unicode standard. Please find
>> in my attachment.
>>
>> I founded some pitfalls screen shoots in http://mymyanmar.host.sk
>>
>> See you.
>>
>> Ngwe Tun
>> CEO
>> Solveware Solution
>> On 3/21/06, *Michael Everson* <eve...@evertype.com
>> <mailto:eve...@evertype.com>> wrote:
>>
>> Dear colleagues,
>>
>> I am very alarmed to have read something that Ngwe Tun sent to the
>> Unicode list today. He said:
>>
>> >We are going to enable Burmese for pango and qt rendering engine. It
>> >would be release in next month. So, we can express opentype
>> >specification for burmese when succeeded in pango/qt modules.
>>
>> What does this mean? There are only two things that I can think of:
>>
>> 1) Either Ngwe Tun is planning to release a Unicode 4.1 conformant
>> implementation, in which case anything built on those engines on
>> Linux will be accumulating data that will need transcoding to the new
>> model if the UTC and WG2 accept the Myanmar fasttrack.
>>
>> 2) Or Ngwe Tun is planning to release a non-conformant
>> implementation, jumping the gun and assuming your proposal will be
>> standardized as we have proposed it.
>>
>> I believe that now is *absolutely* the ***wrong*** time to be
>> planning to release any software, since there is a change to the
>> encoding model c
>>
>> Please clarify this issue for me as a matter of URGENCY.
>>
>> Michael Everson
>>
>> Ngwe Tun's full message is here:
>>
>> At 02:08 +0630 2006-03-22, Ngwe Tun wrote:
>> >Dear Perter, Members
>> >
>> >I would like to share about burmese issues relating Uniscribe.
>> >
>> >The Latest Uniscribe Ver 1.606.5095.0 supported to shape burmese
>> >character in lastest Windows 2000 and Windows XP. In OpenType Table
>> >(rlig and kern) features supported render burmese characters
>> >according to unicode encoding. But burmese scripts are complex
>> >script type and we needed to handle reordering, fallback rendering,
>> >cursor movement and word breaking by uniscirbe engine. AFAK, MS
>> >needs to implement script specific function on uniscribe. It mean
>> >everybody said so *Burmese language not supported*, right?
>> >
>> >And Do we need others setting/implementation for Burmese? I mean NLS
>> >data, Locale setting and code page. We have a doubt that somebody
>> >said *no need to implement for specific language*, For every
>> >language, Microsoft will support Microsoft Locale Builder in next
>> >version of vista, is it true for burmese? I guess so Microsoft can't
>> >support rendering engine customization in locale builder. I saw this
>> >screenshots in
>> ><
>> http://blogs.msdn.com/photos/shawnste/images/535611/original.aspx
>>
>> <http://blogs.msdn.com/photos/shawnste/images/535611/original.aspx>>http://blogs.msdn.com/photos/shawnste/images/535611/original.aspx
>> <http://blogs.msdn.com/photos/shawnste/images/535611/original.aspx>
>> >
>> >But Some of Burmese language implementer announced that "Their
>> >OpenType Font & Unicoded implementation succeeded in Microsoft
>> >Windows." We do not accept condition that OpenType font might be
>> >succeeded but uniscribe and input method are needed to implement by
>> >Microsoft. ref:
>> ><http://www.mymyanmar.net/ota.php>
>> http://www.mymyanmar.net/ota.php *you
>> >may see some graphics* (it's wrote down by burmese langauge) So,
>> >Please sujjest me that implementation is suitable for long term use.
>> >Any how, We need to use for that kinds of implementation, if MS does
>> >not implement for burmese.
>> >
>> >Their implementation might be faced some problem when new version of
>> >uniscribe implementation for burmese by Microsoft. May be double
>> >reordering and some infinite loops in rendering.
>> >
>> >And Let me know basis functions of uniscribe for complex script. We
>> >would be avoid some implementation in fonts. We are going to enable
>> >Burmese for pango and qt rendering engine. It would be release in
>> >next month. So, we can express opentype specification for burmese
>> >when succeeded in pango/qt modules.
>> >
>> >Regards
>> >
>> >Ngwe Tun
> At 22:51 +0100 2006-04-05, Richard Wordingham wrote:
>
>>As to Michael's point, it would be interesting to see the Mymyanmar
>>encodings for:
>
> Well, just to make certain, I will give you he encodings for these in the
> new model:
>
>>(1) Kinzi + WA
>
> NGA + ASAT + VIRAMA + WA
>
>>(2) Full NGA + tear drop-shaped WA (i.e. medial form)
>
> NGA + MEDIAL WA
>
>>(3) Full NGA + obligatorily round WA (i.e. stacked form)
>
> NGA + VIRAMA + WA
>
>>(4) to (6): (1) to (3) above but with RA instead of NGA.
>
> RA + ASAT + VIRAMA + WA (this is Sanskrit repha wa)
>
> NGA + MEDIAL WA
>
> NGA + VIRAMA + WA
>
>>(7) Burmese KA + medial LA
>
> Well, it depends what you mean by Medial La.
>
> KA + VIRAMA + LA would give the subjoined fullforms LA used in Pali.
>
>>(8) Mon KA + medial LA
>
> Mon KA does not differ from Burmese KA.
>
> KA + MON MEDIAL LA
>
>>Do they all have encodings? I suspect not. See
>>http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3043.pdf for a solution and for
>>other challenges.
>
> The MyMyanmar group supports the new encoding proposal. Htoo Myint Naung
> is preparing transcoding software which will handle the transition. Ngwe
> Tun is also preparing transcoding software for his customers. Everyone is
> hoping for the best and preparing for the best.
>
> I would like Ngwe Tun and Htoo Myint Naung to STOP FEUDING until after the
> WG2 meeting. They are professional competitors, which is fine, but right
> now there is posturing going on, and it is NOT HELPING. Behave yourselves.
>
> Thank you both.
At 22:51 +0100 2006-04-05, Richard Wordingham wrote:
>As to Michael's point, it would be interesting to see the Mymyanmar
>encodings for:
Well, just to make certain, I will give you he encodings for these in
the new model:
>(1) Kinzi + WA
NGA + ASAT + VIRAMA + WA
>(2) Full NGA + tear drop-shaped WA ( i.e. medial form)
NGA + MEDIAL WA
>(3) Full NGA + obligatorily round WA (i.e. stacked form)
NGA + VIRAMA + WA
>(4) to (6): (1) to (3) above but with RA instead of NGA.
RA + ASAT + VIRAMA + WA (this is Sanskrit repha wa)
NGA + MEDIAL WA
NGA + VIRAMA + WA
>(7) Burmese KA + medial LA
Well, it depends what you mean by Medial La.
KA + VIRAMA + LA would give the subjoined fullforms LA used in Pali.
>(8) Mon KA + medial LA
Mon KA does not differ from Burmese KA.
KA + MON MEDIAL LA
>Do they all have encodings? I suspect not. See
> http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3043.pdf for a solution and
>for other challenges.
The MyMyanmar group supports the new encoding proposal. Htoo Myint
Naung is preparing transcoding software which will handle the
transition. Ngwe Tun is also preparing transcoding software for his
customers. Everyone is hoping for the best and preparing for the best.
I would like Ngwe Tun and Htoo Myint Naung to STOP FEUDING until
after the WG2 meeting. They are professional competitors, which is
fine, but right now there is posturing going on, and it is NOT
HELPING. Behave yourselves.
Dear All,
Please find attached snapshots from pango-enabled firefox with myanmar
pango module we're developing.
- wrong_mymyanmar.png (displaying wrong_mymyanmar.txt)
- true_mymyanmar.png (displaying true_mymyanmar.txt)
- site.png (browsing http://www.mymyanmar.net/viewthread.php?tid=25)
Best regards,
Tin Myo Htet
On 4/5/06, Ngwe Tun <ngwe...@gmail.com> wrote:
> Dear Friends,
>
> I'm very informed to have some pitfalls in mymyanmar (they called unicode
> standard)
>
> It should not be come right solution for myanmar user.
>
> According to Michael warning, "Linux will be accumulating data that will
> need transcoding to the new model if the UTC and WG2 accept the Myanmar
> fasttrack." So, If we use that solution in some database or application,
> we
> have to migrate to new encoding model. And It's still some problem in data
> interchange. If you type myanmar texts with myMyanmar, you will not see
> without myMyanmar Fonts. It's not truly unicode standard. Please find in
> my
> attachment.
>
> I founded some pitfalls screen shoots in http://mymyanmar.host.sk
>
> See you.
>
> Ngwe Tun
> CEO
> Solveware Solution
>
> >But Some of Burmese language implementer announced that "Their
> >OpenType Font & Unicoded implementation succeeded in Microsoft
> >Windows." We do not accept condition that OpenType font might be
> >succeeded but uniscribe and input method are needed to implement by
> >Microsoft. ref:
> ><http://www.mymyanmar.net/ota.php>
> http://www.mymyanmar.net/ota.php *you
> >may see some graphics* (it's wrote down by burmese langauge) So,
> >Please sujjest me that implementation is suitable for long term use.
> >Any how, We need to use for that kinds of implementation, if MS does
> >not implement for burmese.
> >
> >Their implementation might be faced some problem when new version of
> >uniscribe implementation for burmese by Microsoft. May be double
> >reordering and some infinite loops in rendering.
> >
> >And Let me know basis functions of uniscribe for complex script. We
> >would be avoid some implementation in fonts. We are going to enable
> >Burmese for pango and qt rendering engine. It would be release in
> >next month. So, we can express opentype specification for burmese
> >when succeeded in pango/qt modules.
> >
> >Regards
> >
> >Ngwe Tun
>
> Dear Ngwe Tun,
>
> I think that Michael is right. We can work on the software, make it work
> for the old model (at home), and even make it work for the new model, but
> you might want to wait for UTC and WG2 to decide on the proposal before
> you release it.
>
> You can easily convert data from the old model to the new one... but you
> will never know what happens to the non-coverted original data. Waiting a
> few months will not make a difference.
>
> Regards,
>
> Javier
>
> Ngwe Tun wrote:
>
>> Dear Friends,
>>
>> I'm very informed to have some pitfalls in mymyanmar (they called unicode
>> standard)
>>
>> It should not be come right solution for myanmar user.
>>
>> According to Michael warning, "Linux will be accumulating data that will
>> need transcoding to the new model if the UTC and WG2 accept the Myanmar
>> fasttrack." So, If we use that solution in some database or application,
>> we have to migrate to new encoding model. And It's still some problem in
>> data interchange. If you type myanmar texts with myMyanmar, you will not
>> see without myMyanmar Fonts. It's not truly unicode standard. Please find
>> in my attachment.
>>
>> I founded some pitfalls screen shoots in http://mymyanmar.host.sk
>>
>> See you.
>>
>> Ngwe Tun
>> CEO
>> Solveware Solution
>> On 3/21/06, *Michael Everson* <eve...@evertype.com
>> <http://blogs.msdn.com/photos/shawnste/images/535611/original.aspx>>http://blogs.msdn.com/photos/shawnste/images/535611/original.aspx
Dear All,
Please find attached snapshots from pango-enabled firefox with myanmar
pango module we're developing.
- wrong_mymyanmar.png (displaying wrong_mymyanmar.txt)
- true_mymyanmar.png (displaying true_mymyanmar.txt)
- site.png (browsing http://www.mymyanmar.net/viewthread.php?tid=25)
Best regards,
Tin Myo Htet
On 4/5/06, Ngwe Tun <ngwe...@gmail.com> wrote:
> Dear Friends,
>
> I'm very informed to have some pitfalls in mymyanmar (they called unicode
> standard)
>
> It should not be come right solution for myanmar user.
>
> According to Michael warning, "Linux will be accumulating data that will
> need transcoding to the new model if the UTC and WG2 accept the Myanmar
> fasttrack." So, If we use that solution in some database or application,
> we
> have to migrate to new encoding model. And It's still some problem in data
> interchange. If you type myanmar texts with myMyanmar, you will not see
> without myMyanmar Fonts. It's not truly unicode standard. Please find in
> my
> attachment.
>
> I founded some pitfalls screen shoots in http://mymyanmar.host.sk
>
> See you.
>
> Ngwe Tun
> CEO
> Solveware Solution
>