Re: Prepending vowel exception in Lontara/Buginese script ?

From: Ngwe Tun <>
Date: Tue, 26 Jul 2011 13:50:43 +0630

Dear Phillipe,

On Tue, Jul 26, 2011 at 7:56 AM, Philippe Verdy <> wrote:

> 2011/7/25 Peter Constable <>:
> > I will repeat yet again -- please take note: OpenType Layout does not
> provide any means for describing re-orderings in a font. No such feature is
> feasible.
> In clear texr this means that all those Asian "insular" scripts
> (except Thai, Lao, Tai Viet, which are encoded in visual order, and a
> few other major Indic scripts like Devanagari, Tamil or other scripts
> of India, and Khmer and Lao that have their reordering support) will
> never be supported in Windows before a long time, unless this support
> comes later within .Net which will use its own layout engine which
> "may" work without using Uniscribe (like in the current versions of IE
> and Office).
> But we have alternatives to Uniscribe on Windows. This means that we
> have to ask for support in alternate browsers (Firefox, Chrome,
> Safari, Opera), that will use their own portable text layout engine
> and not the Windows API.
> What are the projects for supporting more scripts in Windows 8 (or
> "Windows Infinite" if I just consider the logo I have seen), if it
> will be built with an increased integration of the browser (HTML5 and
> CSS 2 or 3) in its interface?
> 2011/7/26 Ngwe Tun <>:
> > Dear Phillipe,
> >
> > Burmese was not still support in Windows 7. Hope, we will get burmese
> > support in Windows 8. We are getting Burmese/Myanmar support in AAT and
> > language support in Lion.
> >
> > For the opentype, you can try with tricks for Buginese. Reordering will
> work
> > in Uniscribe itself. So. We tried with GSUB features. rlig or liga
> features
> > support substitute features of glyph. Here is the trick;
> > C = Consonant, E= Vowel, M=Medial
> > 1) CE => ECE => EC
> > 2) CME = CEM => ECEM => ECM
> One problem with this approach is that there will be no way to disable
> the feature, if Windows later performs the reordering itself, because
> then the vowel E will have already slided to the left, and this
> "ligature" may propagate it further to the left, possibly associating
> it to another consonnant.
> We recognize that approach is impossible to use when Microsoft Typography
official support of Myanmar Language. We tried two version as usual. In the
Linux, Pango shaping will try with proper approach such as reordering and
detecting cluster in the shaping engine.

We can't wait 10 years more with under Microsoft official support. We have
some political issues. I continuously attempted to support Myanmar in
Windows. Microsoft Guys said next version of Windows. I agreed that It will
be Support in Windows Infinite.

I do appreciate Peter's discussion here. I don't understand well Microsoft
Policy on adding Language support in previous release. New Tai Lue, Tai Le
was supported in Windows 7. New Tai Lue used to write *Lue* (a.k.a. Tai Lu,
Lü, Lu, Dai Le, Xishuangbanna Dai, Pai-i) a language spoken mainly in the
southern Chinese province of Yunnan by about 260,000 people. There are also
265,000 speakers in Burma, 70,000 in Thailand, 20,000 in Laos and 3,000 in
Source :
In this figure, Burma users are more than the China Users. :)

So such a tweaked font would have to be updated again to remove this
> pseudo-ligature if it uses "liga" or "rlig". That's exactly why I
> spoke about the definition of a specific OpenType feature, whose
> purpose is to be enabled by default on existing OpenType
> implementations that don't perform the reordering, but that would be
> ignored later by any layout engine that knows that it handle the
> reordering itself for that script.
> Such reordering must absolutely NOT be performed by both the font
> features and the text layout engine. This means that if such
> substitution rules are inserted in an OpenType feature, the engine
> MUST have a realiable way to detect it. The "liga" or "rlig" features
> have not been designed for that purpose (Just consider the already
> registered OpenType features: they are extremely specific to precise
> reordering situations, such as repha forms, or for scripts where some
> diacritics or vowels have various styles for placement before, below
> or after the letter)
> On MacOS, which does not perform any reordering itself, but depends on
> AAT (or OpenType features), there's not risk of stability even for
> tweaked fonts. But on Windows and Linux, or in other layout engines
> that don't use AAT but perform the reordering themselves and not in
> the font, this is definitely a problem.
> > For the wikipedia matters;
> > you should go to the wikipedia incubator.
> > you will see about "How to start a new test wiki?" Section. we have
> started
> > some minority language of Myanmar in this place.
> There's already a Buginese Wikipedia (its default script is Latin, but
> the Buginese script is supposed to be supported as well). Wikimedia
> projects do not make distinctions based on the script used, only on
> the language.
> > We will release Myanmar Linux Desktop in 11/11/11.
> Myanmar/Burmese also already has its own Wikimedia projects (Wikipedia
> and Wiktionnary).
> Personnally I think that the rendering issue is even more critical for
> Wikitionnary (all linguistic editions) where the need for supporting
> "minority" scripts (these are definitely not minority scripts when you
> consider the size of these communities speaking the associated
> languages (and that now want a renewed interest on their historic
> script, not just Latin or Arabic).
> Yes, Rendering issues is big deal to encourage to change recent visual
order to logical order. Most of users resisted to use Unicode Encoding. We
can't encourage much without the advantages of Unicode Encoding in
Microsoft. Microsoft can do the both encoding/jobs pretty done recently.

We are trying to have minority orthography first and developing fonts as
parallel jobs.


Ngwe Tun.

> The first thing they want is a stable resource for the dictionnary to
> stabilize an orthography.
> Philippe.

We will release Myanmar Linux Desktop in 11/11/11.
Received on Tue Jul 26 2011 - 02:23:50 CDT

This archive was generated by hypermail 2.2.0 : Tue Jul 26 2011 - 02:23:51 CDT