This article still gets accessed a lot even after over 5 10 years since publishing it. Technology, however, continuously advances, so please be aware that the information below may be outdated.

One of my ongoing language-construction related pet projects is to bring my constructed language’s writing system to the computer. I have been trying to come up with workable solutions to do this for a number of years, but always hit brick walls sooner or later.

Actually, since you’re reading this, I presume that you have a foot in language creation as well as I do, and since many of us folk seem to like not only fiddling with sounds and meaning, but with computers, too, you may even have created a TTF font for your own language and its ‘native’ script. If it’s an alphabet or a simple syllabary like Japanese Katakana, for example, you will probably not have had that many problems and your greatest worry may be how to type this on a regular computer keyboard. Congratulations!

However, in my case it is unfortunately not quite as simple, since I have an abugida to work with. That is, vowels and other modifiers are indicated by a bunch of accent marks that are placed around consonants, while the vowel that occurs most frequently (usually one of [a ə ɔ], depending on the language) is typically not written out.

If you’re familiar with Semitic languages, it’s similar to that, except all vowels are written out mandatorily. If you’re familiar with writing systems of the Indian subcontinent and South-East Asia, it’s that, basically. And if you’re familiar with Tolkien’s Tengwar writing system (yes, “Elvish”), it’s similar to that, too. Now let’s look at possible solutions I’ve come up with and what problems I’ve run into, which is why I’m frankly very tired of even trying. Yet, the ambitious part of me demands to not simply give up.

1. Precomposing All Combinations

This may be the most simple solution. Just do it the way Chinese characters or Korean syllabograms are encoded in Unicode: Precomposed, coming not only in dozens, but dozens of grosses.

Korean, as you may know, is basically an alphabet, except that syllables are grouped into blocks:

The problem with this is that it’s very tedious to do this for Ayeri’s script, since there are 27 consonant letters, 8 vowel diacritics for the top, 8 vowel diacritics for the bottom, 8 functional diacritics that appear underneath consonants, 7 that appear before them as variants, and 4 that appear above them, partly as variants. Not all combinations are possible, but a rough estimate is that you would arrive at a whopping 69,000,000 approximately 450,000 combinations if my knowledge of combinatorics hasn’t failed me.[1. 27 consonants × 8 top vowels × 8 bottom vowels × 8! 2⁸ functional diacritics = 442,368. The factorial of 8 because all of those can be combined (while changing shape contextually, which is why we can safely ignore the prepended and top diacritics) with each other, but not appear twice per character, so with every step you lose one possible combination.

] And even if that were wrong, it’d still be an insanely large number anyway if you really wanted to precompose all possible combinations. And then you’d have to write some kind of library that picks the correct character for the syllable you need, preferrably by entering the word in the Latin alphabet for comfort. Big effin’ deal. I haven’t actually tried this because it seemed insane right up front.

2. Backspacing Characters

An idea that I thought to be really clever is to position diacritics around consonants by defining blank characters in the font, the width of which would be negative. That is, all characters in a font have a width, just like any kind of image file. However, these characters – possessing negative width – would not move the cursor forward, but backward as you type them, while still keeping the left-to-right direction of writing intact, thus overlaying the consonant character with the following diacritic. This was actually semi-successful, as indeed some versions of OpenOffice.org 2, as well as some versions of Firefox let themselves be tricked. Tricked, because it’s not actually what you’re supposed to do as it turned out, so most programs I tried this with as well as later versions of OpenOffice.org and Firefox just ignored the minus signs and took the absolute width of spacing characters, resulting in a grossly spaced-out mess. So this wouldn’t be a way to handle things in the long run either.

3. Graphite by SIL

Graphite is a type rendering engine developed by SIL International, who are a Christian missionary society specialising – among others – in providing tools to bring (minority) languages to the computer. You may be offended by the former part, but as a person interested into linguistics probably still support the latter part. The cool thing about Graphite is that it allows you to define your own typesetting features by means of a scripting language called GDL. The commands from your definitions script would be compiled into a given TrueType font file as a last step, so that you receive a custom-tailored font that supports all kinds of dynamic placement and contextual repositioning you wish for. I actually made things halfway work this way once, with a font I didn’t dare to publish because it was too experimental, since I was by no means fluent in GDL, and it wasn’t very esthetic either. It just worked to a reasonable degree. However, as awesome the prospect of being able to describe your own placement rules by means of a scripting language and getting results that actually work may sound, the downside is that – to the best of my knowledge – Graphite is presently only supported by a few programs, most notably OpenOffice.org/LibreOffice, XeTeX, and SIL’s own WorldPad. There also is a pango-graphite library for Linux which extends Graphite functionality to other applications, such as Firefox, but that’s of no use for Windows computers of course. I gave up on trying to extend my script and rid it of bugs sometime because I had better things to do. I might pick up this loose end later again, though. Sadly, however, development of Graphite seems to have stopped, judging from its website, which hasn’t been updated in quite a while.

4. Anchors in OpenType

OpenType, a type rendering technology jointly developed by Microsoft and Adobe, is supported by far more programs than Graphite and theoretically comes with a number of features that might actually make a font file for my script work. It’s also what I’ve recently picked up again, after previous playing with OpenType features resulted in frustration (and is about to result in it again). OpenType allows you to not only define contextual variants and reordering, but also to define anchors that diacritics attach to. Essentially like in Graphite, except you don’t write a script, but e.g. FontForge has a WYSIWYG way to place them.

Thanks to ‘mark’ and ‘mkmk’, even assembling more complex characters seems very much feasible:

It sounds much like this actually should work in applications that support the simpler, or at least more Latin-script centered functions of the advanced typography features offered by OpenType. However, it turns out that the availability of such features varies quite a lot and is not a given. Thus, what looked like it would work correctly in Fontforge looks like this in Firefox 5 on Ubuntu 10.10 (with the current Firefox 6 Beta on Windows XP SP3 it looks the same, and it has been reported to me to not work at all in Firefox 5 on Windows 7):

As it seems, stacking diacritics is not quite supported the way I conceptualized it, although other fonts that make use of the ‘mkmk’ feature in OpenType – like Charis SIL – get correct placement, as can be seen in the compound character with ‹a› at the bottom line of the screenshot above. And one of Adobe’s flagship programs that supports a good deal of OpenType functions, InDesign (in my case, version CS3), makes it look like this:

Not even here things show up correctly: Although I made sure the ‹ka› character in the third row has all the necessary anchors, bottom-right attaching diacritics just won’t do that for some reason I haven’t yet figured out, while ‹pa› (looks like a Latin ‹n›), for example, does not seem to be a problem.

5. Conclusion

We have seen several approaches towards crafting a TrueType font for Ayeri’s ‘native’ script, Tahano Hikamu. Doing things with SIL’s Graphite or Microsoft/Adobe’s OpenType seemed most feasible, however, there are still barriers that I do not quite know how to tackle – which is frustrating, given that I’ve been trying to come up with solutions for several years already. It’s also the reason that I haven’t yet published such a font for the general public, although it rightly seems from examples I made before that I have two such fonts. However, they lack the functionality I desire, so working with them is rather tedious in that all positioning must be done by manual kerning, for example in InDesign or Photoshop. I hope that sometime I will learn how to achieve my goal of providing a working Tahano Hikamu font, however, not for the time being due to both, limitations in my knowledge of how computers handle TTF files, and restrictions in the implementation of features typesetting systems are theoretically equipped with.