Typing around the world

How to use Sinhala in Microsoft Word

Another support incident report from Marc and Peirce...  Last week we were assisting a Sinhala user who was having trouble selecting Sinhala fonts in Microsoft Word 2003 on WIndows XP: no matter which font they chose, it would switch back to "KaputaUnicode" as soon as they started typing in Sinhala.  We started by trying to reproduce the issue here, without success.  No matter what we did, it just worked for us.

Eventually we decided to disable most of the Microsoft Office Language Settings in order to get a basic failure.  After removing all languages but English (US) and English (Australia), we were able to reproduce the problem: no matter which Sinhala font we chose, Word would switch back to KaputaUnicode.

Then we tried installing the logical language settings using the MIcrosoft Office Language Settings (MOLS) tool.  We added "Sinhalese (limited support)", Tamil and Hindi, but none of these made any apparent diference.  I stopped and tried to remember which other languages I had previously configured in the MOLS tool when things were working for us.  There were a whole lot of languages from all over the world: which one would make the difference?

I took a somewhat educated guess, and added Hebrew.  Loaded Word and tried my sample Sinhala sentence again.  Success!  It worked!  I could now choose any of the Sinhala Unicode fonts and type with them.  Would you have guessed that?

Using the Font Helper in Keyman Desktop to solve common font problems

Recently I was asked a question about Keyman involving a display issue with the Hebrew holam vowel point (U+05B9). The problem was that the holem vowel was causing too much space to appear between letters. To reproduce the scenario, I used Keyman Desktop's Font Helper and the "Getting Started" text editor on Windows XP.

Keyman Desktop's font helper identifies the fonts on your system which are compatible with the selected Keyman Desktop keyboard. It also identifies how compatible the fonts are with a percentage score.

The font helper is available within both the Getting Started editor and the On Screen Keyboard (click the button). In this situation, it was easier to use the font helper embedded within the Getting Started editor. (To access "Getting Started", select Help from the Keyman menu.)

Back to the story then. First I identified a Hebrew word which used the holam vowel point. The phrase I decided to use was "he will write" ( ). I entered that into the Getting Started editor using the Galaxie Hebrew keyboard. The Getting Started editor identified a number of fonts that appeared to be compatible (trimmed image):

I initially selected the Ezra SIL font (by clicking on the font name in the font helper) and confirmed that the holem displayed correctly:

I then selected the Times New Roman font and immediately saw the behaviour that was described:

The low score of 59% in the Font Helper for Times New Roman tells us that the font only includes just slightly more than half of the Hebrew characters accessible via the Galaxie Hebrew keyboard, whereas the Ezra SIL font (100%) includes all of them.

I was able to advise the original user that Galaxie Hebrew Unicode and Ezra SIL were good, compatible fonts for Biblical Hebrew, while (on Windows XP at least), most of the system fonts did not fully support it.

Now we have to wait and see if that resolves the problem for him!

How we integrated KeymanWeb in Wikipedia

We recently published a KeymanWeb Wikipedia Plugin to allow you to use KeymanWeb anywhere in Wikipedia -- editing pages, searching for information, or participating in discussions.  In this post, I wanted to talk about the process of integration from beginning to end.

The whole process took us about 4 hours.

