On 18 Aug 2015 at 06:56, David Starner wrote: > There are many languages, particularly Native American languages, given > written form in the typewriter era that use letters with under-bar as part of > their alphabet. And the underbar is no different from the cedilla, the acute > and grave accents, the umlaut or many other modifiers used to make new > characters in languages across the globe. There are single code-point > versions of characters like ä, but that's historical coincidence, and they > are equivalent to the two code-point versions. Arguing atomicity is missing > the point; A̲ is as atomic as Ä in Unicode's eyes.
IMHO the problem was aroused from GNU APL being implementing Unicode but still hesitating (and seemingly even about to abandon). I just pick one e-mail out of the archives (following Alex Weiner's invitation) http://lists.gnu.org/archive/html/bug-apl/2015-08/msg00047.html and have no time to browse them all but as I must implement APL on the keyboard along with universal Latin, I'm interested in decrypting how GNU APL view characters. IMO the way Unicode worked out to feasibly encode all characters on the world, with decomposition sequences and taking over precomposed characters only for backward compatibility's sake, opposes to GNU APL sticking with the inherited model. This antagonism may be exacerbated by GNU being a part of the Free Software Movement, as opposed to the business model of the companies Unicode is a consortium of. This may partly explain the tone of one part of this thread (except for my own comment). So it could really be a good idea to make GNU APL at ease with Unicode. If underbar letters are for the sole use of GNU APL, their implementation and font support will be catered for by this organization, and it would be enough to discourage their use outside of APL to meet the security issues. However, Ken Whistler explained clearly [http://www.unicode.org/mail-arch/unicode-ml/y2015-m08/0122.html] that today, APL would take advantage from updating towards the up-to-date character model. To facilitate this by making it plausible, I suggest to consider that free software and proprietary software, rather than antagonistic, should be considered as complementary. I hope this (as are other people's contributions on this thread) to be a constructive view helping to clear the differends, given that particular requests cannot be dealt with entirely as long as the underlying philosophy isn't satisfactorily taken into account. Marcel
