Re: ZWNJ in IDN (Burmese Issues)

From: Ngwe Tun (ngwestar@gmail.com)
Date: Wed Nov 23 2005 - 20:02:00 CST

  • Next message: Philippe Verdy: "Re: Latin glottal stops (was: Apostrophes)"

    Dear Javier SOLA

    On 11/24/05, Javier SOLA <lists@khmeros.info> wrote:
    >
    > Ngwe Tun,
    >
    > Correct support for the script includes, among other things, reordering
    > (which -unlike in Khmer- you are now doing inside the font) and
    > recognition of clusters. I believe that Uniscribe does not officially
    > support Burmese, but it renders correctly clusters that are correct, as
    > no script-specific functions are required. If I understand correctly, it
    > will not recognise correctly clusters that are incorrect (it will not
    > insert dotted circles as support for incorrect dependent characters).

    1) yes, reordering properly works in font. It's too slow when processing in
    huge document/file.
    2) We can't identify burmese cluster.
    3) We can't render correctly for illegal sequences; because of we need to
    build dotted circle rules.
    4) some time we need to remove whole cluster. but it's not supported yet.

    The character for separation of words should be ZWSP (Zero Width Space),
    > and not ZWNJ. ZWNJ should normally be used for modification of rendering
    > of clusters.

    I would be learn more deeply in word boundary and cluster identification.

    Thanks.

    Ngwe Tun

    Javier
    >
    > Ngwe Tun wrote:
    >
    > > Hi Richard,
    > >
    > > Thanks for pointing to appropriate place.
    > > Yes, You are right that's not security but it is encoding problem.
    > > If you say so misrendering issues, every rendering engine can't detect
    > > ambugity, am I right?
    > >
    > > I'm sure that Service Pack 2 or updated uniscribe engine supports
    > > burmese language. you can try it out under
    > http://www.openmm.org/opentype
    > >
    > > Anybody, please figure out pit fall rendering problem of recent
    > > Unicode Standard.
    > >
    > > Regards
    > >
    > > Ngwe Tun
    > >
    > >
    > >
    > > On 11/21/05, *Richard Wordingham* <richard.wordingham@ntlworld.com
    > > <mailto:richard.wordingham@ntlworld.com>> wrote:
    > >
    > > Ngwe Tun wrote:
    > >
    > > > You said so there is not an issue. I don't agree that.
    > >
    > > I don't believe it's a security issue. The misrendering should be
    > > consistent and preserve differences.
    > >
    > > > Windows XP Service Pack 2 or VOLT User Community's updated
    > uniscribe
    > > > engine
    > > (usp10.dll) supports both of khmer and burmese. So, We tried it
    > > with burmese
    > > language. But It's not perfect yet for burmese.
    > >
    > > Which version is this? Service Pack 2 didn't seem to upgrade to
    > > usp10.dll.
    > > I'm using an intermediate version that supports Khmer but not
    > Burmese.
    > >
    > > > 1) I agree that virama ZWNJ consonant was distinct virama
    > > consonant. But
    > > > We
    > > have some issues cases as follows;
    > > ....
    > >
    > > > 2) Another issues is kinzi problem
    > > > a) In Unicode 4.0, Chapter 10, kinzi assign as nga virama (1004
    > > 1039)
    > > > b) and also medial ya, ra, wa, ha assign as virama [ya ra wa ha]
    > > (1039
    > > > [101A
    > > 101B 101D 101F])
    > >
    > > > So We got problem in combination of nga and medial. While
    > > combination of
    > > > nga
    > > (1004) and medial wa (1039 101D), it may appear/render wa(101D) +
    > > kinzi(1004
    > > 1039).
    > >
    > > > I guess so it should be add ZWJ after virama, It might be more
    > > safe for
    > > collision or selecting ambiguity. I'm right.
    > >
    > > > I would like to get responses in these issues.
    > >
    > > The Indic list is probably more appropriate. (To join, send
    > > message to
    > > ecartis@unicode.org <mailto:ecartis@unicode.org> with subject
    > > 'subscribe indic'.) There's an attempt to
    > > get a consistent resolution to the rendering problems.
    > >
    > > Richard.
    > >
    > >
    > >
    >
    >



    This archive was generated by hypermail 2.1.5 : Wed Nov 23 2005 - 20:09:08 CST