Accumulated Feedback on PRI #281

This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.

Date/Time: Thu Oct 23 13:28:01 CDT 2014
Contact: adrian_cheuk@sil.org
Name: Adrian Cheuk
Report Type: Public Review Issue
Opt Subject: PRI #281: Proposed encoding model change for New Tai Lue

Having been in contact with the New Tai Lue user community for 8 years, we can
confirm that the local situation described in the background document is true:
they have not been using 'true' Unicode solution in data processing.  Local
users have always been typing & storing characters visually, i.e., the 4
reordering vowels are typed & stored before the initial consonant.  Each
character has the same weight, be it consonant, vowel, or tone, & is processed
as a full character (i.e., not a combining mark).  In the past, legacy
encodings in visual order were used.  When we visited the language area in
2011, we discovered the local newspaper co. had already switched to a pseudo-
Unicode solution that encoded characters using Unicode code points but stored
data in visual order.  Their website www.dw12.com has since been actively
disseminating daily news in this way to this day.  Subsequently we did
extensive testing on platforms & data processing software available to us in
the hope of finding a 'true' Unicode solution for the user community.
However, none of the applications tested was able to support NTL in a workable
manner.  E.g., Windows XP had no NTL support; Windows 7 only had the font but
no IME, & Word 2010 on Win7 turned a run of text into overlapping characters
during editing; OpenOffice 3.2/LibreOffice 3.3 forbade cursor placement before
a vowel or tone, & an initial cannot be deleted w/o deleting also the vowel &
the tone in the syllable.  The requirement to encode reordering characters
logically had created so complicated a technical problem that 7 years after
acceptance into Unicode there was still no functional application support for
the script.  So in 2012 we contacted Peter Constable requesting an encoding
model change to visual order, explaining also Word 2010/Win7's broken NTL
support.  After further investigating the anomaly in OOo/LibO, we contacted
Martin Hosken in 2013 suggesting the proposed character property change as
well as a change to visual encoding order.  We are glad that Martin has
prepared the background document & that UTC has published this PRI.  Given the
substantial amount of data already encoded in Unicode code points but stored
in visual order, the proposed changes will definitely be welcomed by the user
community.  They will not need to change anything but can continue to enjoy
the simple encoding model which they have long been using.  As for existing
Unicode-compliant data & implementations, we are only aware of the Dai Banna
SIL font package, which contains 2 Unicode font families & a 2-paragraph
sample text in Unicode.  SIL is willing to revise the package per the proposed
changes.  We would therefore recommend UTC to adopt the proposed changes as
early as possible.