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
_____
