ISO/IEC JTC1/SC2/WG2 N2147

2000-01-06

Universal Multiple-Octet Coded Character Set
International Organization for Standardization
Organisation Internationale de NormalisationŒåæäóíàðîäíàß îðãàíèçàöèß ïî ñòàíäàðòèçàöèè
Doc Type:
Title:
Source:Status:Date:

Working Group Document
Further discussion of the ZERO-WIDTH LIGATOR
Michael Everson
Expert Contribution
2000-01-06

1. Structure of font styles. A given Latin typeface typically has a minimum of four fonts associatedwith it: plain, italic, bold, bold italic. Each of these is a self-contained unit, containing in it all theglyphs made available by the designer for the character set it handles.

UtopiaUtopiaçƒêîò‡Ž’—œ‚•Þß

Utopia Italicçƒêîò‡Ž’—œ‚•Þß

Utopia Boldçƒêîò‡Ž’—œ‚•Þß

Utopia Bold Italicçƒêîò‡Ž’—œ‚•ÞßGlyphs are accessed by various input methods: they are associated with coded characters enteredwhich oÉen will have a many-to-one relationship with the glyphs which may be presented inindividual glyph cells. Glyphs are typically precomposed units, though mechanisms may exist for
dynamic presentation of character sequences which do not have, in the font, a particularprecomposed glyph; cf. phonetic fonts where bounding-box parameters may be used to represent
sequences of base characters and combining characters.
Precomposed ligatures in fonts and their respective typographic styles have existed since the timeof the earliest printed typefaces. The top two lines in the sample below (taken from BringhurstÕs
Elements of typographic style) are from an italic font cut in the 1650s (350 years ago) by CristoÀel
van Dijck, and the last bottom lines are ligatures from AdobeÕs Caslon roman and italic, based on
William CaslonÕs font from 1750 (250 years ago).

2. Input methods to access characters. Various input methods may yield the same codedcharacter sequence: one may press the ÒaÓ key + the Òring aboveÓ deadkey, or one may press theÒŒÓ key (on a Danish keyboard), or one may press ALTÐÒkÓ + the ÒaÓ key. In all three cases thecharacter sequence generated will be (in normalized Unicode text) LATIN SMALL LETTER A +COMBINING RING ABOVE. This inputting model is the one currently used and it works just Þne.
Inputting is separate from encoding but generates coded character sequences, and codedcharacter sequences are related to glyph selection. In most cases, since Œ is a letter found inPage 1

ISO/IEC 8859-1 (a popular standard), this particular character sequence will be linked to aparticular precomposed glyph cell in the font, which will have some sort of address. The speciÞc
assignment of the address to which a coded character sequence points is up to the designer andis in no way standardized or standardizable, since it is not practical to try to exhaustively specify
what sequences of base characters and combining characters could be required in general, andthe total requirements of a given language are only sometimes predictable.
3. Style selection. Style selection is much diÀerent than glyph selection. It des not involve notchoosing a glyph cell within a particular font, but rather switching between a set of linked fonts(plain, italic, bold, bold italic) Ð such selection is outside the scope of character encoding and ishandled by markup of various kinds. Within a particular style, glyph selection should be based on
the relation given by the designer to glyph cells and a set of coded characters, alone or insequence. At present, however, within a particular style, only the accented-letter type is so
selected; ligatures are not.
NOTE: Most people use the word font incorrectly. The hierarchy goes like this:Typeface name:

UtopiaFont style:
Plain

Font style:
ItalicFont style:
Bold

Font style:Bold Italic

Glyph cells:
Aaç‡BbCc‚•DdEeƒŽÞßê
’î—§òœ
Y y Z z etc.

Glyph cells:
Aaç‡BbCc‚•DdEeƒŽÞßê
’î—§òœ
Y y Z z etc.

Glyph cells: Glyph cells:
Aaç‡Bb Aaç‡Bb
Cc‚•Dd Cc‚•DdEeƒŽÞßê EeƒŽÞßê
’î—§òœ ’î—§òœ
Y y Z z etc. Y y Z z etc.

4. The current model as applied to Brahmic scripts. The same set of parameters described above
applies to Brahmic scripts, as in a Devanagari font. Inputting is separate from encoding but
generates coded character sequences, and coded character sequence is related to glyph selection.
One may press the Ò¬Ó ka key + the Ò-ôÓ i key, or the Ò-ôÓ i key + the Ò¬Ó ka key, and in either casethe character sequence generated will be DEVANAGARI LETTER KA + DEVANAGARI VOWEL SIGN I, and thatsequence will select a glyph cell which gives -¬ ki. Conjuncts (equivalent to ligatures) areachieved by coded character sequences, regardless of inputting: a keyboard may have a dedicatedÒ§Ó ks.a key, and pressing it will yield the coded character sequence DEVANAGARI LETTER KA +DEVANAGARI VIRAMA + DEVANAGARI LETTER SSA (¬ + ô™ + ¯), and that sequence will select a single glyphcell (§) in the font; or one can type explicitly pressing the Ò¬Ó ka key, the Òô™Ó VIRAMA key, and theÒ¯Ó s.a key with the same result. At another level, markup may switch to an italic or bold font; thisform of switching is familiar and has been implemented for both Brahmic and European fonts.
5. The current model as applied to Arabic scripts. Arabic cursive shaping behaviour is intrinsic
to the script and glyph selection with regard to cursivity is rule-governed and must be automatic.
When this automatic behaviour must be overridden for some purpose, the ZERO-WIDTH JOINER and
ZERO-WIDTH NON-JOINER are used, as invisible characters with cursive shaping properties, to selectparticular glyph cells according to the same parameters. This elegant model works very well for
Arabic and other related cursive scripts like Syriac and Mongolian, though a number of scriptspeciÞc characters were added for Mongolian to handle some otherwise unpredictable shaping
behaviour in plain text. For the question of true Arabic ligatures, see page 19 below.
Page 2

6. The current model as applied to European scripts. The current model fails in its handling ofligation in European scripts. This is because, inconsistently with the mechanism used forBrahmic scripts, certain individual glyph cells (ligature glyphs) in a font are not accessed bystrings of coded characters, but rather by Òsome sortÓ of markup, while other glyph cells(accented vowels and consonants) are accessed by strings of coded characters. This is a diÀerent
model than that used for shiÉing between font styles via markup; it forces a relationship between
various undeÞned and ad-hoc markup levels (Òturn on all ligaturesÓ, Òturn on ÔsomeÕ ligaturesÓ)which itself introduces a level of complexity between font designers, application programmers,
and end users which is quite unsatisfactory. Quark XPress allows the Macintosh user to turn Þ andß ligatures on or oÀ, and this works from font to font because these two ligature pairs are hardcoded in standard positions in Macintosh 8-bit fonts; but other ligatures are not recognized by
XPress at all (the inquisitive reader is invited to save the present PDF Þle as plain text to see what
I have had to do to represent all the f-ligatures which I have used consistently within it). The UCS
also encodes a very small subset of ligatures in the FB block, but I agree that it is better for thevectoring from character sequence to glyph cell to be internal to the font, since this leads to fewer
normalizable characters and addresses the diÀerence in typefaces, some of which may have agreat many ligatures and some which may have only a few.
7. Logic of the ZERO-WIDTH LIGATOR. The proposed ZERO-WIDTH LIGATOR allows font designers,
programmers, and users to apply the same logic for ligatures that they apply to accented letters.
Like the SOFT HYPHEN, the ZERO-WIDTH LIGATOR character may in some instances (Òall ligatures onÓ)be automatically inserted at input. This would work Þne for the most common Latin ligatures, i.e.
those in f-, or for a superset of those, involving ct and st ligatures and the like, available from anapplication according to the same criteria employed by AAT and OpenType now. Other forms ofligation, however, such as those required in the Gutenberg Bible, in modern Fraktur German, orin earlier Irish and Greek typography (for which conventions may diÀer from document todocument even in the same typeface), can be dealt with at input by the user, or globally aÉer
inputting, by specifying ZERO-WIDTH LIGATOR insertion, or by deletion of ZERO-WIDTH LIGATOR in thecase of Turkish and Azerbaijani fi (see page 6 below).
Glyph selection within a font (Utopia roman and Utopia italic are two diÀerent fonts) should not
be handled in two diÀerent ways. Selection of the glyph Ž derives from a vector-relation between
coded character sequence and glyph cell. Selection of the ligature Ñ should make use of the samemechanism. Ligation in European scripts is not a style attribute. It is a glyph-selection attribute,and style is a diÀerent level of abstraction. Unicode is currently inconsistent in the way it speciÞes
European ligatures and the way it speciÞes Brahmic ligatures.
Code0065 0301
0915 093F
0066 ZWL 006C
0915 094D 0937
16DE ZWL 16DE
168F ZWL 168F
xx0A ZWL xx00
xx04 ZWL xx0D ZWL xx15
xx00 ZWL xx14 ZWL xx02
03C0 ZWL 03B1 ZWL 03C1 ZWL 03B1
0574 ZWL 0576

