Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

AAT Apple Advanced Typography for the writing systems of world scripts

Thomas Gewecke writes:

If I had to choose one problem which does exist and causes considerable practical difficulties for a lot of people, it would be that lack of full OpenType support in OS X (and the resulting requirement for rare AAT fonts) makes it impossible for Mac users to do everything they might want in a number of important scripts, or to do anything at all in quite a few others.


This is a frequently asked question, so perhaps the simplest solution is to try to support this in a separate thread. It is probably preferable to repeat what Apple has published on the Unicode mailing list on the subject of writing systems in world scripts. A link to a supplier of AAT fonts for lesser languages is included in the references (Bassa, Brahmi, Burmese, Cambodian, Georgian, Inuktitut, Kannada, Laotian, Lepcha, Limbu, Malayalam, N'ko, Osmanya, Sinhala, Tai Le, Tamil, Telugu, Tibetan ...). The most advanced Arabic implementation is Mishafi from Diwan in London - this has earned praise on Typophile. There are several independent software publishers (aside from Apple iWork) that support authoring with AAT Apple Advanced Typography.

According to the Apple Unicode Liason, Deborah Goldsmith, as of OS X 10.2 it is possible for the small type maker to support a writing system in a world script through the optional Apple MORX Metamorphosis Extended tables in the SFNT Spline Font file format. Dropping an SFNT and an input method into the operating system adds the shaping for the writing system. And according to the Apple Unicode Liason, as of OS X 10.4 the optional Apple MORX tables for complex composition and the optional Microsoft GSUB tables for complex composition may peacefully cohabit in the selfsame SFNT Spline Font file (leaving aside the issue of whether this is sound advice, or whether sound advice should say that an SFNT should contain either TrueType or Type 1, either MORX or GSUB - not both in either case).

Hope this helps,

Henrik


References :

http://www.mail-archive.com/unicode@unicode.org/msg13047.html

http://lists.apple.com/archives/carbon-dev/2006/Nov/msg00579.html

http://www.xenotypetech.com/

http://www.diwan.com/mishafi/main.htm

http://www.typophile.com/node/16858

http://www.typophile.com/node/18098

Posted on Jun 29, 2008 2:09 AM

Reply
27 replies

Jun 29, 2008 4:16 AM in response to Henrik Holmegaard

Thanks for the useful info.

Unfortunately AAT fonts, aside from those supplied with OS X or Apple apps, are still quite rare and often expensive, and I don't see much prospect that this will ever change. Greater OpenType support in OS X or specific apps might give users access to a large variety of free unicode fonts already available for most scripts, e.g. from here:

http://www.wazu.jp/index.html

Sometimes OpenType fonts for complex scripts will work in OpenOffice/X11, even when they are not supported in OS X proper.

I think the most important living language scripts for which OS X does not yet include a font are Sinhala, Myanmar, Ethiopic, Khmer, Classic Mongolian, Bengali, Oriya, Telugu, Kannada, Malayam, and Lao. Plus there are several scripts (Devanagari, Gujarati, Gurmukhi, Tamil, Tibetan) where users would probably like to have a greater choice of fonts than is currently available.

Jun 29, 2008 5:32 AM in response to Tom Gewecke

Sinhala, Myanmar, Ethiopic, Khmer, Classic Mongolian, Bengali, Oriya, Telugu, Kannada, Malayam, and Lao


Erhm ... what's wrong with Xenotype Sinhala ... Telugu ... Malayalam? For USD 19.95 there is the SFNT and the input method.

Free type is NOT the solution. Free type is part and parcel of the problem because there is no upgrade path for repairs and improvements.

The problem, if one wishes to find a problem, is first and foremost that the US laser imaging industry in the nineteen-eighties wanted type to be free of ties.

Prof Charles Bigelow discussed the position of the US laser imaging industry and the implications for type in papers and posts from 1986 to 1996-1997 when he gave up in disgust.

hh

Jun 29, 2008 6:01 AM in response to Henrik Holmegaard

There is an assumption that Arabic, Kanji, Hanzi ... have a long typographic tradition. They have not. The printing press was prohibited in Japan until the Meiji Restoration in 1870, the same year Tietgen's Great Northern laid the telegraph line to Nagasaki.

Monotype Nastaliq was introduced for the Monotype Lasercomp in 1981. Monotype used the same model Apple and Microsoft later used, that is, separating processing of semantic information from processing of stylistic information.

The coded character set for Farsi (Persian) was custom as John Latham couldn't find a common coded character set for Arabic closer than the telegraph character set of the Jordanian army. There were 32 characters in the custom character set against 20,000 glyphs in the glyph set.

Monotype, correctly, advertised that it is the introduction of the address space and of the plain text character string that permits writing systems in scripts which were calligraphic well into the twentieth century to become typographic at this turn.

Lithography alleviated the limitations, but Urdu into the nineteen-seventies was still supported by penning pages calligraphically, photographing the calligraphy, and copying the calligraphy photographically onto the printing surface for lithographic multiplication.

Monotype Nastaliq for OpenType is a major undertaking. It is not something Monotype is going to give away. Diwan Mishafi earned praise from Matthew Carter, Royal Designer for Industry. DecoType Naskh is a highend plug-in to Adobe InDesign Middle Eastern Edition.

The idea that OpenType should be for free, or that Apple Advanced Typography should be for free is like the idea that music should be for free or books should be for free.

Expecting Monotype, or Apple, or anybody else for that matter to supply free fonts for specialised academic applications is not the way ahead.

It is preferable that the SFNT programming be publically documented as opposed to the progammed deliverables being public by taking them from the type developer.

Why? Because if the SFNT programming is publically documented, the academic community can do its programming as well for its research projects as for its support projects, and do it right.

One can give away one's own work, but one can't give away the work of others.

hh

Jun 29, 2008 6:05 AM in response to Henrik Holmegaard

Erhm ... what's wrong with Xenotype Sinhala ... Telugu ... Malayalam? For USD 19.95 there is the SFNT and the input method.


I'm not aware of anything wrong with any Xenotype font. My list is of the major scripts where Apple does not yet (but should hopefully eventually) provide a font with OS X.

Free type is NOT the solution. Free type is part and parcel of the problem because there is no upgrade path for repairs and improvements.


What are you referring to by the term "Free type" exactly?

Jun 29, 2008 12:35 PM in response to Tom Gewecke

What are you referring to by the term "Free type" exactly?


Thomas wrote on bundled type and free type: "Unfortunately AAT fonts, aside from those supplied with OS X or Apple apps, are still quite rare and often expensive, and I don't see much prospect that this will ever change. Greater OpenType support in OS X or specific apps might give users access to a large variety of free unicode fonts already available for most scripts."

Included in OS X are lowend implementations of Thomas Milo's Decotype Naskh, Diwan implementations for Arabic script, Monotype Devanagari, and more. If one wants more, then e.g. the Decotype Naskh plugin for Adobe InDesign ME is available at a professional price. Professional Kanji type is also very, very expensive, but one gets a Mincho with a range that was larger than the Adobe range at the time of its introduction.

People don't want to pay for advanced character-glyph transforms and advanced colour-colourant transforms because they see these transforms as part and parcel of the graphical user interface, but the whole idea in modern imaging models is to farm out the making of advanced transforms to people who specialize in this, and for writing systems in scripts which are more calligraphic than they are typographic there is an enormous amount of work involved in making the transforms.

From the perspective of academic anthropology, Apple makes it possible to program any shaping whether predefined or defined for the specific SFNT Spline Font, provide a human sensible localisation in any writing system in any script inside the SFNT Spline Font file itself, and drop an input method for that shaping into the operating system alongside the SFNT Spline Font file. It is not the case that the shapings and their human sensible interfaces are cast in very, very, very solid corporate concrete. By the same token a software publisher is not obliged to support any writing system in any world script out of the box.

hh

Jun 29, 2008 1:10 PM in response to Henrik Holmegaard

for writing systems in scripts which are more calligraphic than they are typographic there is an enormous amount of work involved in making the transforms.


Be that as it may, the fact is that a good number of free OpenType fonts can be downloaded for the scripts mentioned earlier (Sinhala, Myanmar, Ethiopic, Khmer, Mongolian, Bengali, Oriya, Telugu, Kannada, Malayam, Lao, Devanagari, Gujarati, Gurmukhi, Tamil, and Tibetan). The ability to use these in OS X (or an app running in OS X) would solve many problems that currently arise for many people when they want to read/write their native language on a Mac rather than on a Windows machine. The availability of AAT fonts is not at all the same and not likely to ever become so.

Jun 30, 2008 3:19 AM in response to Henrik Holmegaard

So, free type is fine type. It is not about the composition model. It is not about the font technology. It is about the price.


I guess that I would say that it's about finding a way to enable the several hundred million people who use the scripts in question to have the same basic reading and writing capabilities for their native language which the rest of us get as a matter of course without having to buy something extra for our Mac.

I did not mean to imply that the situation with AAT fonts is hopeless. In the last couple years, thanks to the efforts of dedicated individuals, some free Bengali, Kannada, Telugu, Sinhala, and Ethiopic fonts have become available.

Jul 1, 2008 9:04 AM in response to Henrik Holmegaard

+So, free type is fine type. It is not about the composition model. It is not about the font technology. It is about the price.+

As a mere "end-user" (one of those whose purchases in aggregate have made Apple the billion-dollar corporation it is) who doesn't understand all these high-falutin' technical details, all I know is that I am limited to one (count 'em: 1) single, not especially elegant font for composing text in e.g. Devanagari -- a major world script used by hundreds of millions of people in a market Apple has sadly neglected.

Meanwhile, any Windows or Linux user has a choice of dozens or more freely-downloadable Devanagari fonts in a wide variety of styles (the typographical culture of Devanagari is not limited to a single style, any more than Latin letters appear only in Times Roman), several (at least) of them much better-looking than Apple's supplied Devanagari MT font. And, of course, if I send a Devanagari file to any Windows or Linux user, they'll be unable to read it.

In addition, though Devanagari MT is adequate for everyday typography in Hindi, Marathi, etc., it does not include many elements needed for composing Classical or Vedic Sanskrit. There is a downloadable OpenType font named Sanskrit2003 which does include all these capabilities, but it cannot be used in the Macintosh environment.

Yes, Sanskrit2003 is available for free, but I don't see how that necessarily makes it not "fine type"; it may not be the same technical quality as some high-end, sophisticated font used in industrial publishing applications (I really don't know), but it's surely technically equal to any other personal computer-level font, and superior in both capabilities and aesthetic design (to my eye, anyway) to the single Devanagari font Mac users can employ.

The same situation exists in the case of Tibetan and other Indic scripts. Yes, XenoType Techology has done great work in providing solutions for many of these (I've used XTT's Tibetan Kit since 10.2); but still, for all but Tibetan, XTT's kits expand Mac users' possibilities only to the level of Devanagari -- i.e. one or at most two possible fonts. While again, many fonts in varying styles are available to Windows/Linux users for the scripts Tom lists. And, though XenoType's kits are not expensive, even $30-50 is rather more than free (and in the countries where these scripts are used, quite a lot more).

Ironically, XTT's developer did manage at one time to make his primary Tibetan font usable in both Mac and Windows environments -- by somehow combining AAT and OpenType elements within it -- but his considerable effort was then torpedoed, I gather, by some (unannounced, as usual) changes Apple made in font implementation in 10.4. After that experience, he gave up, though a separate Windows version of his primary Tibetan font is still available. Which provides the only option for anyone who wishes to exchange Tibetan files between platforms (both users must purchase the XTT Tibetan Kit) -- while there is no such option for exchanging files in Devanagari, or any other Indic script.

From the little I understand about the technical details of the differences between AAT and OpenType, I'd guess AAT to be the superior system, from the user's (or font designer's) point of view. Nevertheless, as we know, Apple's superior systems did not become the norm in the computer world. And, although the same was true, I believe, of Apple's implementation of file metadata (type & creator codes, etc.) vs. the primitive, limited DOS/Windows file-extension system, Apple nevertheless capitulated for the sake of platform interoperability and made the latter system the norm in OS X.

I don't know what might be necessary to make it possible for Mac users to employ OpenType fonts for complex scripts, but I can't believe that this goal is simply beyond the capabilities of Apple's engineers. Nor do I understand why Apple seems to keep, well, stalling on this issue. (It's been six years since I switched to OS X, but I still can't send a file with Devanagari or Tibetan in it to a Windows user, or read one they send to me.)

I've read recently that Apple is finally putting a little effort into the Indian market; I suppose for now they're simply counting on Indian Mac users working mostly or entirely in English, but perhaps in time they'll see the wisdom of accommodating all the major native scripts as well. And rather than just providing a single Mac-only font like Devanagari MT that confines Mac users to a ghetto, wouldn't it be easier to enable Mac users to employ the already available plethora of OpenType fonts for these and myriad other scripts, so they both have real typographical choices and can talk to the rest of the world?

Jul 1, 2008 9:29 AM in response to HandyMac

I still can't send a file with Devanagari or Tibetan in it to a Windows user, or read one they send to me.


I don't understand that part. If such files are in the standard Unicode used by OS X or WinXP/Vista it should make no difference what platform is used to read it. Of course the app employed must be able to handle the script, and so far neither MS nor Adobe apps for Mac can display Devanagari or Tibetan, so you have to use something else.

Jul 1, 2008 10:37 AM in response to Tom Gewecke

+I don't understand that part. If such files are in the standard Unicode used by OS X or WinXP/Vista it should make no difference what platform is used to read it. Of course the app employed must be able to handle the script, and so far neither MS nor Adobe apps for Mac can display Devanagari or Tibetan, so you have to use something else.+

Well, I may be wrong about that; need to experiment more to be sure. I was mostly assuming given the incompatibility between fonts. I know Safari does display Devanagari and now Tibetan correctly on Wikipedia pages, and I assume most of those are composed in Windows, so there apparently is some interoperability. But of course even if I can send a Devanagari document to a Windows user, it still wouldn't show the font I used, since the only font I can use on the Mac for Devanagari can't be used in Windows.

Don't have Windows myself, but I can try creating a document in NeoOffice with Apple fonts, then opening it in Linux/OpenOffice and see how it looks. As noted elsewhere, I'm not really a big user of these things, but the above, er, rant is an expression of longtime frustration with something that seems to me should be relatively easy for Apple to fix and make things a whole lot easier for a whole lot of people -- including some who are big time users of Indic scripts and would like to do so on the Mac as easily as they could in Windows.

Jul 2, 2008 1:32 AM in response to HandyMac

Please pardon any speedwriting in the following - it's off the cuff :

From the little I understand about the technical details of the differences between AAT and OpenType, I'd guess AAT to be the superior system, from the user's (or font designer's) point of view.


The issue is the business model. Apple TrueType 2 and Apple ColorSync 2 were developed to provide very, very, very highend character:glyph transforms and colour:colourant transforms in an application-independent manner.

The application model was Java and OpenDoc and while OpenDoc is defunct, as is Taligent, Java within which AAT is embedded is alive and kicking. In the application model the idea was that the small developer did not have to independently do elements outside the scope of the application.

Similarly, a graphics library was available to avoid the problem that PostScript is inherently unreliable as it is a programming model that can be used to extend the PostScript graphics model, causing PostScript programs to crash at critical times.

Software publishers in the nineteen-nineties published software for the standalone personal computer with its suite of standalone software. And the standalone software had its own Application Programming Interface that locked XTensions, Plug-ins and more into one and only one suite.

Adobe did NOT want QuickDraw GX and Adobe still has a 'white' paper in which the company states that the idea of the SFNT Spline Font file format as an application-independent product that takes over large parts of line layout is objectionable.

The pendulum does not stand still, however. In the 1970s there were terminals for time-shared centralised computing. In the 1980s and 1990s there were decentralised 'personal' computers in local area networks with their own storage and with graphic displays and printers.

The growth of instructure, both in terms of distributed networking and in terms of an international character set, permits a blend of time-shared computing and 'personal' graphics computing which was intended e.g. with the Apple MessagePad and with Java (Amelio married the ideas).

Apple bled external and internal developers with the late lamented GX and the application model was ten years ahead of its time. Modern imaging models are founded on the ideas implemented in GX and absolutely NOT on the ideas implemented in PostScript and PDF.

Jonathan Seybold told Apple to do an application for pagination, since an application for pagination is the sine qua non for a composition model, a separation model, and a document model (the Apple Portable Digital Document model).

Apple did not do that as it would have caused increased commercial conflict with Adobe, Quark and Macromedia at a time when hardcopy production was still the high end of the Apple product portfolio, and so while ColorSync survived TrueType as prosumer and pro solution suffered.

Ironically, XTT's developer did manage at one time to make his primary Tibetan font usable in both Mac and Windows environments -- by somehow combining AAT and OpenType elements within it -- but his considerable effort was then torpedoed, I gather, by some (unannounced, as usual) changes Apple made in font implementation in 10.4.


Deborah Goldsmith gave bad advice on the Unicode mailing list, I'm sorry but it was not sound technically. Dov Isaacs, Adobe's technical quality manager, gave sound advice in saying that Type 1 splines and TrueType splines should not be housed in the selfsame SFNT Spline Font file. I read what the Xenotype developer posted, and Apple bungled as Apple has bungled other important things like supporting a decent international default separation for ColorSync. There is no excuse whatsoever - if Apple cannot use Apple software with Apple defaults to do a decent job then Apple needs to find out whether it is working for Apple customers or is working for itself.

I don't know what might be necessary to make it possible for Mac users to employ OpenType fonts for complex scripts, but I can't believe that this goal is simply beyond the capabilities of Apple's engineers. Nor do I understand why Apple seems to keep, well, stalling on this issue.


The answer lies in the document model, not in the internationalisation model or in the SFNT imaging model. I am not an expert on Indic scripts (I don't speak or write any of them), but as I understand the matter Indic calligraphic scripts are simulated typographically using a feature called insertion that splits one character code into two glyph codes for vowels.

This type of typographic simulation does not pose problems if you are authoring with the aim of archiving and accessing hardcopy, since your audience is not interacting with the character string, but if you are authoring, archiving, and accessing softcopy then simulation methods such as insertion and bidirectionality may pose problems.

Specifically, if in the process of producing your softcopy pagination you loose the source character stream and the mapping of said character stream to the reshaped and reordered glyph stream, then you have to try to synthesise the character stream. And the more complex the reshaping and reordering, the less likely you are to get a successful simulation.

This is the issue between Adobe PDF produced from PostScript and Microsoft XPS which retains as well the source character stream as the mapping of the character stream to the glyph stream. Adobe PDF, by contrast, is basically a viewable graphic of the glyph stream - Adobe PDF does not even retain semantics for reshaping of formal Danish typography.

Hope this helps,

Henrik


References:

http://www.freepatentsonline.com/y2007/0136660.html

Jul 2, 2008 4:36 AM in response to Henrik Holmegaard

The answer lies in the document model


I don't think the document model and the issues you raise regarding character/glyph streams and .pdf format have anything to do with making Mac's able to use particular features of OpenType fonts. A fair amount of progress in this direction has already been made in OS X with regard to Latin and Arabic. Plus individual apps like Mellel and OpenOffice/X11 are able to do even more. It's just a question of developing the software engines required.

Jul 2, 2008 6:18 AM in response to Tom Gewecke

It's just a question of developing the software engines required.


Cart and horse, chicken and egg - the point is that you can't pick one or the other, it's both or you are standing stock still. Which is what has happened for a decade and a half. Adobe Mars attempts to marry the page description model to the page markup model, but beta only began in late 2007.

The point is that the document models are the brakes on composition models. You can work around the document model with a smart separation model (just colour manage TIFF, drop that into QuarkXPress 3.x, and emit passthrough PostScript), but you can't work around the document model with a smart composition model.

hh

AAT Apple Advanced Typography for the writing systems of world scripts

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.