Design of Common Ligatures

Thank you for your reply.

At first, as I read through your post, I thought that you had used the MUFI recommendations in your font.

However, at the end you wrote “To answer one of your questions, no I didn’t use the same cells for many of these, except for the few called out at the FB block, at the top here, which you already mentioned.”, so it appears that you used some other codepoint allocations? Is that correct?

I have been thinking about these new MUFI recommendations in relation to my golden ligatures collections. MUFI has a different codepoint for a ct ligature. With long s ligatures, the golden ligatures collection has some which are in MUFI and some which are not in MUFI, and MUFI has some which golden ligatures does not have.

For example, the golden ligatures collection has a long s k ligature at U+E754, whereas, as far as I have found at present, MUFI does not have that ligature.

I am hoping to produce a version of my Chronicle Text font with those Private Use Area ligature glyphs and some others from the font that are included in MUFI also mapped to the MUFI recommendations. Also I am hoping to add into the font a few of the ligature glyphs which MUFI has which the golden ligatures collection does not have. As well as ligatures there are also a few other items to double map, such as the precomposed glyphs for M macron, m macron, N macron and n macron and some other ligatures such as pp.

I have come to the conclusion that a central issue is that, as at the present time, with OpenType support not in wide use, that entering transcripts using Private Use Area precomposed glyphs is a good idea, yet that a method is needed so that, in the future, transcriptions to regular Unicode can be made, preferably by an automated method.

There are issues such as how one would decompose a ct ligature. For example, is it as ct or is it as c ZWJ t because one did have a ligature in the first place?

I have been wondering whether those people who are interested could devise a coding, maybe in XML format, maybe in some other format, such that the meaning of Private Use Area ligature glyphs could be added into the font in the Description section of font, so that in the future the font file could, in principle, be accessed by a special purpose application program which could extract that information and use it for such purposes as producing an OpenType version of the font and for decomposing into regular Unicode any text which had been keyed using the font. For example, a text file containing a U+E707 character which had been keyed using my Chronicle Text font could be decomposed automatically by using information from the Description section of the font that U+E707 represents a ct ligature in that font. The coding would allow a default statement with a meaning such as “all Private Use Area encodings not specifically mentioned in the above list are those in the MUFI version 2.0 documentation” so that descriptions need not be included in each font. Thus if someone includes a ligature glyph not in MUFI version 2.0 in a font, the font could have the decomposition information available within the font in a format which some future automated system could understand. The coding system used would best be published and deposited somewhere.

Have you noticed the hypothetical ligatures which are in the Chronicle Text font? These are mapped to U+E716 to U+E71B. These are bi, di, hi, pi, pl, vi respectively.

William Overington

29 April 2007