UniMM Blogger Test Blog

Reorder in Myanmar

2007-12-08T11:26:00.000-08:00

Caution: This article/post marked as to update for latest Unicode 5.1 glyph code point assignment number. But logical and visual sequence issue has the same effect. I'll re-edit this article with Unicode 5.1 character code chart as soon as possible.
---
Reorder?
This is under testing/discussion and comments are most welcome. Please also read feature tag session. Kindly see the presentation below:

See bigger picture at filebrowser.

Description #reor:
Medial present all its formations, Vowel present U+1031 Dependent Vowel E and Consonant present all possible consonants.

Update 1 #reor:
Refer to above presentation image, the first pipeline(client reorder state) could be solved in opentype. It's suggested that reorder through GSUB implementation should be only for client display purpose. But this would still let the users to force type in logical form regardless of syllable and it is not opentype recommended solution either. Especially in Vowel E(U+1031). Then opentype should also be prevented from users to type in wrong logic sequence form by using dotted circle (may be U+25CC) for both Medial and Vowel E. If not, the font may not safe enough for production usage as unicode compliant.

This article is a solution propose to be done in text rendering. Not preferably in font side. But opentype font can be done the same job if developer wants to imply. It should better be in renderer. Until rendering is not supported,

It will not achieve all the tasks which stated in presentation
Opentype has to implement client display reorder (visual reorder) through GSUB
Opentype has to prevent from wrong input sequence by using dotted circle
Users have to type in Unicode logical sequence or use Smart Input Method Editor

References:

Opentype & Uniscribe
http://www.microsoft.com/typography/Glyph%20Processing/intro.mspx
http://www.microsoft.com/typography/developers/opentype/default.htm
http://www.microsoft.com/typography/developers/uniscribe/default.htm
http://msdn2.microsoft.com/en-us/library/ms776488.aspx [MSDN]
http://msdn2.microsoft.com/en-us/library/ms776535(VS.85).aspx

Opentype and Devanagari shaping engine
http://www.microsoft.com/typography/otfntdev/devanot/shaping.aspx

Extra
http://msdn2.microsoft.com/en-us/library/ms776535(VS.85).aspx
http://msdn2.microsoft.com/en-us/library/ms748985(VS.85).aspx [.Net 3.0]

Self-substitution is referential

2007-11-22T21:33:00.000-08:00

"...trying to reorder glyphs by doing a multiple substitution to produce extra glyphs and then a ligature to remove the excess..."

This process could probably note as "Clone/Prune" or be called Cloning then Pruning. The drawback is that it needs to make something un-ordinary approach that Opentype do not recommend it. But there is no other solution for way out then this method.. This is also known as about "Visual glyphs reordering through GSUB".

This is a great impact for me for the time around 2006 development trend.. I were trying so hard to make this happen on Fontforge 2005 and eailer 2006 builds; while VOLT developers can do one (I believe time around Myanmar1 release). So I were asking to FF's user list about this on 2006 May 25. But that didn't resolve though I went on to opentype list and reading Devanagari Script and AAT indic re-arrange by replied mails. Anyway, good that I could read and got some idea about reordering from Devanagari script and I've one positive discussion about Myanmar "Reordering GSUB Vs Uniscribe" on opentype list especially from those indic scripts' opentype developers. And latter I could conclude above Reorder in Myanmar article aka #reor and still this reorder issue is lasting longer by far as un-certain solution.

And the same time FF's prevention for __ligature self-substitution issue__ still existed and stalled the UniMM progress that time; until me & Mr.George discussed again on 2007 Feb 24 about this issue.

Viola!! this time we caught the gap between us. Then after, later of FF's builds, I won't see this message anymore;

"A ligature may not be made up of itself. This substitution is self-referential."

Instead;

"This substitution is self-referential. Is this international? Yes|No"

So, in summary, this is the one big reason about why UniMM is being delayed. (Good Excuse huh :-P)

UniMM Library: CMAP

2007-11-22T18:42:00.000-08:00

Basically, the main idea of preparing UniMM Library Book is that, it meant another developer(s) to use back UniMM as library, thus re-usable work. As you might know that there are some point of complexity for implementing Burmese digital font rather than designer/artworks concept. So, UniMM will go through this process one time and expect to solve UTN11 glyph processing in each of smart font technology. To example about what the re-usable works are:

#fontforge

#create new plain BMP

#follow the way UniMM CMAP

#goto Myanmar Unicode range U+1000 to U+109F and draw glyphs

#goto non-Unicode ranges and draw as UniMM CMAP glyphs

#import UniMM lookup table rulesets

So, CMAP naming is one of the important factor consideration for UniMM development. According to Abobe paper at:

http://www.adobe.com/devnet/opentype/archives/glyph.html

Some part of UniMM need to re-factorize what it has been followed and what it has not followed, yet.

UniMM already followed or have to follow:

"uni" for unicode range glyph naming

"_" underscore for non-unicode range glyph naming

"." dot for alternate ligature glyph and nested tag

Stack

2007-09-21T09:26:00.000-07:00

What is Ligature?

Ligatures are two or more glyphs combined to form a single new glyph.

The Unicode 5.1.0(beta) with UTN11-2 rule for Myanmar Burmese stacked characters or syllable chaining or PatSint (in Burmese phonetic) is as shown below.

UniMM Stack (TruetypeOpen, probably because this truetype also loaded in Uniscribe, see below.)

Myanmar3 Stack (This is Opentype build only, so it is okay that no stacking on ATSUI.)

PadaukOT Stack (This is Opentype build only, so it is okay that no stacking on ATSUI.)

'morx' test about Cocoa draw and ATSUI rendering for Myanmar Stack in UniMM

Probably, my first time see-to-believe about ATSUI processing for Unicode that respect to Myanmar (Burmese) case in my hand.. Cool!

Because I've already seen-to-believe about Opentype and Uniscribe Unicode rendering. The following is all opentype/uniscribe loaded together on MS Word 2003 processor.

In summary, character stacking in Myanmar Burmese is a simple Ligature Substitution which I proposed to use font-registry of either of 'rlig' or 'liga'.