Glyphe + ô«¬ + -ô
f + ZWL + i¬ + ô™ + ¯
Þ + ZWL + Þ• + ZWL + •Š + ZWL + €„ + ZWL + • + ZWL + •€ + ZWL + ” + ZWL + ‚ð + ZWL + á + ZWL + ò + ZWL + á– + ZWL + —

Ž

Latin

-¬ ki

Devanagari

Þ

Latin

® ks.aDevanagari
ç dd
Runic
õ rr
Ogham
Æ ga
Old HungarianÂ csinOld Hungarian´ amb
Old Hungarian· para Greek
˜ mn
ArmenianPage 3

8. Example of Runic ligatures (bind-runes). A 9th-century Old English inscription fromThornhill, Yorkshire, showing a single ÞÞ dd ligature:¼ÁÚË¢Ì¦ì ª±«±ÞÖì « ÏÖ ÒÖ±»ÏË¢Ì¦Öë ÒÖæ¢¾ ©¾ÓÖ±·Á·ÖÓÁçª¦ë ¦«±ì Ëª¢ÚÖjilsui¯:

ar¾rde:¾Éeberhtsui¯eá

bekun

onbergigebidda¯á

¯¾r:

saule

If this text were encoded with a ZERO-WIDTH LIGATOR, all the user would have to do is ensure that
ZERO-WIDTH LIGATOR appears between Þ and Þ (Ò&Ó is used here to show the ZERO-WIDTH LIGATOR):¼ÁÚË¢Ì¦ì ª±«±ÞÖì « ÏÖ ÒÖ±»ÏË¢Ì¦Öë ÒÖæ¢¾ ©¾ÓÖ±·Á·ÖÓÁÞ&Þª¦ë ¦«±ì Ëª¢ÚÖ
If on the other hand there were no ZERO-WIDTH LIGATOR, but instead a ZERO-WIDTH NON-LIGATOR were
implemented to prevent ligatures where they were activated globally, this text would have to be
coded thus (ÒÍÓ is used here to show the ZERO-WIDTH NON-LIGATOR):¼ÁÚË¢Ì¦ì ª±«±ÞÍÖì «Í ÏÖ ÒÖÍ±»ÍÏË¢Ì¦ÍÖë ÒÍÖæÍ¢Í¾ ©¾ÓÖÍ±·Á·ÖÍÓÁÞÞÍª¦ë ¦«Í±ì ËªÍ¢ÚÍÖ
The 55-character text would have to be burdened with 14 ZERO-WIDTH NON-LIGATORs to override anautomatic ligation option; otherwise it would display with all the potential ligatures in thisparticular font (note the Þè dda triplet):¼ÁÚË¢Ì¦ìª±«±àì

áÏÖÒâãË¢Ìäë

åæ©¾Óâ·Á·åÁÞè¦ë

¦éì

Ëêë

It should be noted that Runic ligation must be considered now to be productive; a web search onÒbind-runesÓ will lead to a large number of sites explaining how runes can be combined by themodern user for various ÒmagicalÓ purposes. More serious, however, would be the use runologists might make of sorting and searching bind-rune for statistical analyses, etc. Ð whichcurrently cannot be done eÀectively, as bind-runes can only be achieved at present either byprivate-use characters or markup. Plain text character coding is certainly more reliable.
9. Examples of Gaelic typographic ligatures. Two identical texts (Luke 2: 8Ð14) from two diÀerent
publications using the same typeface but in which diÀerent ligature choices were made. One
might call this Òligature classmentÓ. Both samples are from Uilliam OÕDomhnuillÕs translation of
the New Testament: the sample on the right was published in 1827 (173 years ago) in Dublin by
G. and J. Grierson and M. Keene for the British and Foreign Bible Society; the sample on the leÉ
was published in 1849 (151 years ago) in Dublin by Hardy and Sons. Words containing
typographic ligatures are shown in outline style.

8 ¦ AguÅ do ´‡daÃ ‡o¸aiÃi¸e Åa dÝà¶e Åin na
gc—ÀnÜ¸e amÝ¼, ä ag deanaÀ faiÃe —i¸¶e - adtÃŽud.
9 AguÅ, fŽu¶, do ×±Å aing±l an T’¼±Ãna l‡iÀ lŽo,aguÅ do ×oillÅi¼ gl—iÃ an T’¼±Ãna na dtim¶±ll: ä do
¼a´ ±gla m—Ã ’ad.
10 AguÅ a dœ´-t an taing±l Ãiœ, Na b’o¸ eagla oÃÜ´:—iÃ, fŽu¶, a t‡im ag ÅoiÅgŽulu¼a¸ ¸’´ g‡iÃd±¶uÅ m—Ã,no¶ ´’aÅ do ga¶ Üle Âobal.
11 O’Ã Ãuga¸ an Sl‡nÜ¼àe—iÃ ¸‡oi´ a niœ¼ (Ža¸onCÃ’oÅd an T’¼±Ãna), a gcaàÃÜ¼ Dh‡i´i.
12 AguÅ ag Åo c—ÀaÃàa ¸’´; Do ¼Žu´à‡oi an l±n´ceangÜlte a ngioblÜ´, na lÝ¼e a mai–ÅŽuÃ.
13 AguÅ do ´’ go hoba– cÜd±¶da À—Ã do ×lœa¼
n±À¸a a ´fo¶aiÃ an aingil ag mola¸ DŽ, ä ag Ã‡¸,
14 Gl—iÃ do Dh’a a– Åna h‡ÃdÜ´, ä Å’o¸¶‡in aiÃ an
dtalaÀ, d±¼àoil do na d‡oini´.

8 ¦ AguÅ do ´‡daÃ ‡o¸-i¸e Åa dœià¶e Åin Õna
gc—ÀnÜ¸e amu’¼, ä ag dŽana¸ faiÃe —i¸¶e aiÃ adtÃŽud.
9 AguÅ, feu¶, do ×eaÅ aing±l an T’¼eaÃna l‡iÀ leo,ä do ×oillÅi¼ gl—iÃ an T’¼eaÃna Õna dtim¶eall: ä do
¼a´ eagla À—Ã iad.
10 AguÅ a dœ´-t an taingeal Ãiu, Na b’o¸ eagla oÃÜ´:—iÃ, feu¶, a t‡im ag ÅoiÅgeulu¼a¸ ¸’´ g‡iÃdea¶uÅ m—Ã,no¶ ´’aÅ do ga¶ Üle Âobal.
11 «OiÃ Ãuga¸ an Sl‡nÜ¼àeoiÃ ¸‡oi´ a niu¼ (Ža¸onCÃ’oÅd an T’¼±Ãna), a gc‡àÃÜ¼ ·‡i´i.
12 AguÅ ag Åo c—ÀaÃàa ¸’´; Do ¼Ža´àaoi an l±n´
c±ngÜlte a ngioblÜ´, Õna lÝ¼e a mai–ÅŽuÃ.
13 AguÅ do ´’ go hoba– cÜdea¶da À—Ã do ×lœa¼
neaÀ¸a a ´fo¶- an aingil, ag mola¸ DŽ, ä ag Ã‡¸,
14 Gl—iÃ do ·’a a–Åna h‡ÃdÜ´, ä Å’o¸¶‡in aiÃ an
dtalaÀ, d±¼àoil do na d‡oini´.

Page 4

To facilitate comparison, the texts are given below in Roman type with ligatures expanded, withthe words containing the expanded ligatures printed in outline style.
8 ¦ Agus do ´‡dar ‡o¸airi¸e sa dú ià¶e sin na
gc—Ànu i¸e amú i¼, ä ag deanaÀ faire —i¸¶e a i r adtrŽud.
9 Agus, fŽu¶, do Öe as ainge al an T ’ ¼e ar n a l‡iÀ lŽo,agus do Öoillsi¼ gl—ir an T’¼e arna na dtim¶e al l: ä do
¼a´ e ag l a m—r ’ad.
10 Agus a dœ´airt an taingeal riœ, Na b’o¸ eagla orui´:—ir, fŽu¶, a t‡im ag soisgŽulu¼a¸ ¸’´ g‡irdea¶us m—r,no¶ ´’as do ga¶ uile Âobal.
11 O’r ruga¸ an Sl‡nu i¼àe—ir ¸‡oi´ a niœ¼ (Ža¸on
Cr’osd an T ’ ¼e ar n a), a gcaàru i¼ Dh‡i´i.
12 Agus ag so c—Àaràa ¸’´; Do ¼Žu´à‡oi an le an ´ceangu ilte a ngioblu i´, na lú i¼ e a m a in nsŽur.
13 Agus do ´’ go hoban n cu ide a¶ d a À—r do Ölœa¼
ne aÀ ¸ a a ´fo¶air an aingil ag mola¸ DŽ, ä ag r‡¸,
14 Gl—ir do Dh’a an n sna h‡rdu i´, ä s’o¸¶‡in air andtalaÀ, de a¼àoil do na d‡oini´.

