Streamline keyboard programming (was: Re: Thai Word Breaking)

Marcel Schneider charupdate at orange.fr
Sat Aug 29 15:45:50 CDT 2015


On 27 Aug 2015 at 23:09, I wrote:

> Keyboard source files can be converted and compiled with the Kbdutool.exe of MSKLC even when they have not entirely been generated by the software. In other words, we are invited to add chained dead keys directly in the .klc file, because they are supported by Kbdutool, and run this tool thanks to its command line UI. Among the switches, we find also one to get the C sources only.

> I would have e-mailed this the day the whole process is working (to date, I can just include my custom header, via an #include at the end of the kbd.h in the \inc\ directory), as there is no such switch to get Kbdtool.exe compile from the C sources.

> IMHO what we must not do, is to insist to have graphic UIs for the whole keyboard layout creation, because experience shows that keyboard editing, especially dead key repertories, as well as the allocation table and ligature table, are best done in spreadsheets (where we can also have the diagrams), with the whole NamesList (or the part containing identifiers and heads/subheads), and the surrogate pairs beside in two formula-generated columns (using little hex conversion tables because Excel can AFAIK not handle the >> and << operators (this is >>, << in the case it disappears).

Philippe Verdy kindly made me aware that the binary right shift is an integer division. Yep, I didn't notice, and clumsily removed two hex digits and figured out how to get the next one... Thanks to Philippe's advice, the C formulas from the Unicode Frequently Asked Question stand now as short Excel formulas in my NamesList spreadsheet.

Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20150829/fd228434/attachment.html>


More information about the Unicode mailing list