Using Tibetan In Macintoshes

THL Toolbox > Tibetan Scripts, Fonts & Related Issues > Using Tibetan in Macintoshes

Using Tibetan in Macintoshes

Contributor(s): David Germano, Chris Fynn, Chris Walker

Mac OS X 10.5.0 (Leopard) onwards comes with full Unicode Tibetan support in the base install, including two fonts (Kokonor and Kailasa) and three keyboard layouts. Scope of support includes full Unicode Tibetan block coverage and stacks for transliterated Sanskrit plus some contemporary Chinese phoneticizations. However, limitations persist for Tibetan in the software, which often does not work properly with Unicode Tibetan despite the systems support. Earlier Mac operating systems have only partial support for Tibetan Unicode.

As explained below, there are two types of Unicode Tibetan fonts - Open Type and AAT, with Windows historically focusing on supporting the former and Mac supporting the latter. In Mac LION OS, most typical software programs will work only with the AAT fonts (Kokonor, Kailasa) and not with the Open Type fonts (Tibet Machine Uni, Microsoft Himalayan, Jomolhari). However, there are some exceptions where Mac software will work with Open Type fonts but not with AAT fonts. In addition, there are very frustrating situations where the AAT fonts won't even show up in the font menu for a software application, even if you can see the "font group" to which you might have assigned them. There are, however, some Open Type fonts (Jomolhari-ID and the newer Qomolangma fonts) that have been specially adapted with a trick to work in Mac applications. These are usually the most reliable since they typically work in all the environments, if Tibetan Unicode will work at all. Finally, it is possible to build hybrid fonts that have both AAT and Open Type functionality, though few have gone to the added expense and size (Xenotype seems to claim this is what it has done).

Thus, for example ((most current versions as of January 2011), Open Office and Keynote works fine with AAT fonts, but not with Open Type fonts. In contrast, Outlook 2011 and Text Edit work fine with all Tibetan Unicode fonts. Word 2011 however is extremely frustrating - standard Open Type fonts will work, but AAT fonts won't even appear in the font menu, nor will Qomolangma. InqScribe, a commercial transcription program THL uses, works only with Jomolhari-ID and Qomolangma, since it won't properly render standard Open Type fonts like Himalayan or Tibet Machine Uni, but oddly won't even show AAT fonts like Kokonor or Kailasa in the font menu! Xenotype - we are still checking whether we have the most current version - doesn't show up in the font menu for InqScrib, and doesn't work for Word 2011.

All in all, it remains a very frustrating situation for Tibetan language in the Mac OS at present. However, if you are patient, and try a variety of fonts, most times you should be able to find a happy solution. However, there are situations where there is no solution at all possible - such as in JAVA software like ELAN transcription. This, however is the fault of Java's disastrous support for complex scripts, and has nothing to do with Mac OS. The same limit applies in Windows.

Other pages:

Fonts

Mac OS X 10.5.0 (Leopard) comes with two Unicode Tibetan fonts developed by Prof. Shojiro Nomura of Otani University and Steve Hartwell:

Kailasa - System font (More compact; used for User Interface labels)
Kokonor - Application font (used for Documents and the Finder)

See Tibetan Fonts to view all available fonts.

You may have files using non-Unicode Tibetan fonts and want to convert them to Unicode (see Conversion-Reversion for Tibetan Fonts).

One problem is that Tibetan Unicode requires the use of "smart font" technology to create Unicode Tibetan fonts because of the complex nature of Tibetan as a script. Unfortunately, there are two competing types of "smart font" technologies - OpenType and AAT. Macintosh has supported OpenType since Panther (Mac OS X 10.3), but the support has been partial. Instead it more fully supported the AAT system. With the Leopard version of their operating system, support of OpenType underwent a major expansion. While documents created in an OpenType or AAT Unicode font can be converted back and forth without a problem, it does mean that the variety of OpenType Unicode Tibetan fonts won't work well on the earlier Macintosh operating system versions.

Microsoft Office 2011 for Mac supports Tibetan Unicode. This eliminates the problem of Tibetan letters not stacking correctly in the Microsoft Office suite of applications (Word, Excel, and so forth).

From Chris Fynn, April 2009: AFAIK Microsoft Word on Mac OSX does not support complex script fonts - neither AAT nor OpenType. There is no complex script rendering engine like Uniscribe included in MS Office for the Mac, and it does not seem to make use of Apple's services for this provided by the operating system.

Keyboards

Mac OS X 10.5.0 (Leopard) comes with three keyboard layouts:

Tibetan - Wylie - (EWTS 2.02)
Tibetan - Otani
Tibetan - QWERTY

See Tibetan Input Tools for Macintosh to view all available input methods and how to use them).