8 ¦ Agus do ´‡dar ‡o¸airi¸e sa dúià¶e sin Õna
gc—Ànu i¸ e amuí¼, ä ag deana¸ faire —i¸¶e air adtrŽud.
9 Agus, feu¶, do Öeas ainge al an T’¼earna l‡iÀ lŽo,agus do Öoillsi¼ gl—ir an T’¼earna na dtim¶eall: ä do
¼a´ eagla m—r ’ad.
10 Agus a dœ´airt an taingeal riœ, Na b’o¸ eagla orui´:—ir, feu¶, a t‡im ag soisgŽulu¼a¸ ¸’´ g‡irdea¶us m—r,no¶ ´’as do ga¶ uile Âobal.
11 «Oir ruga¸ an Sl‡nu i¼àe—ir ¸‡oi´ a niœ¼ (Ža¸on
Cr’osd an T ’ ¼e ar n a), a gcaàru i¼ ·‡i´i.
12 Agus ag so c—Àaràa ¸’´; Do ¼Žu´à‡oi an le an ´ceangu ilte a ngioblu i´, na lú i¼ e a m a in nsŽur.
13 Agus do ´’ go hoban n cu ide a¶ d a À—r do Ölœa¼
neaÀ¸a a ´fo¶air an aingil ag mola¸ DŽ, ä ag r‡¸,
14 Gl—ir do Dh’a an nsna h‡rdu i´, ä s’o¸¶‡in air andtalaÀ, de a¼àoil do na d‡oini´.

Although the same font is used for these examples, ligature behaviour is not the same for the two
texts, and indeed in the Þrst text, eagla ÔfearÕ is written both eagla (verse 9) and ±gla (verse 10), andair ÔonÕ is written both - (verse 8) and aiÃ (verse 14). The glyph selection is not rule-governed, and
it is impractical at best to suggest that the font designer, even though he or she is permitted to
specify various ÒclassesÓ according to the AAT/OpenType model, should be able to specify all thepossible glyph-selection levels in a particular font, because the choice may diÀer greatly fromdocument to document. It is not as it is in English, where one might have simplistic choices likeÒall f-ligaturesÓ, Òall f-ligatures and ct/st ligaturesÓ, and Òall available ligaturesÓ. In scripts like
Runic, Ogham, and Old Hungarian, where nonce-ligatures oÉen occur (and where there are also
examples like eagla/±gla), the ZERO-WIDTH NON-LIGATOR would be a serious nuisance.
There are also a few other minor spelling diÀerences between the two. texts: îir ÔforÕ is written O’Ã.
and «OiÃ in verse 11; also fŽu¶ and feu¶ for fŽac ; also Dh’a/·’a for Dia. The speciÞc î = «O = Ov«
orthographic conventions used in a printed text may be of interest to researchers sorting or
searching Ð syntactic analyses of the word —ir Ôfor, becauseÕ (French ÔcarÕ) require that the.
researcher knows that the spellings «oir and o’r also apply. Note in verse 8 the word amuigÔoutsideÕ appears as amÝ¼ (with ligature, = amœi¼) and amu’¼. Implementation of ZERO-WIDTHLIGATOR would code the Þrst as amœ&i¼. Could researchers wish to distinguish amÝ¼/amœi¼/amu’¼
for some purpose? With ZERO-WIDTH LIGATOR, they would be able to do so, more simply than withmarkup.

On the leÉ, a sample of text set in Watts type in 1845 (155 years ago), with the ligature – nn used
once in line 1 and the ligature - air used once at the end of line 4. On the right, a sample printed
in the Irish Echo in America in 1890 (110 years ago), which uses no ligatures at all.
Page 5

The AAT/OpenType model as currently applied to Latin seems to have been developed only tocater for decorative ligation, but as we have seen, ligation may not be simply decorative. Editorial
choices regarding spacing, legibility, and so on were made in preparing the texts above. Suchchoices may be considered signiÞcant in textual analysis; certainly as noted above the presenceof bind-runes in Runic texts is likely to be considered signiÞcant by runologists. Use of ZERO-WIDTHLIGATOR to eÀect typographic ligation would permit researchers to sort and search taking ligatures
into account, because they would be explicitly marked in plain text by the encoding.
Other forms of ligation vs. non-ligation are signiÞcant as well: in ISO/IEC JTC1/SC2/WG2 N2141,
I noted that
For most languages, Latin Þ and ß ligatures are not optional in good typography (Turkish and Azerbaijani
require a distinction to be made between fi and fõ but presumably permit ß ligatures.) É The end-userprobably cannot [reprogram the ligature management mechanism to override automatic font ligation].
But he or she can choose to insert or delete a ZERO-WIDTH LIGATOR. An Òunintended nasty consequenceÓ
could, for instance, make a font unusable for Turkish or Azerbaijani Ð a problem avoided by the use or
non-use of ZERO-WIDTH LIGATOR.

Ligatures of fi (Þ) are proscribed in Turkic Latin environments. The current model puts theburden of providing a speciÞc ÒTurkicÓ level of ligation into their fonts upon the designers. How
many designers are linguistically literate enough to anticipate this? The number is certainly a verysmall subset of font designers. With ZERO-WIDTH LIGATOR, a language-independent and scriptindependent solution, users will be able to select, manually or automatically depending on
inputting soÉware, the ligatures required, and the need to have fonts containing an explicit
Turkic option does not arise, as the ZERO-WIDTH LIGATOR solution is general at the level of coding.
NOTE: Being conservative, and keeping to 16 Turkic languages which could make use of theTurkish i/õ distinction, and bearing in mind the fact that some of these populations presently
use the Arabic or Cyrillic scripts, the user community potentially requiring Turkic handling of
the fi ligature is approximately 105,750,000. Of these, we know that 62% of them (the Turks andthe Azeris) are in fact writing with the i/õ distinction. ThatÕs 66 million users.

In the discussions to date, we have seen an attachment by aÞcionados of the AAT/OpenTypemodel to its purported richness, but failing the introduction of a ZERO-WIDTH LIGATOR which selects
glyphs based on coded character triplets, the end user is stuck with whatever tables a designer has
seen Þt to include in his font, which could well render a great many Latin fonts unusable to up toa hundred million Turkic-speaking users. Yet the UCS already permits coded-character-sequencebased glyph selection for Brahmic scripts; it is illogical that we not do so the same for European
scripts.
10. Examples of Greek typographic ligatures. Early Greek typography makes use of a very rich setof ligatures.

On the leÉ, a text in Latin and Greek, both making use of typographic ligatures (ca. 1770, 230 yearsago). On the right, a ligature for the word ðáòá ÔnearÕ.

