Re: Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
On Sun, 16 Oct 2016 14:25:34 -0400, Mark E. Shoulson wrote: > I have the rare good fortune to see John Cowan on a near-daily basis > (except this month, with all the Jewish Holidays); I'll forward your > message on. Thank you. On Sun, 16 Oct 2016 12:25:27 -0600, Doug Ewell wrote: > Marcel Schneider wrote: > > > I guess that Moby Latin is now being reengineered, see: > > > > http://www.smo.uhi.ac.uk/gaidhlig/sracan/Whacking/MobyLatinKeyboard.html#vietnamese > > That's Caoimhín Ó Donnaíle's mirror of the readme file for Whacking > Latin, the UK version of Moby Latin. I don't see anything about > re-engineering it, but maybe I missed something. Right, it isnʼt talking about re-engineering. “Reconsidered” is not re-engineered. Though I still guess that the author is doing much more now. I remembered this sentence from having read it when youʼd shared Moby Latin here. > > > Obviously the Microsoft program used to generate will be > > KbdUTool, the Microsoft Keyboard Table Generation Tool (Unicode). > > Yes, via MSKLC. Then there would be nothing to be reconsidered. Iʼve in mind using the -s flag to generate the C sources, then setting these read-only once edited. > > > Iʼm so glad that now what many people were waiting for, > > serial dead keys, is going to become a common feature > > on Windows. > > I would be glad to see that too, but where do you see that on the > referenced page? All I see is John's original text about working around > the MSKLC limitation. By experiencing the current use of KbdUTool (via a script in batch that Iʼve written with a comfortable UI for end-users), I feel myself in a position to extrapolate this from John Cowanʼs wording of the disclaimer: «These assignments are considered temporary, and will be reconsidered when the Microsoft program used to generate Moby Latin can handle serial dead keys.» It doesnʼt say what program. Just “the Microsoft program used.” If today, this variable is set to 'KbdUTool' instead of 'MSKLC', then suddenly the Microsoft program “can handle serial dead keys.” > > If you want to work directly with KbdUTool to get serial dead keys, > bypassing MSKLC, here is Kaplan's post from 2011 on how to do this. Be > sure to read all the warnings twice: > > http://archives.miloush.net/michkap/archive/2011/04/16/10154700.html Thank you for this link. This is what I should refer to when citing the feature. There is the test issue, that seems rather awesome. Does a working layout driver prove that there is no known bug? Iʼm actually using sucb a working layout driver. E.g. pressing the Acute dead key twice, then ‘o’, inserts ‘ő’. Iʼd suggest not to do this in the .klc file, too complicated through its apparent simplicity because the diacritic doesnʼt show up on each line. Kind regards, Marcel
Re: Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
Marcel Schneider wrote: I guess that Moby Latin is now being reengineered, see: http://www.smo.uhi.ac.uk/gaidhlig/sracan/Whacking/MobyLatinKeyboard.html#vietnamese That's Caoimhín Ó Donnaíle's mirror of the readme file for Whacking Latin, the UK version of Moby Latin. I don't see anything about re-engineering it, but maybe I missed something. Obviously the Microsoft program used to generate will be KbdUTool, the Microsoft Keyboard Table Generation Tool (Unicode). Yes, via MSKLC. Iʼm so glad that now what many people were waiting for, serial dead keys, is going to become a common feature on Windows. I would be glad to see that too, but where do you see that on the referenced page? All I see is John's original text about working around the MSKLC limitation. If you want to work directly with KbdUTool to get serial dead keys, bypassing MSKLC, here is Kaplan's post from 2011 on how to do this. Be sure to read all the warnings twice: http://archives.miloush.net/michkap/archive/2011/04/16/10154700.html -- Doug Ewell | Thornton, CO, US | ewellic.org
Re: Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
I have the rare good fortune to see John Cowan on a near-daily basis (except this month, with all the Jewish Holidays); I'll forward your message on. ~mark On 10/16/2016 01:08 PM, Marcel Schneider wrote: On 11 Oct 2016 09:48:00 -0700, Doug Ewell wrote: […] You mentioned mobile devices, but also mentioned ISO/IEC 9995 and 14755, which seem to deal primarily with computer keyboards. On Windows, John Cowan's Moby Latin keyboard [1] allows the input of more than 800 non-ASCII characters, including the two mentioned in your post (ɛ and ɔ): AltGr+p, o 0254 LATIN SMALL LETTER OPEN O AltGr+p, e 025B LATIN SMALL LETTER OPEN E Moby Latin is a strict superset of the standard U.S. English keyboard; that is, none of the standard keystrokes were redefined, unlike keyboards such as United States-International which tend to redefine keys for ASCII characters that look like diacritical marks, making adoption difficult. There are also versions of Moby based on the standard U.K. keyboard. [1] http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html U.S. Moby Latin and Whacking Latin keyboard driver packages are not available any more. What happened? Neither can John Cowanʼs home pae be accessed: http://home.ccil.org/%7Ecowan/XML/ Though the Chester County Interlink host is not down. Still the ReadMe can be accessed, from another domain: http://www.smo.uhi.ac.uk/gaidhlig/sracan/Whacking/MobyLatinKeyboard.html
Re: Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
I guess that Moby Latin is now being reengineered, see: http://www.smo.uhi.ac.uk/gaidhlig/sracan/Whacking/MobyLatinKeyboard.html#vietnamese «These assignments are considered temporary, and will be reconsidered when the Microsoft program used to generate Moby Latin can handle serial dead keys.» Obviously the Microsoft program used to generate will be KbdUTool, the Microsoft Keyboard Table Generation Tool (Unicode). Iʼm so glad that now what many people were waiting for, serial dead keys, is going to become a common feature on Windows. All the best, Marcel On Sun, 16 Oct 2016 19:08:59 +0200 (CEST), I wrote: […] > U.S. Moby Latin and Whacking Latin keyboard driver packages > are not available any more. What happened? > Neither can John Cowanʼs home pae be accessed: > http://home.ccil.org/%7Ecowan/XML/ > Though the Chester County Interlink host is not down. > Still the ReadMe can be accessed, from another domain: > http://www.smo.uhi.ac.uk/gaidhlig/sracan/Whacking/MobyLatinKeyboard.html
Re: Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
On 11 Oct 2016 09:48:00 -0700, Doug Ewell wrote: […] > > You mentioned mobile devices, but also mentioned ISO/IEC 9995 and 14755, > which seem to deal primarily with computer keyboards. > > On Windows, John Cowan's Moby Latin keyboard [1] allows the input of > more than 800 non-ASCII characters, including the two mentioned in your > post (ɛ and ɔ): > > AltGr+p, o 0254 LATIN SMALL LETTER OPEN O > AltGr+p, e 025B LATIN SMALL LETTER OPEN E > > Moby Latin is a strict superset of the standard U.S. English keyboard; > that is, none of the standard keystrokes were redefined, unlike > keyboards such as United States-International which tend to redefine > keys for ASCII characters that look like diacritical marks, making > adoption difficult. There are also versions of Moby based on the > standard U.K. keyboard. > > [1] > http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html > U.S. Moby Latin and Whacking Latin keyboard driver packages are not available any more. What happened? Neither can John Cowanʼs home pae be accessed: http://home.ccil.org/%7Ecowan/XML/ Though the Chester County Interlink host is not down. Still the ReadMe can be accessed, from another domain: http://www.smo.uhi.ac.uk/gaidhlig/sracan/Whacking/MobyLatinKeyboard.html
Re: Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
On Tue, 11 Oct 2016 15:52:20 +, Don Osborn wrote: […] > > The problem is input systems, not availability of fonts as it once was. > Keyboard > layouts exist for Ga and other Ghanaian languages, and these enable typing > needed > extended Latin characters. But a number of them, including possibly all for > mobile > devices, work by substituting selected key assignments, which in the case of > multilingual text would apparently mean switching keyboards to accommodate > characters not present in both/all languages used. Not ideal. > […] AIUI, what is drawing people away from getting able to efficiently input Extended Latin alongside with Basic Latin, is the fear of becoming unable to efficiently input digits as soon as these donʼt show up in the Base shift state any longer. Thus IMHO it could be interesting for many more of the worldʼs languages to see that there is a good reason to depart from the typical layout pattern that has the digits in the Base shift state, and to see that this is in practice feasible inside the system input framework, which doesnʼt have so much of the severe limitations that are often pointed. These mainly result from the appearance that the Windows keyboarding framework is given in the MSKLC UI, while the author of this useful software himself invited his users to expand the features by using the included Keyboard Table Generation Tool (Unicode) 3.40. So do I, FWIW. While still being very busy with the French keyboard layouts that Iʼm working on, Iʼm already able to share one more feature for keyboards that have the 102d/105th key, next to left Shift. It is obtained by mapping on this key e.g. the 0x10 modifier, and by allocating this new level to an emulated numerical keypad with hex digits beside Arabic digits, a comma key beside the decimal separator dot key, double and triple zero keys, the zero doubled on VK_0 to complete and to facilitate input of binary numbers, with % and $ and much more, and U+202F on the space bar. In many languages, this is used as a tousands separator, and in all languages before the unit (as in ‘1,234.56 $’). This new “Num” modifier is optional, as is the extra key proper to ISO keyboards. But I strongly recommend to always add the extra toggle Iʼve already mentioned, on key E00 (or instead of Capitals Lock if this is disliked in the target locale). I believe that such keyboards will address the issue. Best regards, Marcel
Re: Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
On Tue, 11 Oct 2016 15:52:20 +, dzo_at_bisharat.net wrote: > Of possible interest - I noted recently the continued use of "3" for "ɛ" in > tweets > & some web content about a pair of Ghanaian plays whose titles include the Ga > language term "Wogbɛ Jɛkɛ." > > See > http:/niamey.blogspot.com/2016/10/wogb-jk-ghanaian-language-input-support.html > > The problem is input systems, not availability of fonts as it once was. > Keyboard > layouts exist for Ga and other Ghanaian languages, and these enable typing > needed > extended Latin characters. But a number of them, including possibly all for > mobile > devices, work by substituting selected key assignments, which in the case of > multilingual text would apparently mean switching keyboards to accommodate > characters not present in both/all languages used. Not ideal. > > What are the possibilities of extended keyboard options on mobile devices for > extended Latin characters to facilitate multilingual text composition? What > is > current thinking / practice wrt expanding virtual keyboards? > > This gets beyond Unicode proper to ISO/IEC 9995 and perhaps ISO/IEC > 14755, so may be beyond the scope of the list. Any responses off-list > I can summarize if of wider interest. One way to deal with increased sets of directly accessed letters is to map the extended letters on the digits row, and to toggle between a languages layout without directly accessed digits, and an ASCII layout, and to do this not via the system facility, but with a hard-coded toggle on key E00. This way Iʼm catering for French, [1] and I project to derive a Malian layout from it, but for Ga one has to start from the US-English layout, except where French has been adopted in Ghana. I see no particular challenges in starting from whatever layout to implement this (including Vietnamese and Lithuanian, where digits are *already* on third level), when the users are interested in a change for enhancement; but in adding an extra row to a cellphone on-screen keyboard I do see several. Kind regards, Marcel [1] http://dispoclavier.com/#i0
Re: Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
On Tue, Oct 11, 2016 at 8:55 AM wrote: > What is current thinking / practice wrt expanding virtual keyboards? > I'm just a user here, and that of the English and Esperanto keyboards on Android, but given swipe input and autocorrect both depending on knowing what language is being entered, it seems unlikely that virtual keyboards are going to evolve towards being better at multilingual input.
Re: Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
Don Osborn wrote: > What are the possibilities of extended keyboard options on mobile > devices for extended Latin characters to facilitate multilingual text > composition? What is current thinking / practice wrt expanding virtual > keyboards? > > This gets beyond Unicode proper to ISO/IEC 9995 and perhaps ISO/IEC > 14755, so may be beyond the scope of the list. Any responses off-list > I can summarize if of wider interest. You mentioned mobile devices, but also mentioned ISO/IEC 9995 and 14755, which seem to deal primarily with computer keyboards. On Windows, John Cowan's Moby Latin keyboard [1] allows the input of more than 800 non-ASCII characters, including the two mentioned in your post (ɛ and ɔ): AltGr+p, o 0254LATIN SMALL LETTER OPEN O AltGr+p, e 025BLATIN SMALL LETTER OPEN E Moby Latin is a strict superset of the standard U.S. English keyboard; that is, none of the standard keystrokes were redefined, unlike keyboards such as United States-International which tend to redefine keys for ASCII characters that look like diacritical marks, making adoption difficult. There are also versions of Moby based on the standard U.K. keyboard. [1] http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html -- Doug Ewell | Thornton, CO, US | ewellic.org