Macintosh Software Support for Tibetan Unicode

You have to determine if a given software program supports Unicode Tibetan, since not all programs support it just because the operating system supports it (see Software Support for Tibetan in Macintoshes to view software program support).

Technical Background

Beta versions of Leopard yielded the following problems, which we need to check in the released version of Leopard. The stacking works well in TextEdit, but some multi-stacked characters still are not displayed correctly (however, that could have been because I was typing somewhat randomly - not knowing Tibetan nor Wylie). Tibetan Machine Uni still doesn't stack properly using Leopard's built-in Wylie input method.

A cool feature is that you can search for files containing Tibetan using Spotlight (Tiger and Leopard's integrated search feature) by simply typing in Tibetan. Spotlight found documents that used Tibetan Machine Uni, as well as Kailasa. It did not find documents containing the equivalent Tibetan characters in Jomolhari, though it found them when I copy & pasted Jomolhari text into Spotlight. Filenames can contain Tibetan and stack properly when the input is completed, but not not always while typing.

Leopard supports OpenType fonts, as well as TrueType, Postscript Type 1, Multiple Master and Font Suitcases.

Smart fonts are necessary for displaying writing systems with various complex behaviors, such as:

contextual shaping
ligatures
reordering
split glyphs
bidirectionality
stacking diacritics
complex positioning

Leopard is supposed to have full support for Open Type GSUB & GPOS except for some of the context-dependent alternate features. There is no Tibetan language support engine for pre-processing of Tibetan unicode characters. Therefore any Tibetan font that requires no Unicode pre-processing and only uses normal GSUB and GPOS features will work.

Extensive testing of Leopard is required to figure out any limitations, and what modifications of the lookups in extant Open Type fonts might be necessary to work round whatever limitations there are. Vowel substitutions in Tibet Machine Uni obviously use context-dependent alternative substitutions since the shape and position of the vowel often varies depending on the preceding stack. Without an explicit list, we don't know if these lookups are using any of the features that are in the "some" not supported - or just the remainder that presumably are. Also what features are included in "normal GSUB and GPOS features"? Which GSUB and GPOS features do they consider "abnormal"?. (e.g. Are one-to-many substitutions, required to deal with certain Sanskrit vowels, considered "normal" or "abnormal"?)

"Any Tibetan font that requires no Unicode pre-processing" is not clear - if characters occur in the order that I would expect someone to type them there may be no need for "pre-processing" since that is more or less the ideal ordering for open type processing. However due to Unicode normalization process having previously occurred for some other reason (e.g. collation, or transmission over the internet) some character may have been re-orderd due to that normalization process. To "require no Unicode pre-processing" the lookups would have to be designed to deal with characters at least two possible sequences:- the order which you would expect someone to type them and the order after any Unicode normalization process.

Normally you would expect some pre-processing to be done by Uniscribe so that the character string that is presented to the lookups is in the order that is most efficient for those lookups - whether or not the characters had previously been "normalized" for some other reason. This may not have too much impact on regular Tibetan sequences and you can probably include extra lookups so that the font works with either sequence.

There is also another kind of "pre processing": most open type shaping engines categorize Tibetan characters in different groups (e.g. punctuation, digits, base consonants, sub-joined consonants, subjoined vowels, above base vowels, other below-base marks and other above base marks and only applies specific features to specific categories of characters. So usually you don't have to handle sequences this categorization excludes. At the very least you may have to include reasonable some "error handling" lookups for such sequences as Leopard would not otherwise handle them.

Uniscribe and other OT shaping engines also apply a specific sub set of OT features in a specific order - which may vary dependent on the script involved (the set of features and the order in which individual features are applied may be different for e.g. Arabic, Devanagri and Tibetan) Since it appears there is no in-built script-specific processing done by Lepoard's shaping engine the order in which OpenType features are applied is important - lookups always being dependent on any that have occurred before. I assume that Lepoard blindly applies the ("normal") lookups it finds in a font without any pre-processing (re-ordering or character classification) with the exception of lookups using some context dependent features (exactly which features these are unspecified).

It is probably possible to re-tailor the font lookups so that they work with Lepoard - though to do this might effect its efficiency on all platforms - but we need many more specific details.

Also - Mac OSX apparently uses more than one font shaping technology (just which is used apparently depends on whether the application is "Cocoa", "Carbon", or whatever) - and some Mac applications use their own OpenType shaping technology. So we need to know just which applications actually take advantage of the "full support for Open Type GSUB & GPOS" that Lepoard provides - and, maybe more importantly, which don't. (The latter category probably includes MS Word on Macs)

Generally there is a whole different philosophy between the way Mac and Windows/OpenType support complex scripts. Essentially, on Windows a lot of the script specific stuff ("pre-processing") is expected to done by Uniscribe or other OT shaping engine so the lookups can be designed without having to deal with that - and only a specific sub-set of features is applied to a specific script - (if others are included they don't get applied). This way of doing things means the lookups are fairly straightforward and reliable - though there are limits and constraints to what you can to. On Macs there is no script specific knowledge (character preprocessing and categorization) built into the shaping engine. The font developer is expected to build that into the font itself - this is far more flexible but requires far more work on the part of the developer and consequently more testing. There is probably also a lot more error and exception handling

If an OpenType font requires little or no pre-processing and features are applied in a "normal" (non script specific) order it appears that what Lepoard can do is to "translate" the OpenType lookups it finds in a font into AAT / ATSUI lookups and then apply them. Like any machine based translation this will have limitations though you can tweak the source so the resulting translation works better.

To make some things work (or to work round these limitations) it might also be possible to include some lookups under features not applied by Uniscribe for Tibetan but which would presumably get translated and applied by Lepoard.

All this would probably be much easier with Jomolhari than with TMU since, in most cases, Jomolhari (which as pre-composed stacks including vowels) uses straight forward substitutions where TMU has context dependent substitutions. [There is a trade-off here since the number of combinations TMU supports is consequently much higher.] Jomolhari does use context dependent substitutions to get alternative glyph forms but this is mostly for better appearance and positioning in specific situations (typographical niceties). In the case of Jomolhari the text is perfectly readable if these context dependent features are not applied - while with TMU you might get vowels which don't match or over print the stack which would make the text pretty unreadable. MS Himalya would probably be totally un-usable since it uses a lot of context-dependent lookups even to compose consonant stacks [this makes the font much smaller (and uglier) since it gets by with a much smaller number of glyphs - composing many on-the-fly].

Summary

Probably OpenType Tibetan font could be made to work within the restrictions imposed by Leopard's "translation" - though one would need a lot more information on things like the specific order in which Lepoard applies features, which of the the context-dependent alternate features don't work - and which kinds of lookups and features are excluded from what Apple consider to be normal GSUB and GPOS features.
Doing this would likely add to the complexity and size of the lookups required in the font - and hence could impact performance on all platforms, particularly with large text files.
It would be easier to do this with a font like Jomolhari than with TMU.
It would be foolish to attempt to do this without a Mac running the target applications in order to test whether things were working.
Without the specific information mentioned in 1. it is difficult to predict how complex doing this would be - though it is likely to be somewhat easier and less problematic than adding a whole set of AAT / ATSUI tables to the font.

Also all you are going to end up with is one Tibetan font that works on Windows and Linux applications that support OpenType, and on those Mac applications actually built to take advantage of Leopard's limited OpenType "support". A concern is the latter might be pretty much the same group of applications that already work with the Xenotype font - and exclude those that don't.

A closely related issue which should be considered here is getting Tibetan fonts to work in Adobe applications like InDesign, Photoshop, and Illustrator. For current documentation on using Tibetan unicode fonts in Adobe InDesign CS5 and CS6, see external link: http://digitaltibetan.org/index.php/How_to_prepare_InDesign_CS5,_CS6_for_Tibetan_script. Again there is no specific support for Tibetan in Adobe's own OpenType engine (used on all platforms) but this can be worked round by including extra lookups in the font which get applied by the Adobe engine but ignored by Uniscribe (the Adobe engine ignores almost all the features normally used for Tibetan so the tables can co-exist without much trouble). Jomolhari-ID was specifically designed to fix this problem, but we have not tested it ourselves and so we cannot confirm that it works. The Bejing "Qomolangma" fonts also may have the same design as Jomolhari-ID.

Since they pretty much have a monopoly on software used by publishers and printers, getting Unicode Tibetan script to work in Adobe CS applications is a far more important urgent need here than getting the font to work on Macs (which wouldn't cover Adobe applications since they have their own font shaping engine). Without this publishers of newspapers, periodicals and so forth cannot use Unicode since all their pre-press systems and equipment is pretty much tied to Adobe applications.

However because of the nature of the lookups required by the Adobe engine to make Tibetan work, my guess is that if you made a font with extra lookups that worked with the Adobe engine this would also work with Leopard with little or no change - so doing things this way could solve two problems at once and be far more beneficial.

THL Toolbox > Tibetan Scripts, Fonts & Related Issues > Using Tibetan in Macintoshes