It sounds to me like a fault in the keyboard software, which could be fixed by the people who own and maintain that software.
> On 17 May 2018, at 01:20, Richard Wordingham via Unicode > <[email protected]> wrote: > > On Thu, 17 May 2018 00:34:35 +0100 > Michael Everson via Unicode <[email protected]> wrote: > >> This is not a fault of the encoding. >> >>> On 16 May 2018, at 23:01, Richard Wordingham via Unicode >>> <[email protected]> wrote: >>> >>> I think simple Windows keyboards have a limit of 4 16-bit code >>> units; for an Indic SMP script, one couldn't map <x> to a single >>> key, as it would require 6 code units. > > It is a consequence of the policy of avoiding precomposed characters. > If there were a precomposed character for <x>, the keyboard could emit > that character - job done. > > One objection is that one would need a sequence of decompositions: > > <XA> = <KA_PLUS, SSA> > <KA_PLUS> = <KA, VIRAMA> > > Some people are vehemently opposed to unnatural characters like > <KA_PLUS>. > > Presumable the official view is that Windows Text Services have taken us > beyond that point, and the likes of <XA> above are not needed. > > If X persists, perhaps named sequences should be assigned numbers so > that X can make a generic allocation of keysym codes to named > sequences. > > Richard.