Page 6¦°Ë¤Ãª äïàìï÷ ¹èóïù Ìòéóôïù, ëìèôÞ÷ áðÞóôïìï÷, áæöòéóíÛîï÷ åé÷ åùáççÛìéïî £åïà, (Þ ðòïåðèççåÝìáôï äéÀ ôöîðòïæèôñî áùôïà åî çòáæáÝ÷ áçÝáé÷,)ðåòÝ ôïù ùéïù áùôïà, (ôïù çåîïíÛîïù åë óðÛòíáôï÷ ¢áâÝä ëáôá óÀòëá, ôïà ïòéóõÛîôï÷ ùéïù £åïù åî äùîÀíåé ëáôá ðîåàíá
áçéöóàîè÷ åê áîáóôÀóåö÷ îåëòñî ¹èóïùÌòéóôïù ôïà ºùòÝïù èíöî, äé ïà åìÀâïíåî øÀòéî ëáÝ áðïóôïìÜî åé÷ ùðáëïÜî
ðÝóôåö÷ åî ðÀóéî ôïÝ÷ Ûõîåóéî, ùðÛò ôïàïîÞíáôï÷ áùôïà, åî ïÝ÷ åóôå ëáÝ.É

On the leÉ, text printed by Robert Estienne in a font by Claude Garamond, Paris 1550 (450 yearsago), showing an extremely complex array of ligatures; on the right, the same text (Romans 1: 1Ð6)transcribed. Which is simpler, using markup to represent the text, or using the ZERO-WIDTHLIGATOR? Setting this text would be time-consuming either way Ð but the ZERO-WIDTH LIGATOR is
portable in plain text.

Modern font revival of Alexander WilsonÕs 1756 Greek typeface, with 17 tying ligatures.
11. Ligatures in Old Hungarian. Old Hungarian is perhaps one of the best examples with regard
to this discussion. The principal reason that Old Hungarian has not already been accepted forcoding in the UCS is the ligation requirement. The basic set consists of 45 letters, a set of 79
ÒcanonicalÓ ligatures promulgated by Hungarian experts on the net, and a set of 63 ligatures
which I had found in two other sources. The ÒoÁcialÓ expert view is that the 63 additional
ligatures are ÒunsafeÓ (whatever that means) and that only the 79 should be supported. It is mybelief that one of the reasons for this is the space limitation of the currently-available PC
implementations of Old Hungarian fonts. I can Þnd no principled reason for not accepting these
additional ligatures as authentic ligatures (found as they are in texts expounding the use ofligatures in the Old Hungarian script). Indeed, the Hungarian experts want to insist that the 79ÒcanonicalÓ ligatures be explicitly encoded in the UCS, and have not accepted my assertions thatthe character/glyph model supports the Old Hungarian ligation requirements. In part, this isbecause of the vague nature of the current model, which would have ligatures either on or oÀ; I
cannot tell the Hungarians Òno problem, in plain text you can just use ZERO-WIDTH LIGATOR and you
will be ÞneÓ, but instead have to refer them to as-yet-unavailable AAT/OpenType technologies,
which, as presently constituted, oÀer no plain text mechanism for ligature presentation, which
the Hungarians donÕt like. It is for this reason that the Hungarian experts insist on hard coding of
their ligatures even in the UCS, so that they are available when required. ZERO-WIDTH LIGATOR would
guarantee that whenever required, a ligature could be coded, while leaving ordinary
representation available for general purposes. In fact, of the 79 ÒsafeÓ ligatures, six of them are noteven considered by these experts as ligatures, but rather are viewed as Devanagari § ks.asometimes is, as unique indivisible characters, analysed by shape only. (The experts even give
dubious ÒEgyptianÓ scarab-beetle etymologies to explain these Òbug signsÓ.) All of these havenormal ligature transliteration decompositions, and if ZERO-WIDTH LIGATOR were available, it would
Page 7

be far easier to assure the Hungarian experts that € + ZWL + ” + ZWL + ‚ would be used to represent² amb with concomitant support for lexical, sorting, and searching operations. Of the 63 ÒunsafeÓ
ligatures, the Old Hungarian data shows the extreme example of ° Osk‡nt. But this is no diÀerent.
from Devanagari ì rs. t. yaøm where the sequences — + ZWL + • + ZWL + • + ZWL + •é + ZWL + • + ZWL+ and í + ô™ + î + ô™ + ï + ô™ + ð + ñ + ôò can each point to unique glyph cells in a font.
€‚ = ±€… = ²€Š = ³€”‚ = ´€•… = µ€• = ¶€œ = ·€ =¸•œ = ¹‚€ = º‚† = »‚ =¼‚• = ½‚— = ¾ƒ€• = ¿
ƒ• = À

„€ = Á
„•• = Â…£ = Ã
†”› = Ä†• = Å
Š€ = Æ
Š† = Ç
Š• = È
Š— = ÉŒ€ = ~
Œ† = Ë
Œ• = Ì
Œ— = Í• =Î
Žœ = Ï
’€ = Ð

’• = Ñ
’† = Ò
’— = Ó
’ =Ô
”‚ = Õ
•€ = Ö
•€› = ×•‚ = Ø
•ƒ = Ù
•… = Ú
•‹ = Û
•• = Ü
•• = Ý• =Þ
—œ = ß
œ€ = à

œ† = á
œ• = â
œ— = ã
œ =ä
œ£ = å
•€ = æ
•† = ç
•• = è
•• = é
•” = ê
•— = ë
•› = ì
• =í
Ÿ =î
•=ï
›œ£ = ð›œ£• = ñ¡€ = ò
£’ = ó
£” = ô
£•• = õ£œ = ö
£Ÿ = ÷
§€ = ø
§•œ = ù¨€ = ú¨œ = û¨ =ü
€’‚ = ý€’‚ = þ€œ = ÿ

„• = €…• = •…œ¨•• = ‚
Ž =ƒ•„ = „•‹2 = …
•› = †• ’=‡—• = ˆ
œ„ = ‰
œ„• = Š•• = ‹• €=Œ
€„ = ••„ = Ž
•• = •€œ£ = •€• = ‘
•• = ’‚• = “Š =”…” = •… =–‰• = —‰•’ = ˜‰“ = ™
Œ• = š
’€• = ›•• = œ
•• = •••• = ž•• = Ÿ

’‚ =••2 = °’… = ¡••€ = ±’§ = ¢•••• = ²”•… = £
•œ† = ³•• = ¤£’• = ´••¨ • = ¥ §€œ = µ•• = ¦§• = ¶••† = §§••• = ·—• = ¨§” = ¸›€ = ©
§œ = ¹› Œœ£ = ª •’… = º—•••• = « ”€ = »œ„•• = ¬ ‹œ = ¼•• = ½œ˜ = œ=¾
œ˜… = ®
œ§ = ¯

12. Rules for ligation in Fraktur German. From Albert Kapr, Fraktur: Form und Geschichte dergebrochenen Schriften. Mainz: Hermann Schmidt. 1993. ISBN 3-87439-260-0. My translation.
2. Fraktur ligatures: Â Ã Ä Þ ß Æ Ö Ú Û ö § ÷ à á (÷ ø À Þ ß É ù ú û ü § ý ¸ ¹)
The summarized rules of use (ignoring the case of the commonly known §):Ñ Ligatures are used if they do not disrupt linguistic correctness: doÂ, RuÃ, hoÄen, verÞlzt, ßaÂ,oÆ, laÖen, [FiÚ], Ûe, Waöer, A÷, reàen, Kaáe (do÷, Ruø, hoÀen, verÞlzt, ßa÷, oÉ, laùen,[Fiú], ûe, Waüer, Aý, re¸en, Ka¹e)
Ñ They are not employed in word compounds: auffordern, SÂilfinÅel, SÂnupftuÂ (auffordern,S÷ilfinÿel, S÷nupftuch)
Ñ Word stems must be observed: iÂ kaufte (i÷ kaufte), but single letters at the ends of words
are not ÔdetachedÕ: gekauÆ, Auß. (gekauÉ, Auß.)Ñ Syllables are not relevant: ÅaÆig (ÿaÉig) is set with a ligature; the word stem is ÔSaÉÕ.
Ñ Should three letters which appear together, of which a ligature could be made from any twoof them, the syllable-division decides: pÞfÞg, OfÞzier, Soufßeur (pÞfÞg, OfÞzier, Soufßeur)Ñ Ligatures are not used to save space. Exceptions: Â, Ã, á and § (÷, ø, ¹ and §)There are apparently no ligature triples in Fraktur. Note the recently discussed example WaÂstube
Wachstube Ôwax tubeÕ vs. WaÂ÷ube Wachþtube ÔguardroomÕ.
13. Costs of ZERO-WIDTH LIGATOR implementation. In the short term, it is true that the provision ofa ZERO-WIDTH LIGATOR will not solve all problems immediately, and it does (or could) necessitate areanalysis of recommended practice with regard to the current AAT/OpenType model. At thesame time, however, it must be noted that the takeup of that model has been less than admirable,
so we are not talking about a huge change in coding practice which will costs millions to a great
many companies. To date I have been informed of only one product that implements the current
AAT/OpenType model, and I am unconvinced that this is the best model given the ligation
requirements of European scripts (which are a good deal greater than the use of f-ligatures inEnglish and German).
Page 8

I argue that a single consistent mechanism for ligature formation will beneÞt users of the UCS,
that this is already present in the coding conventions for Brahmic scripts, and that the greatest
number of user needs can be satisÞed by harmonizing European ligature selection with theproven-successful mechanism used for Brahmic scripts.
John Jenkins asked me what mechanism I would employ to achieve ligature variants but I say thatthe same mechanism used for Devanagari et al. will serve here. ¬ + ô™ + ¯ yields §, but it may also
yield ®. The same sort of thing happens in Tibetan. Mechanisms exist in Devanagari WorldScript
and Tibetan (third-party) WorldScript to allow the user to select variant ligatures Ð but theunderlying encoding (used for sorting and searching) specifying that a ligature is used remains
the same, and whatever mechanism is used for those scripts should serve just as well for
European scripts. The fact is that the current Brahmic model works perfectly well, and is superior
to the ad-hoc AAT/OpenType ligature model, because it is consistent with established UCS
principles of using coded character sequences to specify glyph selection. There is no need tomake European scripts a non-plain-text exception, since ligation behaviour in European scripts,
while less extensive than it is in Brahmic, can easily beneÞt from the use of the same principles,
if we will only choose, sensibly, to normalize now.
Use of ZERO-WIDTH LIGATOR makes glyph selection simpler and application-independent, sinceapplications will have to deal with doublets and triplets of base-character + combining-character
sequences in any case Ð ZERO-WIDTH LIGATOR simply adds a new set of coded-character-to-string
vectors.
Practically speaking, with regard to cursor placement, etc., implementation of ZERO-WIDTH LIGATOR
is no diÀerent from implementation of SOFT HYPHEN. With XPress now, when selecting text
containing the SOFT HYPHEN, I oÉen meet with the invisible SOFT HYPHEN character between twoother characters in a word. It took me only a moment to learn that this occurred, and that was
years ago; it is second nature to me now.
13. Excerpted discussion of the ZERO-WIDTH LIGATOR from the Unicode list, with comments.
John Jenkins said:
I havenÕt seen anyone claim that ligation control should be handled entirely by soÉware. The
OpenType/AAT model is explicitly opposed to that assumption.

Well, that is a fault in the analysis that led to the present AAT/OpenType model. It works for trivial
substitutions like standard English f-ligature behaviour. It fails in the long term where more
complex ligation behaviour is indicated. But itÕs not a total failure Ð because the AAT/OpenTypemodel already supports the basic model of Brahmic character-based glyph selection. The failure
is insisting on trying to do Latin ligation with a diÐerent model, i.e., without explicit encoding.
Abandon this and you are leÉ with something that works in all contexts.
The end user still has complete control over the process. The soÉware merely enables this and provides
default behavior.

But the choice and formatting of the user (i.e. the speciÞc ligature behaviour selection) is notpreserved in plain text. This is another fault that can be easily abandoned.
It would be possible to write such an editor for Mac OS 9 in about a page of code. WeÕre working on
sample code and demo applications to show how this can be done. And itÕs been possible to do ever since
we released the late lamented GX Þve years ago.

When will such an editor be available? It wasnÕt available 5 years ago either.
Adobe InDesign Ð and admittedly non-cheap program Ð can handle an awful lot of Latin ligatures. I
believe it could handle anything you put in your OpenType font, at least manually. Given InDesignÕs
extensive plug-in architecture, it would be possible to get it to do whatever you want.
Page 9If, and only if, you are a computer programmer and can write a plug-in. Most users and fontdesigners are not programmers. Even expert users like me are not able to do this. ZERO-WIDTHLIGATOR puts real control at the Þngertips of the end user, and facilitates the vectoring of glyphs forthe designer. Surely this beneÞts everyone. The font designer and the end user are the people whohave to deal with the provision and use of ligatures in actual text. The big companies have alreadydone the right thing for Brahmic scripts, and now only need to accept a single logical model andemploy the same model for Latin that we promulgate to everyone else.
There are two issues here. One is getting system soÉware support. The other is getting applications totake advantage of the system soÉware support. The latter can be an enormous uphill battle, as our
experience getting people to support ATSUI shows.

System soÉware that supports the Brahmic paradigm should be able to be conÞgured to
implement ZERO-WIDTH LIGATOR with a minimum of eÀort and expense.
The former is also enormously problematical. The problem is that the TrueType spec doesnÕt oÀer any
direct support for mapping multiple characters to single glyphs Ð the presumption is that this is handled
in the AAT/OpenType tables. I donÕt know how OpenType libraries like UniScribe or CoolType work, but
I know enough about the guts of ATSUI to say that it would be fairly diÁcult to get it to handle ZERO-WIDTHLIGATOR;Not at all. If e + ô« = Ž, why shouldnÕt f + ZWL + l = ß ?
ZERO-WIDTH NON-LIGATOR would be comparatively simple. I would imagine that OpenType would have
similar problems. Basically ZERO-WIDTH LIGATOR would be useless except for a plain-text exchangemechanism, and even there it would be problematical.

It is a question of ensuring that certain strings of characters point to certain glyph cells. You guys
have been telling us font designers for years that smart fonts is the way to go. Well, I for one
believed you, and I am telling you that I canÕt get what I need from your present model, but witha simpler model (already compatible with AAT/OpenType as applied to Brahmic) we have noproblems at all, apart from a short-term model overlap.
I think itÕs a bit on the na•ve side to assume that just adding ZERO-WIDTH LIGATOR would solve the problem.
WeÕd be three or four years at best before weÕd get support at the OS level and then down to the app level.
The point is that there is already a mechanism in place on both Windows and the Mac that can solve theproblem. WeÕd be far better oÀ IMHO to deÞne exchange formats for cross-platform use that includes
ligation information.

I am aware of the temporal problem. I can live with it; the UCS is forever. I am, however,convinced that ZERO-WIDTH LIGATOR is the simplest and best solution. Your Òmechanism in place on
the MacÓ is not in place on the Mac, except in a technology which has not been snapped up byhardly anyone. Sorry, gods know I donÕt like to say this, but there is no mechanism for this on myMac, and the mechanism that you are promulgating does not serve my needs. It is needlessly
complex and too open-ended. It burdens me, if I want to make and Old Church Slavonic font that
handles all kinds of OCS typography, with knowing what all the possible permutations of ligatures
could be, but this is is impossible to know, since the permutations can diÀer from document todocument and even from sentence to sentence within a document. What I need is a way to typewhat I need and to have the data preserved in plain text. You can automate that input to yourheartÕs content for Latin f-ligatures. Just give us a consistent coding model for ligature behaviourfor European and Brahmic scripts alike. Bite the bullet Ð this problem will not go away till you dowhat we tell you we need! The problem has been identiÞed and discussed for a decade already.
The AAT/OpenType model has not been implemented, and it is inadequate. A simpler model,
compatible with AAT/OpenType and current Brahmic practice, exists, and if you implement it
you will serve the user. You need to stop trying to cheat the rendering engine by pretending that
Latin f-ligatures can be handled without character coding. Why do we not handle non-standard
Arabic glyph behaviour with markup, instead of with an explicit ZERO-WIDTH JOINER and ZERO-WIDTHJOINER? Your (pl.) arguments are just as valid for that situation as they are for Latin ligature
Page 10behaviour. Either character-code sequence points to glyph cell, or that kind of selection should
always be handled by markup. The mixed model is inadequate and problematic. Character-code
sequence is by far and away more preferable.

Peter Constable said:¦

But ligatures that are in free distribution with non-ligated forms are exactly the kind of thing that ought
to be speciÞed using style/formatting information applied to the run of characters: it does not haveanything to do with the meaning of the text but is purely there for presentation purposes.

Not so: ZERO-WIDTH JOINER/ZERO-WIDTH NON-JOINER also have no relation to the meaning of coded
text string Ð they only deal with text presentation.
Ligation in this case can be handled using such a mechanism, selected by the user using some UI device,with the OS/rendering engine applying a feature that applies the appropriate substitution. In such casesof ligation, it should not be a requirement that the ligature be retained when exchanged via plain text any
more than should the choice of typeface, point size, bold, italic, etc. Such presentation information does
not belong in plain text.

No, because italic markup switches between fonts (as opposed to switching typeface), and ligation
selects speciÞc cells within a font.
If we start talking about encoding in Unicode all presentation distinctions in ancient documents thatmight prove to be signiÞcant (but also might not), wonÕt we end up turning this character encoding
standard into a glyph encoding standard? Maybe this rhetorical question is reactionary and that is could
be feasible to add such to Unicode in a controlled manner. Just sounds scary.

My 1849 Irish bible is not ÒancientÓ. Anyway, the ZERO-WIDTH LIGATOR is just a way of doing
something we already do in the standard in order to eÀect an identical kind of glyph selection
behaviour with Brahmic scripts and fonts.
Asmus Freytag said:¦

What is at the heart of this recurring request is that support for many scripts (or older typographies) is
incomplete without an interchangeable method of indicating the precesence or absence of ligatures.

Correct.
Posing this question allows us to consider the full-featured typorgraphic and aesthetic requirements forligation Ð as well as any inherent regularities. Once we have a design in place for interchanging ligatureswith marked up text, we can revisit that and see whether replacing markup instructions by charactercodes gives better results.

This is a waste of time. We already have a working model with VIRAMA, and ZERO-WIDTH LIGATOR is
analogous to that and its implementation would make the logic for font implementation for allthese scripts the same.
Both concepts (Ôligate hereÕ, ÔdonÕt ligate hereÕ) can in principle be expressed with HTML or XML stylemarkup Ð I have seen too little discussion of what this markup should be like, and what the consequences
are of it being present in the middle of words. Is that something that the HTML/XML community wants
to deal with?

Doing this would be just as ad-hoc as the current AAT/OpenType model is, for European scripts,
and all we are talking about is character-based glyph cell selection.
The strongest arguments in favor of character codes come from those who have for long time needed toÔtrickÕ various applications into supporting languages that they were not explicitly designed for. If
character codes would result in ÔenablingÕ many of these implementations, by letting the authorcommunicate with the rendering engine, so to speak, that is itself a valid argument to consider. (It would
need some actual case studies where this approach is shown to work).

I performed such ÒtricksÓ in order to prepare the present document.
Page 11

Still, even that would need to be contrasted with the cost to applications that do not know about these as
characters and end up showing ÔboxesÕ.

I could live with this in the short term. The long-term advantages to the designer and the user far
outweigh this minor inconvenience.

Gary Roberts said:¦

Yes. There is deÞnitely an issue of how to accomplish what one wants in a way that will be implemented.
For example, if the solution relies on language tags (e.g. dictionary based solutions), then it is of little use
if companies donÕt provide support for your language.

Which is, of course, unacceptable, given the number of the worldÕs languages.
On the other hand, the SOFT HYPHEN is generally implemented, and supports languages that havenÕt evenbeen invented yet. Now, one could argue whether SOFT HYPHEN is best implemented as markup or as the
addition of a new character. I tend to read and create markup Þles by hand. My tendency is to prefermarkup when there is some span to the markup. The more characters the markup is likely to aÀect, themore I prefer it to adding a character. SOFT HYPHEN is an example where there is no span at all, and it
makes sense to solve the issue with a SOFT HYPHEN character. I see ZERO-WIDTH LIGATOR as a substitute formarkup having a span of two or three characters, which still makes it attractive as a new character
solution. It also seems more ßexible.

Yes! As I said above, markup could substitute for ZERO-WIDTH JOINER and ZERO-WIDTH NON-JOINER justas ÒeasilyÓ. But it would be absurd to do so.
Say that I oÉen deal with fonts that have only ligature pairs, given the choice of Ði or fÞ, I always preferÐi, but my colleague prefers fÞ. We both prefer Ñ as a single ligature if it exists in the font. What markup
gives each of us the results we prefer? For &=ZERO-WIDTH LIGATOR, the answer is f&Þ for me, and À&i for mycolleague. Note that ZERO-WIDTH NON-LIGATOR is not useful for this case.

I agree, ZERO-WIDTH NON-LIGATOR is not useful here, but the solution is simple:
1. For an encoded sequence f&f&i, if <Á> exists, print it.
2. If <Á> does not exist, but <À> exists, print it and ignore the second &.
3. If <Á> and <À> do not exist, but <Þ> exists, print it and ignore the Þrst &.
4. If <Á> and <À> and <Þ> do not exist, ignore both &s.
5. If <Á> does not exist, but <À> and <Þ> exist, and the user prefers f<Þ> to <À>i, user
deletes the Þrst &.
Search engines that are not markup savvy (including my eyes) Þnd markup more disruptive than a single
character, particularly if it occurs frequently.
Search en-gines that are not mark-up sav-vy (in-clud-ing my eyes) Þnd mark-up more dis-rup-tive thana sin-gle char-act-er, par-tic-u-lar-ly if it occ-urs fre-quent-ly.
Search en<SH>gines that are not mark<SH>up sav<SH>vy (in<SH>clud<SH>ing my eyes) Þnd
mark<SH>up
more
dis<SH>rup<SH>tive
thanasin<SH>glechar<SH>act<SH>er,
par<SH>tic<SH>u<SH>lar<SH>ly if it occ<SH>urs fre<SH>quent<SH>ly.
Note that I have chosen relatively non-intrusive markup.

The arguments above show that we should not be using markup for ligation because thecharacter-sequence-to-glyph model is already there and should be preferred. But GaryÕs example
is good, especially in the ÒShow InvisiblesÓ option that good applications oÀer: suf&f&icient
would be friendlier than su<LIG>Á</LIG>cient in contexts where invisible characters andmarkup are displayed to the user.

Asmus Freytag said:¦
Page 12

The beauty of character codes as controlling agents lies in the fact that they directly interact with the ligating
engineÕs context processing. As has been pointed out on the Unicode list, f<ZWL>f is supported immediately,
as long as dumb fonts or unrelated processes can handle it as a zero-width character (ignorable).

Only in a situation which has a meta-markup turning on one (or more) levels of ligature class.
This mixes markup with coding for the same operation (glyph selection) and is not consistent
with VIRAMA/ZERO-WIDTH JOINER conventions.

Mark Davis said:¦

With ZERO-WIDTH LIGATOR, the font designer has to actively add all sequences of the form:
ÒfÓ + ZERO-WIDTH LIGATOR + ÒiÓ -> ÒÞÓ ligatureÒfÓ + ZERO-WIDTH LIGATOR + ÒfÓ -> ÒÀÓ ligature...
if those ligatures are to work with ZERO-WIDTH LIGATOR. There is no magic wand that tells the soÉware how
ZERO-WIDTH LIGATOR would work, otherwise.

Yes. The same principles we use for sequences of base and combining characters apply. For theuser, this could be handled by input, as it is (at least minimally) in XPress. For the designer, he or
she has to do this for all precomposed glyphs of combining characters anyway (at least forprecomposed characters which are post-normalization). WhatÕs the difference? ZERO-WIDTHLIGATOR makes the designerÕs job easier: he or she knows that certain coded-character sequences
will select the vectored glyphs; this is the best use of the smart font model.

Lloyd Anderson said:¦[Mark DavisÕ model above] is not the context I was envisaging at all. My understanding was that thoseconcerned with the Latin alphabet would have fonts containing ÒfÓ + ÒiÓ -> ÒÞÓ ligature (and so on), anda global ligature-on setting would cause these rendering glyphs to be used, while a global ligature-oÀ
setting would cause these rendering glyphs to not be used.

The problem is that the global ligature on/off model mixes markup with character coding.
There is no statement that I have seen made by Everson that would require throwing out such an
implementation.

It would be cleaner if Þ/ß ligatures were also encoded with ZERO-WIDTH LIGATOR. Users are now
presented in some (few) applications like XPress with an option to use these ligatures or not. ItÕshandled now by XPress by explicit ligature encoding, which will tempt many developers to kludge
a solution by coding ligature characters in the Private Use Zone. ThatÕs not what we want, is it?. It
interferes with options like spell-checking, sorting, and searching. Transferability of text could beseverely reduced as will be seen in the coding of Þ, ß, Ñ, and Ò in this PDF document in plain text,
which uses the usual Òsecond-fontÓ ligature kludge. No harm is done by teaching the user that, todo ligation properly, a ZERO-WIDTH LIGATOR is used. Users have learned to employ SOFT HYPHEN thisway already.
There would be three kinds of cases (at least), and in all three of them, ligature rendering glyphs would
be provided in the fonts.
A. Use of ligatures controlled by global settings, as the above example for Latin ÒÞÓ, as Devanagari, as
Arabic.
B. Blocking of ligatures in particular cases (using ZERO-WIDTH JOINER if cursive connections need to bepreserved)
C. Requiring ligatures in particular cases (for those, Old Hungarian and others which work similarly,
triples like X + ZERO-WIDTH LIGATOR + Y would be built into fonts when the fonts support such ligatures).

Page 13

Everson is of course quite correct that the majority case for quite a number of alphabets is non-ligatured.
Using Arabic or Devanagari or Latin ÒÞÓ examples simply does not address that situation, and is nocounterexample to it nor any argument against it. Latin, Arabic, Devanagari need one sort of support,
several alphabets named by Everson need another sort of support, and neither sort of support needs to
exclude the other.

I donÕt see how the VIRAMA/ZERO-WIDTH LIGATOR analogy doesnÕt solve this. Look at
Roman/Fraktur/Gaelic requirements (and indeed Turkic Latin requirements), which have quite
diverse ligation requirements; but the support required is the same as that for Brahmic. I contend
that Latin is no different from any other European script Ð the Gaelic, Fraktur, and Turkic
examples should show this. Latin ligation cannot be automated.
That is what I meant by saying there is no diÀerence, that the use of ZERO-WIDTH LIGATOR adds no newmechanism to the functioning of the system, it only adds a single code which is to be disregarded on somelevel in processes like sorting and (optionally) searching.

I would say Ò(optionally) in processes like sorting and searchingÓ. Cf. the discussion of bind-runes
above.

Peter Constable said:¦

I wouldnÕt necessarily expect each ligature to have its own (i.e. individual) style run. In general, itÕs more
likely that the font vendor has created the font to support varying levels of ligatures, and the user speciÞes
a particular level of ligation for an entire paragraph or larger run of text, possible the entire document.

The range of options, as shown in Greek and Gaelic above, may be too complex for the designer
to handle or predict. Better to leave the burden of ligature setting to the user, with automatic
insertion of ZERO-WIDTH LIGATOR in trivial instances like Latin f-ligatures (with user deletion or
special inputting settings for things like Turkic override of f- ligatures where necessary).
In other words, the burden on the font designer is exactly the same, save for a minor detail. Thus it seems
the implementations required to support ZERO-WIDTH LIGATOR vs. ZERO-WIDTH NON-LIGATOR should be fairly
comparable. Some comments have suggested otherwise,

I donÕt see a value in ZERO-WIDTH NON-LIGATOR. It requires a mix of levels and diÀers from the
Brahmic model for glyph-cell selection. ZERO-WIDTH LIGATOR is like VIRAMA: if present it selects aglyph cell; if absent, no such selection is made. It is analogous the combining character model Ð
if present, a precomposed glyph is selected; if such a glyph is not present, a base character and azero-width combining character is selected (with possible bad centring of the diacritic).
Marco Cimarosti said:
A non-historical example for the need to control ligatures in plain text has already been done: the ÒfiÓ ligature
in Turkish. In most roman fonts, the dot over ÒiÓ disappears in the ÒÞÓ ligature, because it merges with the ÒfÓÕs
top. This aesthetic adjustment is perfectly innocent in most languages, because the dot on ÒiÓ has no special
meaning (it is just an heritage from handwriting). In Turkish, however, dotless ÒiÓ is a separate letter so, in
certain fonts, the ligature loses the distinction between ÒfiÓ and ÒfõÓ.

IÕve suggested in an earlier message in this thread that ideally all runs of text should be tagged to indicate
their language.

Only a small subset of the worldÕs languages have been given taggable codes.
If this is done, then it would be possible for that information to be used by the rendering engine inshaping the text and for the font developer to specify that the ÒÞÓ ligature not be formed for Turkish butthat it be formed for other languages. (Current score, as I recall: OpenType already provides support forsuch language-speciÞc substitution; such support in not currently available in AAT but is being
considered.)Page 14

And how are the orthographic rules for all these languages to be accessed? Is there an
orthographic register? (There is not, and even if there were, as shown for Gaelic above, it mightinterfere with the accurate representation of historical texts. With ZERO-WIDTH LIGATOR, you donÕt
have this problem.) Up to 16 Turkic languages could make use of the Turkish fi convention
discussed here. What happens when a language (like Greek or Irish) can be written in many fontswith diÀerent ligation requirements or options? Ligatures like air (-) will only be present in someIrish fonts, but no one would complain if switching from ‡o¸-i¸e in a Watts font led to arepresentation of ao¸airi¸e in a Newman font, since Newman fonts never had such ligatures
traditionally anyway. Using ZERO-WIDTH LIGATOR to link character-sequences to glyph cells(ignoring the ZERO-WIDTH LIGATOR if no X-ZWL-Y triplet is available in the smart font) is by far andaway the simplest solution to this chronic problem.

Mark Davis said:¦

A font vendor, right now, can map the unassigned characters from 2060-2069, E0000-E0FFF to the empty
glyph. If we end up adding ZERO-WIDTH NON-LIGATOR and/or ZERO-WIDTH LIGATOR, then they will go in one ofthose positions. Rendering engines should (but may not) currently Þlter out all unassigned characters inthis range, since their eÀect on rendering cannot be predicted. But once ZERO-WIDTH NON-LIGATOR or ZEROWIDTH LIGATOR are approved and allocated, the rendering engine can pass them through to the font table
execution code. Once that is done, then ZERO-WIDTH NON-LIGATOR would work with no further action by the
font vendor. The vendor would have to add the extra ligature mappings to the font for ZERO-WIDTH LIGATOR
to work. ThatÕs why ZERO-WIDTH NON-LIGATOR is simpler to implement than ZERO-WIDTH LIGATOR.

How does this work for eagla/±gla? What about the Runic example given above? There are no
obligatory ligatures in Runic, so turning ligation on globally is obviously not a solution, and themodel you and Asmus Freytag have suggested wtih ZERO-WIDTH NON-LIGATOR is very impractical for
Runic, as it is for Latin-Gaelic or Latin-Fraktur. (Estonian Fraktur uses no ligatures. We could
exhaustively investigate Fraktur as used in Danish, Swedish, Norwegian, Latvian, Lithuanian,
Estonian, Finnish, and S‡mi, to try to come up with a hierarchy of language-speciÞc
instantiations of rules, but the X-ZWL-Y model is far simpler for the font designer and the end user,
and apart from possible input settings, is not dependent on further language-speciÞc table
implementations by programmers. Like SOFT HYPHEN, ZERO-WIDTH LIGATOR will support Òlanguages
that havenÕt even been invented yetÓ. This glyph-selection model is already the one implemented
for Brahmic conjuncts, Brahmic consonant + vowel-sign sequences, and Latin base-character +combining-character sequences.

Kent Karlsson said:¦

The typographic-aesthetic ligatures are not orthographically motivated [in Swedish], but typographicallymotivated: the (normal) glyphs overlap in an ugly manner, and if someone cares enough (especially forlarger sizes), a ligature is formed that looks better. In modern use (or its lack of modern use at present forthat matter) there is no orthographic implication whatsoever. Some maintain, apparently without
evidence, that these ligatures do have an orthographic signiÞcance at morpheme boundaries. However,some example ligatures, given in some (Swedish) typography books, are for letter combinations thatwould, for Swedish, only occur for compound words: fÖ and ffb, in incomplete example listings. In
addition, the second g in, e.g., ÒtuggummiÓ (chewing gum), which subword does that second g belong to?
Is it the last letter of ÒtuggÓ (chewing) or the Þrst letter of ÒgummiÓ (gum)? Here these two g-s have been
amalgamated into a single g. So what would be so horrible about doing a milder form of joining over a
subword boundary? In the books on typography that I have looked in, they happily provide someexamples of ligatures. There is no Òby the way, donÕt use them over subword boundariesÓ or similar side
remark.

Such rules are given for Fraktur German, as shown above.
Instead it is taken as obvious that if you want to use ligatures to make the glyph sequence a bit betterlooking, you are free to do so anywhere in a word. They are, aÉer all, only there for aesthetic reasons, andnot ligating is no better looking over a subword boundary than anywhere else.
Page 15

Then automatic insertion of ZERO-WIDTH LIGATOR in Swedish is always appropriate for certain letter
pairs and triplets. No problem.
3. There has been no agreed upon way of accessing [such ligatures].

This is part of the problem with markup.
So prior to the existence of AAT or OpenType fonts, it was hard and unsafe (for font changes) to use them,even if such non-English ligatures were present in a font.

ThatÕs why we propose ZERO-WIDTH LIGATOR Ð to make it agreed and safe and portable.
If a glyph sequence [É] has no overlapping glyphs, or the overlap looks ok anyway, no ligature should be
used, and if a ligature is used anyway it should look exactly like the unligated glyph sequence. Any
occurrences of preligated Latin characters from the FBxx block should be replaced by their compatibility
decomposition, or otherwise look exactly like if it were compatibility decomposed (though the caretmanagement will be diÀerent in the latter case). (An Þ ligature should look diÀerent from an f followed
by a dotless i. This is not an issue for Swedish per se, but may be for Turkish names, of persons or places,that are properly spelled in an otherwise Swedish text.)

So you delete ZERO-WIDTH LIGATOR for Turkish names. Simple! And expected for Turkish text.

John Jenkins said:¦

Michael would then be arguing that even though most writing styles for Latin donÕt require explicit
ligation control to be legible, some do. We need to add ZERO-WIDTH LIGATOR and ZERO-WIDTH NON-LIGATOR to
support those writing styles.

No, we just need ZERO-WIDTH LIGATOR, and its absence. And this should be generalized for all
typographic ligatures in Latin. Cost to the user? Minimal, since most current applications donÕt
deal with ligatures at all, and the most common f-ligatures could be handled with a simple allon/Turkic/all-off switch (which still would insert (or refrain from inserting) ZERO-WIDTH LIGATOR in
the requisite positions). Otherwise you maintain a mixed model for ligature production, which is
untidy and unnecessary.
Peter Constable said:
True, but I think the question still has some validity in the following way: In one scenario, a font designer has
to list all sequences of the form ÒfÓ + ÒiÓ -> ÒÞÓ ligature ÒfÓ + ÒfÓ -> ÒÀÓ ligature while in the other scenario thefont designer has to list all sequences of the form ÒfÓ + ZERO-WIDTH LIGATOR + ÒiÓ -> ÒÞÓ ligature ÒfÓ + ZERO-WIDTHLIGATOR + ÒfÓ -> ÒÀÓ ligature

Actually, the type designer would probably want to provide both sets of sequences for those cases wereligation control wasnÕt done by ZERO-WIDTH LIGATOR and ZERO-WIDTH NON-LIGATOR.

But it would be a lot simpler if it were done with ZERO-WIDTH LIGATOR for all languages in all
European scripts.
As an aside, on this I would absolutely insist Ð that ZERO-WIDTH LIGATOR and ZERO-WIDTH NON-LIGATOR be at
most an optional way of specifying ligation control in plain text, allowing for ligation control in higherlevel protocols without them. It would seriously undermine the technology that AppleÕs been selling forÞve years to make them obligatory.

I really hate to criticize Apple, but who has bought and implemented this technology? Only
Adobe? Even Apple doesnÕt have a text editor available that implements it!
In other words, the burden on the font designer is exactly the same, save for a minor detail. Thus it seems theimplementations required to support ZERO-WIDTH LIGATOR vs. ZERO-WIDTH NON-LIGATOR should be fairly
comparable. Some comments have suggested otherwise, however; for instance, I seem to recall John Jenkins
saying that implementing support for ZERO-WIDTH NON-LIGATOR in ATSUI would be fairly simple, but that hePage 16wasnÕt at all sure if or how support for ZERO-WIDTH LIGATOR could be added. Why should there be that muchdiÀerence?

The complication comes in trying to make sure that fonts without the ZERO-WIDTH LIGATOR version of thetables will work correctly. This will mean adding ZERO-WIDTH LIGATOR to the list of characters whose display
we (almost always) actively suppress Ð things like the directionality overrides are rarely mapped explicitly
to invisible glyphs in fonts, so we have to do this ourselves to make sure that black boxes donÕt litter thelandscape of text that uses them.

True.
The more diÁcult part is adding a step to parse the text for ZERO-WIDTH LIGATOR and, if it is present,
checking the font to see if a particular feature allows for the equivalent ligature to be formed if there is noZERO-WIDTH LIGATOR and overriding the userÕs collection of set features to include it.

True. That doesnÕt mean itÕs not the right thing to do. And itÕs not very different from what one
has to do with base-character and combining-character sequences.
This is similar to what we have to do in other situations. E.g., if a font doesnÕt have a Unicode cmap, we
make one and cache it, so that fonts will work ÒproperlyÓ even if they havenÕt explicitly been updated tosupport the new behavior. ZERO-WIDTH LIGATOR would require similar functionality on our part Ð old fonts
should continue to do the right thing without being formally updated to do so.

They donÕt do this now, as I say Ð a major user of my Armenian Utiltiies has just said that heÕsstarting to have problems with them on his new G4. I hope Apple can make tools available to help
me update my fonts Ð but I think updating, ZERO-WIDTH LIGATOR or not, is inevitable given the tools
we have at present.
To work, youÕd need to have:f + i --> Þ
f + SHY + i --> Þ(f + ZERO-WIDTH LIGATOR + i ) --> Þ(f + SHY + ZERO-WIDTH LIGATOR + i ) --> Þ(f + ZERO-WIDTH LIGATOR + SHY + i ) --> ÞAll explicitly in your list of potential ligatures in your font.

ThereÕs no harm in this, if itÕs really necessary. Font designers will welcome this, I should think.

Peter Constable said:¦

As we consider cost of implementations, I wonder just how many fonts there are in existence in each ofthese categories? I.e. whatÕs the cost impact on vendors and users in relation to existing fonts of use of
ZERO-WIDTH LIGATOR (or ZERO-WIDTH NON-LIGATOR) versus the cost of any other alternative? I suspect thecosts in relation to existing fonts that Mark refers to is not very high (but feel free to correct me if IÕm
wrong) on the assumption that the technologies required to make smart-font ligation work (AAT and OT)
havenÕt been around that long and/or have been utilised by only a very small number of applications.

I agree. Certainly even smart fonts and AppleÕs TEC remapping could break all currently available
cmap-less non-Roman font kludges until Apple makes editable TEC soÉware available to us. My
WorldScript resources are already starting to break with System 8.6 on the G4, and at present I can
do nothing about it to serve the users of my soÉware.

John Jenkins said:¦

Both AAT and OT allow for bitmap fonts that have all the smarts needed to render anything in Unicode
properly. The distinction isnÕt between stupid bitmap fonts and smart outline fonts, itÕs between stupid
fonts and smart fonts.
Page 17

Yes but there arenÕt very many smart fonts now (I canÕt make them), and as far as Òanything inUnicodeÓ is concerned, well, Unicode canÕt handle the requirements adequately without ZEROWIDTH JOINER as far as I can see. You can represent what is actually in Unicode, but this doesnÕt
support bind-runes according to the plain-text requirement, for example.
In practice, GX and AAT donÕt Þlter out any unassigned characters before doing the character-glyph
mapping, and I doubt that OT systems do, either. We could add them to the list of Unicode code points
whose Òempty boxÓ display is actively suppressed, but thatÕs a diÀerent matter Ð and weÕd rather not,because that could potentially interfere with the last resort font and font substitution (or whatever weÕre
calling it these days).

The Last Resort Font will have to be updated many times. Look at all the as-yet-unencoded scripts
in the Roadmap.
The real complication with ZERO-WIDTH LIGATOR is to update the rendering engine so that older fonts willcontinue to work ÒproperlyÓ without having to be updated. This is something weÕve been pushing reallyhard to do and weÕd want to continue to do it. Realistically, however, we might be forced simply to puntand say that ZERO-WIDTH LIGATOR would only work with fonts explicitly updated to support its use.

If thatÕs whatÕs required, than thatÕs what we should do.

Lloyd Anderson said:¦

I have always assumed that the technology which speciÞes a default (assuming the font supplies theglyphs), whether obligatory for Latin or not, would remain in place. (I assume this system does not choke
if a font does not contain particular ligature glyphs, it simply renders without ligatures at that point...?)The use of ZERO-WIDTH LIGATOR and ZERO-WIDTH NON-LIGATOR, just like the use of ZERO-WIDTH JOINER and ZEROWIDTH NON-JOINER (at least in most instances) would be special overrides, the second for overriding
obligatory ligatures (which could be used in Latin, of course), [though I think ZERO-WIDTH JOINER would do
for the ZERO-WIDTH NON-LIGATOR uses? if not, why not, perhaps I missed something earlier...]I think I have dealt with this above.
Tables of triples X + ZERO-WIDTH LIGATOR + Y would be needed only for [scripts like Old Hungarian Runes,
Germanic Runes, etc.], they would not be needed for Latin, and would not appear in Latin fonts? At least
not for ligatures which were included in the obligatory set.

I disagree. What is the ÒobligatoryÓ set? What about Turkic?
I hesitate to speculate (given my limited knowledge) further concerning any, to me still hypothetical,
need for ZERO-WIDTH LIGATOR for Latin. Though I can conceive that there might be a split between
normally-obligatory ones and optional ones, that still could be handled as for Arabic script, by having
global settings to include none/only obligatory/obligatory + preferred/all (or whatever the details of thecurrent implementation are).

There are too many potential options to make this an attractive solution. ZERO-WIDTH LIGATOR is
simpler.

John Fiscella said:¦

A method of ligature control has been suggested using ZERO-WIDTH LIGATOR and which would require asmart font to intervene in order to exercise complete ligature control. While I am not opposed to theintroduction of the ZERO-WIDTH LIGATOR (even enthusiastic that they would be available), as a font architect
and font designer, I feel that we mixing apples and oranges if we require the ZERO-WIDTH LIGATOR to only
be usable through a smart font mechanism; because it is inconsistent with present complex script
rendering conventions.
Page 18

I have tried to show that European script requirements are complex with regard to ligation, evenfor the most common Latin ligatures (since Þ is proscribed in Turkic, and since fi doesnÕt exist as
a ligature in Gaelic).
It should be a rendering engine which substitutes an Þ ligature from f + ZERO-WIDTH LIGATOR + i. Ideally,
ligatures in Latin script should be handled in the same manner as ligatures in Arabic script (for example).

I disagree, because Arabic shaping behaviour is truly obligatory, and ligatures in Latin are notuniversally obligatory. The Brahmic model is more applicable to the full range of requirements.
If they canÕt be, then the conventions/implementation of the rendering engine/model may need to beÞxed. Of course, the real problems are that in Latin: 1) most ligatures are discretionary (this could,
depending on the stylized design of the font, potentially occur for every glyph pair to be rendered);
and/or 2) ligature substitution is layout-dependent.

