At 14:59 11/2/2002, Doug Ewell wrote:
> It should be noted that using ZWJ is a valid way to encode the > desirability of a ligature in plain text, but it is far from being a > guarantee of displaying such a ligature. There are a lot of fonts out > there with glyph substitution lookups that will correctly display > something like a ct ligature using layout features (discretionary, > controlled by the user) in OT savvy apps like Adobe InDesign, but > will do so only for the sequence c+t. Ironically, the sequence > c+ZWJ+t is more likely *not* to display as a ligature, since the ZWJ > interferes with the sequence recognised by the font lookups.
But using ZWJ still requires proprietary layout features in OT-savvy apps. Whenever you're mapping from a character sequence to an unencoded glyph variant, you need a higher level protocol than is provided in a character encoding standard. c+ZWJ+t needs to be resolved to a ct ligature, and that requires a font level lookup and a line layout engine that understands and implements such lookups.Using ZWJ to control ligation is admittedly a new concept, and it may not have been taken up yet by many vendors, but that seems like a really poor reason to discourage the Unicode approach.Proprietary layout features in OT-savvy apps like InDesign might get the job done, but wouldn't it be better if app vendors and font vendors would follow the Unicode Standard recommendation? You never know, it might even reduce the number of requests to encode ligatures.
The useful thing that the ZWJ does is to provide authors with a means to explicitly request ligation in a plain text document, but this is a *very* unusual requirement outside of a couple of obscure scripts (e.g. Old Hungarian). When someone sits down to type a typical English language document (or German, or French, etc.), he generally does not think about ligatures at all: he types his language in the commonly accepted manner, inputting character codes. Ligatures are a *typographical* feature of the Latin, not an orthographic one. Authors, by which I mean any user creating a document, do not think about ligatures unless they happen to be specialists, e.g. palaeographers, working with documents in which features such as ligatures are germane to the content. In probably 98% of all Latin script documents, standard ligature substitution should be automatic and global, which is what current smart font and professional layout applications provide (of course, users can turn ligatures off, globally or on an individual basis).
There are hundreds of thousands of books and periodicals published every year, almost all of them using standard ligatures in accordance with 500 years of typographical convention. I suggest that, at most, a handful of authors gave any thought to ligation while they were writing their texts, either because they are specialists working in document studies, or because they feel the need to meddle in the typographer's job.
So, from this it should be obvious that we need automatic ligature substitution in higher level protocols using smart font features, because most documents that should have ligatures when published will not have them encoded in the text source. This is the reality of publishing, and it is the market on which the vast majority of font developers are focused. In this market, ZWJ ligation is rightly viewed as unnecessary except for a very small minority of specialist uses that will probably require specialist fonts from specialist foundries.
Far from discouraging my colleagues from supporting ZWJ in font lookups, I've made proposals on the OpenType list suggesting how this might be done in a way that is easy, does not conflict with current ligature implementations, and respects authorial intent (by using the Required Ligatures <rlig> feature instead of the optional Standard Ligatures <liga> feature). I don't expect many people to do this, since ZWJ ligation provides a solution to something that almost no one sees as a problem.
Finally, I don't think it is right to characterise ZWJ ligation as 'the Unicode approach' if the implication is that the approach taken in smart font technologies like OpenType, AAT and Graphite are somehow anti-Unicode. All these technologies are based on Unicode text processing, and the Unicode character/glyph model is the basis of the higher level protocols that they provide.
John Hudson
Tiro Typeworks www.tiro.com
Vancouver, BC [EMAIL PROTECTED]
It is necessary that by all means and cunning,
the cursed owners of books should be persuaded
to make them available to us, either by argument
or by force. - Michael Apostolis, 1467
