extended/tailored grapheme cluster implementation.
Dear List,
I would like to ask about extended/tailored grapheme clusters
implementation. In Burmese, our smallest unit of grapheme cluster is
syllable level. I found some expression in UAX #29,
Grapheme clusters can be tailored to meet further requirements. Such
> tailoring is permitted, but the possible rules are outside of the scope of
> this document. One example of such a tailoring would be for the *aksaras*,
> or*orthographic syllables*, used in many Indic scripts. Aksaras usually
> consist of a consonant, sometimes with an inherent vowel and sometimes
> followed by an explicit, dependent vowel whose rendering may end up on any
> side of the consonant letter base. Extended grapheme clusters include such
> simple combinations.
Are there any tailoring in any software. Can we implement with
Rendering/Shaping Engine or any other software?
Myanmar Syllable can be formed by Consonant/Independent Vowel + [Medial] +
[Vowel] + [(Cons) (Asat)] + [Tone] + {[Virama] + [Consonant] + [Medial] +
[Vowel]}
[...] is optional.
{...] n times
looking forward your feedback.
Best
Ngwe Tun
--
If everything is possible, Impossible is possible too.
Re: Prepending vowel exception in Lontara/Buginese script ?
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 Vietnam. Source : http://www.omniglot.com/writing/tailue.htm 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 sh
Re: Prepending vowel exception in Lontara/Buginese script ?
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 For the wikipedia matters; you should go to the wikipedia incubator. http://incubator.wikimedia.org you will see about "How to start a new test wiki?" Section. we have started some minority language of Myanmar in this place. Best Ngwe Tun On Tue, Jul 26, 2011 at 1:57 AM, Philippe Verdy wrote: > 2011/7/25 Peter Constable : > > From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe > Verdy > > > >> What would be the behavior of a font that would use GSUB entries (or > >> ligatures) in a feature to implement the reordering that NO renderer > >> currently implements for Buginese ? What will happen later if the > >> renderer does implement it ? > > > > Your question is no coherent: OpenType features cannot be used to trigger > re-ordering. > > Hmmm... Your reply is also incoherent: > > (1) There are lots of OpenType features registered that actually > perform contextual reordering in Indic scripts, including when they > are in fact mandatory for that script (example for repha forms of ra, > or to move ra to a later position after another base consonnant, to > make it shown on the next vowel, or other exceptions needed in khmer, > lao,...). > > (2) These features were even registered by Microsoft. > > (3) Some of them are for pre-base reordering, other contain exceptions > to the usually "mandatory" pre-base order, to change it in a post-base > form in some other contexts. > > >> Does the OpenType specification allow specifying a temporary override > >> for the missing renderer reordering capabilities ? > > > > No, and I don't see how that would make any sense: if a rendering system > support Buginese script, then it supports it and does the reordering > necessary. It either supports it or it doesn't. > > What I asked is if it is possible to have another feature, that would > be triggered and enabled by default (and should occur before the nukta > feature and other similar features like repha forms) and tagged with > the Buginese script, unless the renderer knows that it supports itself > the reordering of prepending vowels for that Buginese scripts (in > which case that feature would be ignored). > > This is what I would call a smooth transition : existing renderers > would work with a font presenting that feature, and future renderers > that perform the necessary reordering would ignore it and would not > even require that a Buginese script contains this feature. > > >> Note: The Microsoft Font Validator (found in Microsoft Typography > >> website, section for Downloadable Tools) still does not recognize bit > >> 96 of the ulUnicodeRange field, officially defined for the Buginese > >> block range (U+1A00..U+1A1F), and reports an error if this bit is set. > > > > I'll report that to the team that maintains that tool. > > Thanks. > > It should also correctly parse the "head" table instead of reporting > this (non-documented) internal exception in the validation report: > > E0041 : An exception occurred preventing completion of table validation" > System.FormatException: Le format de la chaîne d'entrée est incorrect. > à System.Number.StringToNumber(String str, NumberStyles options, > NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) à > System.Number.ParseDouble(String value, NumberStyles options, > NumberFormatInfo numfmt) à System.Double.Parse(String s, NumberStyles > style, NumberFormatInfo info) à > OTFontFileVal.val_head.Validate(Validator v, OTFontVal fontOwner) à > OTFontFileVal.OTFontVal.Validate() > > >> And the Fonts folder in Windows 7 Explorer does not say that the font > >> effectively supports Buginese (a Buginese font says that it supports no > >> script at all, even if all code points assigned in the Buginese block > are > >> mapped, and bit 96 is set in Unicode Ranges of the header). > > > > Two issues: > > > > 1) Windows 7 does not provide text-display support for Buginese script. > > OK, so Uniscribe (and IE) does not perform the reordering. It's then > impossible to display correctly encoded Buginese text on Windows with > Uniscribe. Other renderers will b
Re: Pupil's question about Burmese
Dear Peter Constable, * Burmese_is_supported in windows.* It makes worse than ever to create another story like pseudo-unicode like Zawgyi in Windows. too. We are in dead-lock because without releasing Myanmar Opentype specifiction for burmese by Microsoft. We can't implement burmese in opentype adopted rendering engine like pango and harfbuzz. We are not satisify just typing burmese text and printing burmese text. We want to have effective use of unicode data in burmese language processing like spelling check, machine translation and OCR. So, Do we need system locale for Burmese? How about CultureInfo for Microsoft .Net Framework. I've encouraged to use Unicode standards among Myanmar Users. Myanmar Users willing to use unicode standards in their works, personal and every application. But there are no advantages in using Unicode Standards and CLDR too. If Unicode.org make standards and do not apply those standards in software and systems, how can we trust those standards. Myanmar Users do not wait on Microsoft, Apple, Oracle implementation. They are going wrong or breakthrough solution. Again. I have to say caution about ethnics language. We should take care about Mon, Shan and Karen Language which is encoded in Unicode 5.1 But Microsoft didn't assign yet for those language in Windows 7 I'm trying to get Burmese Language Pack in Microsoft Windows .since 2002. I gave up and no more try to get it. Microsoft not waiting stable Standards, Politics and/or Technical. I don't not any of reason for delaying our beloved language. Thanks for reading it and support for 40 million speaking language. We did petition to Microsoft at http://petition.myanmarlanguage.org/ http://my.wiktionary.org is the good dictionary site. It is started but not yet finisned. Best Ngwe Tun On Tue, Nov 9, 2010 at 8:52 AM, Peter Constable wrote: > From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On > Behalf Of Andrew Cunningham > > >> Your system locale has to handle the Burmese language. So you need to > >> either install Windows 7 in Burmese or change under Regional / > >> Language options in Control panel, under Adv tab. > > > well considering Burmese is a language that is not supported by Microsoft > ... the above is relatively irrelevant. > > At whatever point Burmese _is_ supported in Windows, system locale will not > be relevant. To be clear, the legacy Windows notion of system locale is > relevant only in relation to apps that support only legacy Windows > encodings, not Unicode. There is no system locale support for languages such > as Hindi or Armenian or Khmer, but that does not prevent display of text in > those scripts in Unicode-capable applications. So, for instance, every copy > of Windows 2000 or later versions is capable of displaying Hindi or Armenian > text, regardless of the system locale setting; every copy of Windows Vista > or later is capable of displaying, in addition, text in scripts such as > Khmer and Ethiopic; and every copy of Windows 7 is, additionally, able to > display text in scripts Tifinagh and Tai Le. In all these cases, the system > locale setting has no bearing. > > > > Peter > > > > >
inquiry about collation testing
Dear List is there any tools or programs or database which can test CLDR collation? Best Ngwe Tun.
Re: OpenType update for Unicode 5.2/6.0?
hope this URL http://ultimategerardm.blogspot.com/2010/10/what-is-in-name-when-it-cant-be-read.htmlhelpful to know pseudo unicode font. On Fri, Oct 15, 2010 at 12:13 PM, Andrew Cunningham wrote: > HI Vinod, > > On 15 October 2010 13:04, Vinod Kumar wrote: > > > > > Unicode compliance does not mean that complex text support must be on > Open > > Font format or its Feature tag based shaping technique. There is no doubt > > that the mobile phone community has accepted Unicode as the standard for > > text representation, and for what the text should look like when > > displayed. How the text should transform to the shapes is not under > > the purview of Unicode. If people find simpler or elegant ways of > > transforming Unicode text to shapes, these are not pseudo-Unicode > solutions. > > > > Actually you misinterpreted what i said. > > pseudo unicode is a term used to describe non-Unicode legacy glyph > based encodings that are superimposed over Unicode blocks. to the > average application it looks like Unicode but isn't Unicode. > > For the Myanmar script examples of pseudo-Unicode would include the > zawgyi and ayar fonts. > > For languages like Burmese pseudo-Unicode content is much more common > than Unicode content. And all mobile solutions I've seen for Burmese > have been non-Unicode. > > > > For example, India had a font standard called INSFOC for Devanagari. A > > shaping engine that will convert Devanagari text in Unicode to INSFOC > glyph > > code sequence would be completely Unicode compliant with respect to > > rendering of Devanagari. Some of my contacts have already extended this > > approach for Gujarati and plan to bring all the nine Indian scripts > too > > under the same Unicode text to font glyph code standard. > > That is what i would term transcoding, and not what i mean by > pseudo-Unicode. > > > -- > Andrew Cunningham > Senior Project Manager, Research and Development > Vicnet > State Library of Victoria > Australia > > andr...@vicnet.net.au > lang.supp...@gmail.com > > > -- ယနေ့မှစ၍ norris...@awwonline.biz ကိုသာဆက်သွယ်ကြပါ။ ngwes...@gmail.com ကို မကြာမှီပိတ်ပါတော့မည်။
Re: OpenType update for Unicode 5.2/6.0?
Dear Peter Constable, Thanks for your attention on our beloved languages. Interesting News. http://phuketwan.com/tourism/phukets-burmese-wave-douses-english-bank-atms-12946/It is proof that Burmese language is not only for Burma. Burmese Language Speakers (more than 60 mil, including minority ethnics) looking forward to use Microsoft Windows with Burmese/Minority Ethnics Language Pack. Have a nice day. Best Ngwe Tun. On Thu, Oct 14, 2010 at 12:38 AM, Peter Constable wrote: > From: Ngwe Tun [mailto:ngwes...@gmail.com] > > > I understood that supporting Unicode should not be exceptional for > Myanmar > > Character Block (U1000-U100F). > > Unicode conformance does not require implementations to support all > characters / blocks / scripts equally. > > That said, I thought we had updated Character Map to cover Unicode 5.1 > additions, but apparently that is not the case. Thanks for bringing this to > my attention. > > > > Peter > -- ယနေ့မှစ၍ norris...@awwonline.biz ကိုသာဆက်သွယ်ကြပါ။ ngwes...@gmail.com ကို မကြာမှီပိတ်ပါတော့မည်။
Re: OpenType update for Unicode 5.2/6.0?
Dear Peter Costable, it might be off-topic, When Microsoft will fix MLang bugs for Myanmar? http://blogs.msdn.com/b/michkap/archive/2008/04/18/8403631.aspx Burmese Font Developer, We are making fonts without Microsoft OpenType font specifiction for Myanmar. Can we have any of specification for OpenType in Unicode 6.0. Again, another disappointing case is Character Map in Windows 7 didn't update yet for Myanmar Changes in Unicode 5.1 Best Ngwe Tun. On Wed, Oct 13, 2010 at 3:39 AM, Peter Constable wrote: > We are in the process of updating the tags to sync with Unicode 6.0. This > has to be coordinated with the ISO Open Font Format standard, so may take a > little time. > > > > > > Peter > > > > *From:* unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] *On > Behalf Of *John H. Jenkins > *Sent:* Monday, October 11, 2010 9:32 AM > *To:* Unicode ML > *Subject:* Re: OpenType update for Unicode 5.2/6.0? > > > > You might start with at > http://www.microsoft.com/typography/otspec/otlist.htm. > > > > On Oct 11, 2010, at 5:11 AM, Saqqara wrote: > > > > Given that OpenType is the de-facto standard for fonts, it is > disappointing to see the 'Script tag' list for OpenType has not been updated > in almost three years. I'm a patient person but the lack of inclusion of new > scripts in Unicode 5.2 a year after the fact seems like carelessness. I've > elaborated a little further on my jtotobsc blog, see > http://jtotobsc.blogspot.com/2010/10/isounicode-scripts-missing-in-opentype.html > . > > > > My particular interest being 𓌃𓂧𓏏𓏯𓀁𓏪𓆎𓅓𓊖 (mdt-kmt, the Egyptian > language in hieroglyphs). > > > > Any ideas who needs to be prodded to make an update happen? It would also > be very useful if HTML5/WOFF could spec Unicode 6.0 or later as a step > towards a multiscript web. > > > > Bob Richmond > > > > > > > > > > > > = > Siôn ap-Rhisiart > John H. Jenkins > jenk...@apple.com > > > > -- ယနေ့မှစ၍ norris...@awwonline.biz ကိုသာဆက်သွယ်ကြပါ။ ngwes...@gmail.com ကို မကြာမှီပိတ်ပါတော့မည်။
