On Keyboard Layouts
At the ATypI conference 2011 in Reykjavík, I gave a talk entitled “Pitfalls of Pi fonts.” This presentation was the culmination of a project that involved the creation of keyboard layouts for all of our dingbat fonts. The ultimate purpose of this project was the desire to replace obsolete Type 1 (T1) fonts with more current OpenType fonts (OTFs), which was necessary for various reasons, the most important of which being that T1 fonts lack proper Unicode information. On another hand, this shortcoming in the T1 font format was also its greatest advantage: virtually all the glyphs were easily accessible from the keyboard.
The goal was updating the fonts to reflect the major Unicode 6 update, but without losing the capability of typing symbols with a keyboard. This is why keyboard layouts were created for each of these fonts; when activated, they exactly replicate the former T1 behavior.
In the process, I learned a lot about creating keyboard layouts on Mac and Windows, and used lots of different ways of creating the best workflow. In the end, a scripted solution was created, which would largely automate the work necessary. The process involves creating an XML-based Mac OS X layout first, then converting the resulting XML into a Windows-compatible file.
While the first part is largely tied in with our font production system, and consequently not really useful for anybody else, the second step is quite universal, and can be applied to many XML-based Mac OS X keyboard layouts.
For getting started with creating keyboard layouts, please download my ATypI presentation. It includes my observations on keyboard layout creation, and some useful links and resources. The annotated PDF includes all the slides I showed, plus the complete contents of my talk.
Update February 25, 2013:
Keyboard layout conversion script and documentation are now available on GitHub.
6 Responses
Comments are closed.
Mr. Grießhammer
People at FontLab directed me to your presentations.
I have read your “Pitfalls of Pi Fonts” and “On Keyboard Layouts”. I think you are the answer to my prayers. I am only a typographer and not a programmer.
I have designed glyphs for the Canadian Aboriginal Syllabics (Unicode 1400s), and am making fonts available to children in schools. We need a simple solution for using the font on Windows. Their equipment can be old as there is lack of funds.
As most of these aboriginal languages can be written within 190 glyphs, it is easy to make a font for Macintosh. The ideal solution for Windows would be to attach a python string to the font, so that when the Alt-a key is pushed on Windows the font will return the same glyph as the option-a glyph on Macintosh.
Do I understand that you have solved this problem? You say, “this script will be publicly available, in one of the next iterations of the Adobe FDK”.
I do not wish to use Unicode for this purpose, as there are many aboriginal languages with different sets of required glyphs and keyboard layouts. I basically piggyback on the American English keyboard. I used to have Windows fonts that worked with a macro program for substitution called “Quickeys”. But that is too expensive and cumbersome for my users.
Could you please help me and direct me where to go?
Eiko Emori
My work on keyboard layouts covered exactly what you describe – making equivalent keyboards for Mac and Windows operating systems.
Above, you can download a script to convert a keyboard layout from Mac to Windows format.
My workflow is described in the presentation – I used a software called ‘Ukelele’ on the Mac to create the original keyboard layout file; then I used my script to convert the layout to Windows KLC format.
This file can be opened in ‘Microsoft Keyboard Layout Creator’ and be compiled to an installable file.
All of those applications are freely available, here are the links (from the presentation PDF):
Ukelele: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=ukelele
MSKLC: http://msdn.microsoft.com/en-us/goglobal/bb964665.aspx
For the purpose, you’ll have to use Unicode values, as there is no other way for a keyboard layout to access a glyph.
In your case, as the glyphs are not (yet) in Unicode itself, it would be helpful to use PUA values (I also touched on that in the presentation):
PUA values are in the range of U+E000–U+F8FF
http://en.wikipedia.org/wiki/Private_Use_(Unicode)
Using the US keyboard as a host is a common (but unfortunately a not really useful) practice, as you exclude any user not having the US keyboard available.
Mr. Grießhammer,
Congratulations on your approach: it is very clean. However….
I have tested your script, using “x.keylayout” (Apple Wireless Swiss German keyboard).
I have obtained file “x.klc”.
Tried to open it with MSKLC.exe under:
(MAC OS X 10.8.2/Parallels v8/WINDOWS 7 Pro SP1) and received the following message:
“There has been a problem loading that keyboard”.
On this setup MSKLC.exe 1.4 works perfectly with other keyboard files (Parallels, Logitech and Windows).
Can you provide any help?
Thank you for your kind attention,
Rodrigo CABALLERO
(MBPro)
Hello Mr. Caballero,
Thank your for your comments, I appreciate the feedback.
Unfortunately, the .klc format is not publicly documented, so the keyboard conversion script relies on my own reverse-engineering of the format.
Also, as you experienced, MSKLC is not very explicit with reporting errors, which makes things even more difficult.
The different keyboard layout strategies (Mac vs. Win) are not fully compatible, consequently, this script can only be a helper for making the step in the right direction.
I would suggest analyzing the created .klc file in a common text editor, and possibly compare it to other, known-good .klc files. Maybe something obvious comes to your attention.
Without having any of those files available, further analysis on my side is not possible.
Best greetings,
Frank Grießhammer
WOW! Thanks for the quick answer!
Yes I understand the difficulties involved due to lack of information…
I am going to send both files to you; If you have time to take a look at them it would be a great progress.
Thank you for your attention.
Rodrigo CABALLERO
Problem solved. I created a .klc from your source data using the Python script; and I am not able to reproduce the error.
Please check your email for the output file created.