Non-standard 8-bit fonts still in use

[Ed Trager]

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 <duerst at it.aoyama.ac.jp>
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20160502/a9f2234f/attachment.html>