Dear Myanmar GP members, Please find below the review of the Myanmar LGR proposal by the integration panel. Kindly let us know if you have any queries. We look forward to the final version, incorporating the feedback. Regards, Sarmad _____ From: Integration Panel To: Myanmar GP The IP has reviewed the Myanmar LGR proposal draft v2 "with Grapheme corrections". Generally the IP reviewers note two facts that stand out with regards to the proposal. One is the complexity of the combined writing systems and the other is the overall good quality of proposal. However, significant work remains to be done. This feedback by the IP is focused on issues needing the most urgent attention, leaving some details for later review. The IP's working position is that the rules probably don't have to be as complex. Most of them are simple depth (1) left-hand-contexts. The good news is that the GP has researched the language-specific rules for each language in depth and expressed them in a form that's generally trivial to translate to XML, if the LGR was on a per-language basis. (The few exceptions are noted, but ought to be relatively easy to fix). While preserving the detail information regarding individual languages (which is really valuable), the IP would like the GP to investigating "merging" the rules again, so that they become once more "generic" to the *script*. Perhaps it is possible to take one of the languages as a "template" and change the character categories back to generic ones ("Consonant" instead of "mm_con", "mon_con", "poa_con" etc.). Then, in a second pass, the GP could identify combinations allowed by these generic rules that violate some language's rules in such a way that it leads to rendering problems. If such a conflict exists, the IP would encourage the GP to investigate those cases to see whether some tightening of the restrictions (disallowing code point contexts between some code points that are each language specific, but for different languages, for example) makes any sense (or is logically possible). Generally, a slight over or underproduction by the rules compared to the native orthography of a given language may be acceptable -- as long as the ability to form labels is not severely compromised or labels can be formed that present security risks. If generic rules are possible, we have what one might call option (1) in my comments: rules that are specific but expressed on a code-point basis (not based on language context). If not possible, we have option (2) like in Thai, where the IP and GP had to admit defeat and the LGR could not support some features of minority orthography due to rendering system limitations. Because the quality of the rest of the proposal is so high, the IP is confident that the GP would be able to present matters in a way that allows the IP to understand to what extent "generic" rules are possible and to what extent they "violate" assumptions by native readers and or rendering engines. At this point, it may be premature to create an XML file -- the "pseudo LGR" notation at the end of Section 7 is a good and clear statement of the GPs intent and way easier to edit than XML with all its syntactic baggage. Because the rules are so in flux, the IP would be happy to accept a third draft on the current basis (if the GP include the "pseudo LGR" format, along the lines of what they called "alternate" and make the other changes we request). In the attached document, there are three lengthy "Notes from IP reviewers" in the marked-up text. These remarks were felt to be too extensive to put them into the sidebar comments (where, depending on the system, they may be hard to view) but also that they were better placed in context in the document rather than presented here. These remarks address the issue of what is and isn't possible when designing WLE and context rules; with the explanation geared towards specific issues with the Draft 2 document in this regard. The IP is looking forward to an updated draft that returns to a more streamlined and script-specific set of context rules. PS: it would be nice to have future LGR drafts carry a date in the file name in the format YYYYMMDD _____