AAT Apple Advanced Typography for the writing systems of world scripts

An update on parallel support for Apple TrueType 2 and Microsoft OpenType:

For a decade the Unicode Mailing List has discussed whether the way to get support for ligation into Microsoft Word is through direct drawing (: the ligated glyph is directly drawn as an incorrect public character or as a private 'character' in the Private Use area of Unicode) or through indirect drawing (: the ligated glyph is indirectly drawn as a glyph code which preserves spelling, sorting and searching). There are plenty of posts by John Jenkins urging that Microsoft support either Apple's or Microsoft's solution to indirect drawing, or support both. Simply to put a stop to the problem of direct drawing that spoils spelling, sorting, and searching.

There is no online trial of Word for Mac 2008, but the online help states that ligation is now supported as well for Apple TrueType 2 / Apple Advanced Typography as for Microsoft OpenType. The burden is now on Apple to support searching of complex composition, whether in the Latin, Greek and Cyrillic scripts that have a linear relationship between input character order and output glyph order or in Arabic and Indic scripts that have a non-linear relationship between input character order and output glyph order.

"Turn on ligatures, or joined characters: Ligatures are joined or decorative characters that are available in some fonts. Not all fonts contain ligatures, but many OpenType fonts contain ligatures, as well as some Apple fonts, such as Apple Chancery and Zapfino ... Ligatures in Apple
fonts are supported under all versions of Mac OS X. Ligatures in OpenType fonts are only available under Mac OS X v10.5 (Leopard)."

Best,

Henrik Holmegaard

Reference:

http://www.microsoft.com/mac/help.mspx?target=bb7b56a7-5237-40ec-89a8-6cd103e5cd 1d1033&clr=99-4-0&ep=8&rtype=2&pos=1&quid=cc029434-184c-4e64-b568-6dfbe3526bb4&C TT=Search&MODE=ct&locale=en-US&usid=e90e8505-8c95-43fe-9341-fd62e29afd35

Nothing has changed about any "document models" as far as I know.

When PDF is created from PS the source character information in the SFNT imaging model and the source colour information in the ICC imaging model is sought on mounted disks, and if not found there it must be synthesised.

PS may be an internal intermediate format (: you do not see PS saved to disk) or an external intermediate format (: you see PS saved to disk). The degree to which synthesis is successful depends among other things on the script.

If the output glyph order is the same as the input character order (: linear order), then chances of successfully synthesising the source character string are higher than if the output glyph order is not the same as the input character order.

This is nothing new, for instance, there are public posts by Eric Muller of Adobe on the Unicode Mailing List.

Best wishes,

Henrik Holmegaard

In that context the new ability of Word for Mac to use AAT fonts for ligatures that Word for Windows cannot display is of little or no value.

Apple and Microsoft agreed at the start that content information should stay intact in complex composition. The Unicode Consortium is based on the idea that content information should be portable. This is achieved by an imaging model that permits a different glyph repertoire per font, preventing the problems of an imaging model within which a glyph can be drawn if and only if it is depicted as a character in a character set. Some fonts may encode a rich appearance for a given writing system in a world script, others a less rich appearance, some the bare minimum (in the obligatory CMAP), others none (if they do not support the script).

The person who purchases an authoring application should purchase the fonts that provide the level of graphic appearance she desires. Under the terms of the end user licence, she is not allowed to interchange the font files themselves. She should not anticipate that her audience has to acquire the same authoring application as she has. She is, however, allowed to interchange the content information (which is her own creation) in page markup models, and she is allowed to interchange the content and the appearance in page markup models where the font information is not extractable.

There are problems with the process from Adobe PostScript to Adobe PDF. These problems impact different scripts differently, if Adobe PostScript is preserved as intermediate format.

Adobe PDF has the ability to hold as well the glyph stream as the character stream, provided Adobe PostScript is not the intermediate format.

For this to work SFNT Spline Fonts without broken CMAPs are necessary as well as content preparation with content structure in Adobe PDF 1.4.

PDF/A is supported in OpenOffice 3.0 beta supports Mac OS X, for instance, and Microsoft has announced support for PDF/A in a coming Service Pack.

If the document model works properly, it is also possible to solve the invertibility issues of Arabic and Indic scripts which are the most non-linear.