Consistent use of ZERO-WIDTH LIGATOR should Þx this problem.
If a rendering engine is built into an operating system to handle these services, then it also must be
layout-aware to cover all ligature cases in all scripts. Somehow, the implementations currently available
in some operating systems (either through op system versions or through Òlanguage kitsÓ) only go halfway. Applications, however, can take over and supply the missing functions (for example substituting Þ
for f + ZERO-WIDTH LIGATOR + i), provided that a mechanism exists for calling up the Þ glyph from the font.
This is easily done if a glyph is encoded.

Yes, but do we want to encode 130 Old Hungarian ligatures? Or ~50 Gaelic Latin ligatures?
It seems like the only clean way to do it is to encode a complete set of Latin ligatures (1,482 would do)

I am sure you have not counted Gaelic ligatures, which are not just pairs, but sometimes triplets.
in Unicode (not relying on the character/glyph model for Latin ligatures). If this were done:
1) application developers could install any type of ligature management, limited only by their
imagination and language requirements (or, more preferably, a script could be supplied to do this by
the user and read by the application);
2) consistency would be maintained with other script rendering mechanisms, some of which are inplace today;3) glyph-naming dilemmas would be eliminated;
4) it could be made backward-compatible with many existing legacy fonts.

I hope so. Certainly the end user needs to be the one with ultimate control over text representation.
The diÁculties of using the character/glyph model in cases where layout is an inßuencing factor has been
discussed frequently and are obvious to an application developer. Conversely, implementation of thecharacter/glyph model is no problem at the font level for reencodable dumb fonts.
To summarize:
Consistent Latin script ligature management can be easily implemented if1) the ZERO-WIDTH LIGATOR is implemented; and2) two sacred cows are abandoned (no more ligature encoding in Unicode and relaxation of thecharacter/glyph model for the case of non-complex script ligatures).

I donÕt think further encoding of explicit ligatures in the UCS is really necessary. The charactersequence glyph-selection mechanism employing ZERO-WIDTH LIGATOR should make the pointmoot.
14. Ligatures in Arabic. I am not arguing strenuously on this point, but one possible additionaluse of ZERO-WIDTH LIGATOR could be to assist in Arabic ligature selection. This is not the same thingas Arabic shaping behaviour. So, given Ç + Ç + Ç = ô, it might be possible to use ZERO-WIDTHLIGATOR to select true ligatures, so: Ç + ZWL + Ç + ZWL + Ç = ö; Ç + ZWL + Ç + Ç = õ. The Arabic model
may not require this, however. FINIT.
Page 19