1. We created a free subscription for KeymanWeb at http://www.tavultesoft.com/account/home/kmw/  We followed the steps in the subscription process, added every keyboard for every language, and added the domain "en.wikipedia.org" as the primary domain for the subscription.  (We later extended the subscription to every Wikipedia domain).
2. Next, we created a new plugin Javascript file at http://en.wikipedia.org/wiki/User:Keymanweb/keymanweb.js which linked to our KeymanWeb subscription and imported the KeymanWeb Javascript components as the page loaded, using the Wikipedia Monobook function addOnloadHook:

   addOnloadHook( function() {
    document.writeln("<"+"scr"+"ipt type='text/javascript' "+
    "src='http://r.keymanweb.com/code/?domain="+
    location.hostname+"&id=243&page="+
    encodeURIComponent(location.pathname)+"'>"+
    <"+"/"+"scr"+"ipt>");
    
    document.getElementById('bodyContent').innerHTML = 
    "<div id='KeymanWebControl'></div>" + 
    document.getElementById('bodyContent').innerHTML;
   } );

3. Also in the same Javascript file, we inserted an element at the top of the bodyContent as a container for the KeymanWeb toolbar:

   importStylesheetURI(
    'http://en.wikipedia.org/w/index.php?title='+
    'User:Keymanweb/keymanweb.css&action=raw&'+
    'ctype=text/css' );
   

4. At this point, we had KeymanWeb working within Wikipedia, and could select a keyboard and type with it in any edit box in Wikipedia.
5. However, we decided that the normal KeymanWeb toolbar was too intrusive for Wikipedia, and replaced it with a new, smaller toolbar.  This took the most time, including drawing, scaling and modifying the CSS rules for displaying the toolbar.  We recorded our CSS changes in http://en.wikipedia.org/wiki/User:Keymanweb/keymanweb.css.  Firebug in Firefox was an invaluable tool for tweaking the CSS to get it just right.
6. Finally, we took some time to write up the instructions for integrating KeymanWeb into your own user profile in Wikipedia.

As you can see, the actual integration process was dead easy.  Most of the time we spent was taken on polishing the look and feel of KeymanWeb for a better fit into Wikipedia.  We were surprised ourselves by how straightforward it was to get the basic integration right.

Try it yourself at http://en.wikipedia.org/wiki/User:Keymanweb!

Tibetan EWTS keyboard and Sanskrit stacks (or why clear documentation is essential)

I was assisting a Tibetan user with an issue typing Sanskrit stacks today.  We were both reading the documentation for the keyboard and both running into the same problem -- we just could not get the stacks to form.  We were both running in Vista so I knew that the problem was not rendering.

We both tried to type pad<space><space>+ma<space>, which according to the documentation, as we read it, should give us པདྨ but was instead giving us པད+མ་.

So I did a little research.  I took the source file for the keyboard and searched for a couple of the stacked characters -- in this case, I searched for the Unicode character Tibetan subjoined ma (U+0FA8).  As soon as I found it in the source, I understood the problem.  The source line read:

"+m" + " " > U+0FA8

We needed to type just +m, not +ma.

Now when I go back to the documentation and read it again, it seems obvious enough.  But it clearly isn't, because three different people have read the same instructions and made the same mistake.

Now I have a new item on my list: clarify the stacking instructions in the Tibetan EWTS keyboard!

Specifying default options for Keyman Engine at install time

Note: this blog is intended for Keyman Developer Branding Pack Users.  It is not applicable for Keyman Desktop or KeymanWeb.

The default settings for Keyman Engine may not be what you want for your product.  It is possible to change the default options by adding the values to the .wxs intermediate file created by the Product Editor.  The .wxs file will then be used to compile the product installer.

1. View the knowledge base article at Tavultesoft KB article KMKB0060 and decide which settings you want to implement
2. Open the Product Editor for myproduct.kpp and click “Export to WiX” in the Compile tab.  Export the files to c:\myproduct (or replace this with your own path)
3. Load the myproduct.wxs file generated in the C:\myproduct\build folder in an XML editor.  An XML editor is recommended because otherwise it is hard to read, but can use any Unicode-compliant text editor if you prefer.
4. In the section <Component Id="component_CurrentUser", add Registry values as per the following example for "auto open osk" (available types are 'integer' or 'string'):
   <Registry Root="HKCU" Key="Software\Tavultesoft\Keyman Engine\7.0" Type="integer" Name="auto open osk" Value="0" />
6. Create a batch file with the following commands, tweaked as per your product name and choice of folders, and then run it:
   cd \myproduct\build
   "\program files\Tavultesoft\Keyman Developer 7.0\WiX\candle.exe" myproduct.wxs
   cd \myproduct
   "\program files\Tavultesoft\Keyman Developer 7.0\WiX\light.exe" -out myproduct.msi build\myproduct.wixobj "\Program Files\Tavultesoft\Keyman Developer 7.0\WiX\wixui.wixlib" -loc "\program files\Tavultesoft\ Keyman Developer 7.0\WiX\WixUI_en-us.wxl" -b "\Program Files\Tavultesoft\Keyman Developer 7.0\Redist\Desktop"

   EDIT 11/11/09: Fixed incorrect directory for light.exe command -- thanks Amaryllis for pointing this out.

7. This will generate a myproduct.msi file with the options preset as you desire.

If you want to make a new version of the installer, I recommend that you start from Step 2 again as Keyman Developer will manage the upgrade of the .wxs file, which needs a number of changes to make it work correctly for an upgrade.  So make sure you save a copy of the <Registry> XML tags that you add, so you can paste them into the updated .wxs file in this situation.

We plan to add a RegistryKeys section to the .kpp file in a future update of Keyman Developer to reduce the complexity of this process.

Creating a custom On Screen Keyboard for Keyman Desktop

A discussion with a customer a few days ago led into this blog post - how to create your own On Screen Keyboard for Keyman Desktop that does not need to follow the standard 101-key keyboard shape. Your custom on-screen keyboard will be a HTML file that includes a couple of interoperability tweaks to integrate cleanly into the Keyman Desktop On Screen Keyboard UI.  Once you have created your Keyman Desktop keyboard and package (see the tutorials for info on how to do this!), you will need to create a new HTML file called "usage.htm". The basic idea is simple: clicking on an element in the HTML page will fire an event back to Keyman telling it to insert a specific character into the active document.  For example, the following snippet will insert the ṡ character when clicked:<a href='keyman:insertchars?chars=U+1E61'>Insert ṡ</a> Note the different elements of the URL:

• keyman:insertchars tells Keyman to insert characters
• chars=U+1E61 tells Keyman which Unicode characters to insert

This is really all you need to know to start creating your own customised On Screen Keyboard.  Keyman will manage the focus, context and interactions with the target application. For a complete example, we'll look at the European Latin keyboard.  Feel free to use it as a starting point for your keyboard.  Note that the usage.htm is targeted at Internet Explorer, as we know that it will be used only by the embedded Internet Explorer web browser in the On Screen Keyboard.  This means that cross-browser compatibility has not been added to the file, for simplicity.

The European Latin usage.htm has the following components:

• An embedded stylesheet
• Javascript to generate the grid of characters (simpler to maintain than storing it as HTML) - the "gen" function
• Javascript to handle resizing the grid of characters to the window size, automatically - the doResize function
• A small amount of Javascript to handle customised tooltips for the character grid - the mouseOverBox function
• And a couple of utility functions

The body of the document is straightforward - just call the gen() function to complete.

Download Usage.

Internet Explorer embedded fonts vulnerability and patch

Microsoft have just announced a set of vulnerabilities with their Embedded OpenType Font component.  This component is used in Internet Explorer to automatically download and display fonts on websites.  it is especially useful for displaying text in languages not supported by your operating system.

Tavultesoft use the Embedded OpenType Font component in a number of our websites.  For example, we use it on http://ethiopic.keymankeyboards.com/ to instantly allow display and editing of Amharic, Tigrigna and other Ethiopic languages.

FireFox 3.5, Safari, and Chrome should not be affected by this vulnerability, and you should be able to utilise embedded fonts in these browsers safely.

Make sure you use Windows Update as soon as possible to update your computer to avoid being affected by this vulnerability!

Finally embeddable fonts work in all major browsers*

With the release of Firefox 3.5, all* the major browsers now support embeddable fonts - in one of two formats, TrueType/OpenType and EOT.  This makes for a much smoother experience for visitors to multilingual websites.

For an example, visit http://ethiopic.keymankeyboards.com/ on a machine without any Amharic/Ethiopic fonts installed, with IE6, IE7, Firefox 3.5, Safari 4 or Chrome.  Click in the KeymanWeb demo box and type some keys - it doesn't matter much what you type.  You may see boxes or replacement characters for a second or two if you have a slow connection, but then the text will show in Ethiopic script.

It's been a long wait.  But I'm happy that it has finally happened.

* Except for Opera.  But embeddable fonts will be supported in Opera 10 which is in beta.

Keyman 7.1.267.0

We've just released another update to Keyman Desktop and Keyman Developer.  In this version:

• We add a fix for a minor Windows 7 compatibility issue.
• We fix a couple of reported crashes, and an install issue on Vista that was rarely experienced.
• We address some bugs in the On Screen Keyboard export and print functions (Did you know you could right-click on the On Screen Keyboard and print it in Keyman Desktop Pro?)
• We finally fix the proxy issue which has been making life difficult for those behind a proxy server!
• And finally, we have improved the User Interface Language dialog box by making new translations more easily accessible with the More Updates Online button.

The Keyman Developer update includes some fixes for the KeymanWeb Compiler.

Full details are available in the Keyman Version History.

You can get the full download from http://www.tavultesoft.com/70/download.php.  Patch updates will be available soon.   

KeymanWeb Updates

We have published an update to KeymanWeb, v 1.0 build 136.  This release makes the following updates:

• The Alt key is now released in the On Screen Keyboard correctly.  This problem was especially evident previously when switching windows with Alt+Tab.
• Firefox now scrolls input and textarea controls correctly when typing with KeymanWeb.
• The On Screen Keyboard has some minor formatting changes:
  • The title "Tavultesoft KeymanWeb" is no longer a link - this had the potential for confusion and made it difficult to drag the On Screen Keyboard around.
  • The name of the active keyboard is now shown in the title bar.
  • The border colours are now more consistent.
  • The position of letters on the key caps has been tweaked.
  • The font size is no longer impacted by page-level font sizes.
• KeymanWeb_Root variable is now ignored if a full path to a keyboard file is registered.
• KeymanWeb_AttachType is now checked before attaching to dynamically created controls.
• KeymanWeb now attaches correctly to dynamically created controls in Safari, Chrome and Firefox.

The update has been automatically deployed for KeymanWeb subscribers.

Some additional fixes have been made to the KeymanWeb compiler, which will be available as part of Keyman Developer build 7.1.266.0 and later versions shortly.