The best place to convey your personal opinions

Is it possible to have a more pleasant exchange, perhaps?


Best wishes,

Henrik Holmegaard

Basically, graphic information processing has to do non-destructive drawing. If graphic information processing does destructive drawing, then there is no repurposing. You have to be able to draw a glyph design without the glyph code for that glyph design being directly depicted onto a character code in a coded character set. If you can only draw a glyph design by direct depiction onto a character code in a coded character set, soon searching, spelling and sorting have collapsed in your composition model and so has computer communication which is based on constant content specifications.

Below from the World Wide Developer Conference in May 1989, before the Seybold Conference on Computer Publishing on 20th to 23rd September 1989. The New York Times featured the Seybold Conference and what followed, see a simple search of www.nyt.com.

/hh

Reference:
http://www.mactech.com/articles/mactech/Vol.05/05.10/Typography/index.html

And she has no concern with the issues involved with pdf other than to know how create one from her Word doc when a printer or someone else asks for that instead of .doc.

In Microsoft Windows Vista, the Save as PDF function for Microsoft Office strips ICC profiles / colour specifications when saving into Portable Document Format. A printer who asks for a PDF from Microsoft Office is asking for some serious trouble, because what the pagination will have is deviceRGB and deviceCMYK with no way of knowing how to convert to the intended printing condition. Whether the Save as PDF function also clips character specifications e.g. for Microsoft OpenType ligation is not known - I neither have Microsoft Windows Vista nor do I have Microsoft Office.

"Many of the applications in a print provider‟s workflow will already process PDF files perfectly well, so it‟s clear that the 'Save as PDF' plug-in offers significant advantages over saving as XPS. The print provider must take a little care still, because that only saves as a baseline PDF file, without guaranteeing that all fonts be embedded, and without including characterization data for the colors." ( http://www.globalgraphics.com/xps/faq.pdf)

I don't think the scenario you describe has much relevance to anything that goes on in the real world.

What 'real world'? What private person or professional publisher wants device data in the pagination - whether RGB/CMYK colourants that do not reference standard colour specifications or TrueType/PostScript glyphs that do not reference standard character specifications.

Sure, if you find it possible to start using these forums for their intended purpose instead of as a soapbox for all your erroneous personal opinions.

Sic.

/hh

Smart glyph scaling has been said to be obsolete. Smart glyph scaling is used as well in Latin typography as in non-Latin typography.

There is support for smart glyph scaling in CoreText. The support for smart glyph scaling includes TrueType Variations and Type 1 Multiple Masters.

"The API provides font viewing and selecting. It provides font references, font descriptors (objects that encapsulate font data sufficient to instantiate a font reference), and easy access to font data. It also provides support for multiple master fonts, font variations, font cascading, and font linking."

/hh

Reference :

http://developer.apple.com/documentation/Carbon/Conceptual/CoreTextProgramming/Overview/chapter_2_section4.html

Multiple Master fonts have not been produced for some time now, being replaced by OpenType in 2000.

OpenType is a set of extension tables to the TrueType Specification. Type 1 Multiple Master is a type technology, specifically a PostScript font program dictionary format.

The idea of interpolating between style axis was introduced by Ikarus, the first professional font production program developed by the folks in Hamburg before PostScript.

Similarly, Fontlab today uses the idea of interpolating between style axis in the font production process, but saves out fonts for simple linear scaling.

Among the extension tables termed OpenType there is a function that supports separate fonts in a series that are automatically selectable.

This is supposed to be the substitute for a single font with smart non-linear scaling. It is not a user friendly substitute, though.

/hh

Warning !!

Apple Pages is installed with ligation as default. Deselect ligation as default. If you do not deselect ligation, ligatures in Apple Advanced Typography, Microsoft OpenType and Adobe OpenType will compose, but will not decompose into the standard character specifications you input when you save out PDF softcopy. The only ligatures that stay searchable in PDF softcopy are the Modern English ligatures that Anglo-Academic academic communities caused to be included in the international standard character set. These are in the Alphabetic Presentation Forms block in Unicode, see the Apple Character Palette.

To deselect automatic ligation, open the default Document Inspector and deselect the checkbox Use Ligatures at bottom right.

Best wishes,

Henrik Holmegaard
technical writer, mag.scient.soc.