On 07 Aug 2015, at 18:38, Doug Ewell wrote: > Michael Kaplan, author of MSKLC, reports that not only is the limit on > UTF-16 code points in a Windows keyboard ligature still 4, it is likely > to remain 4 for the foreseeable future: > > http://www.siao2.com/2015/08/07/8770668856267196989.aspx > > "People who want input methods capable of handling more than four UTF-16 > code points really need to look into IMEs (Input Method Editors) which > are all now run through TSF (the Text Services Framework), a completely > different system of input that allows such things, admittedly at the > price of a lot of complexity." > > This should settle the matter.
I wouldnʼt have made a «battle» of that. Please, note that Iʼm quoting somebody else; these quotes cannot be mistaken for scare quotes (which BTW would probably have been more appropriate, and thus more expected). And I wouldnʼt have answered any more. I just donʼt want to let the Mailing List believe that I agreed being classified as «fighting the [bad] fight», if not even as a “bad boy” (that isnʼt quoted from here). So unfortunately I canʼt help replying again. For all «documentation», this a bit vulgar blog post that is being shared, cites internal references (other blog posts from the same author on the same web site). The header file it refers to, remains unquoted and unlinked. Thus, this blog post is biased with the authority bias. Iʼm not quite sure whether people are conscious that by contesting the accuracy of the original actual Windows keyboard driver header file (kbd.h), they are insulting the developer(s) who wrote it, as well as the company that stands behind him/them. For not wanting to make anybody loose face, I didnʼt mention that a copy of the cited and quoted header file is included in the MSKLC. The version 1.4 of which dates from Thu, Jan 25, 2007, 23:14:22, whereas the included kbd.h shows «10-Jan-1991 GregoryW» in the file history. Therefore, my supposition (I hadnʼt looked up that!) that «when the MSKLC was built, Windows did not support more than four characters per ligature. (Thatʼs the only straightforward explanation of this point of the MSKLC.)» turns out to be completely wrong (except the parenthesized disclaimer). I could become more explicit, but I just stand away in order not to heat up the discussion with ad personam conclusions. At this unexpected point of the thread, Iʼm extremely sickened. At the same time, the shared blog post helps me to understand a bit better some asperities of the overall (most of the time) rather sympathetic MSKLC. I often wondered why the description page [https://msdn.microsoft.com/fr-fr/goglobal/bb964665.aspx] and even less the download page [https://www.microsoft.com/en-us/download/details.aspx?id=22339] have not been updated (no mention of Windows 8 on the former, no mention even of Windows 7 in the system requirements on the download page), and why thereʼs no 2.0 version of the MSKLC. Most times I answered to myself that the little interest on usersʼ side discouraged Microsoft from investing in such an update.—Thatʼs now to be revised. Iʼd never imagined that a limitation in the MSKLC (not the only, but the most striking one) could be justified and defended the way it is. IMO it would have been wise to limit this thread to “Ligature length on Windows”. Now that it extended to all “Windows keyboard limitations”, letʼs extend a bit more to prevent further disruptions. Iʼm not here to criticize Microsoft. I ask everybody to be honest and to answer for himself one single question: How on earth can I prefer Bing if I were battling against Microsoft? Does anybody really believe that Iʼm annoying myself to find more bugs? So please remember that by the time, the Redmond company got the unlucky reputation of not listening to its users. Iʼve got the strong hope that this tendency has been reversed, but I still believe that as soon as Unicode implementation is concerned, the Unicode Mailing List is one of the best places to send the topic. I still believe it today, as this thread has taught me a lot. Hopeful that this will end in a constructive way, Marcel Schneider
