In addition to creating platform-specific keyboard layouts as Doug suggested, I would also like to point out that it is now also possible —and possibly even easier— to create web-based keyboard and input method engines that may allow a greater degree of cross-platform support, reducing platform-specific work.
Also with web applications the "software installation" issue is eliminated. Remember that while it is easy for technologically savvy folks like members of this mailing list to install keyboard drivers on any platform we like, this process is somewhat beyond the reach of many people I know, even when they are otherwise fairly comfortable using computers. As an example, see http://unifont.org/keycurry/, a Javascript/jQuery-based web app that I wrote and use for myself all of the time. One limitation of keycurry is that currently almost all of the keyboard maps assume an American QWERTY layout. But honestly it would not be very difficult to generate variant maps for AZERTY or whatever else one wants. I just have not bothered myself to do that extra work because I bought my laptop in the U.S. and the default QWERTY layout works fine for me, especially now that I can write new keyboard maps for most scripts and languages in a matter of a few minutes (unifont.org/keycurry now uses JSON-based keyboard maps with UTF-8, in addition to an older format based on Yudit; obviously IMEs for scripts like Korean or Chinese take a lot longer to write, but simple keymaps for Latin and many other scripts are super easy to make). In fact, with web-based solutions, users don't even have to download or install the fonts, as obviously we can just use web fonts to supply Unicode-based fonts to the web app. (In fact this is exactly what I do for the Tai Tham keyboards in keycurry, inter alia). Best - Ed On Mon, May 2, 2016 at 3:34 AM, Martin J. Dürst <[email protected]> wrote: > Hello Don, > > I agree with Doug that creating a good keyboard layout is a good thing to > do. Among the people on this list, you probably have the best contacts, and > can help create some test layouts and see how people react. > > Also, creating fonts that have the necessary coverage but are encoded in > Unicode may help, depending on how well the necessary characters are > supported out of the box in the OS version in use on the ground (which may > be quite old). > > Also, a conversion program will help. It shouldn't be too difficult, > because as far as I understand, it's essentially just a few characters than > need conversion, and it's 1 byte to multibyte. Even in a low level language > such as C, that's just a few lines, and any of the students in my > programming course could write that (they just wrote something similar as > an exercise last week). > > On 2016/05/01 02:27, Don Osborn wrote: > >> Last October I posted about persistence of old modified/hacked 8-bit >> fonts, with an example from Mali. This is a quick follow up, with >> belated thanks to those who responded to that post on and off list, and >> a set of examples from China and Nigeria. I conclude below with some >> thoughts about what this says about dissemination of information about >> Unicode. >> > > I'm not familiar with the actual situation on the ground, which may vary > in each place, but in general, what will convince people is not theoretical > information, but practical tools and examples about what works better with > Unicode (e.g.: if you do it this way, it will show correctly in the Web > browser on your new smart phone, or if you do it this way, even your > relative in Europe can read it without installing a special font,...). > > Even in the developed world, where most people these days are using > Unicode, most don't know what it is, and that's just fine, because it just > works. > > Regards, Martin. >
