Re: ZWL, ZWNL no difference?

Date: Thu Dec 30 1999 - 13:20:48 EST

       (I'm just posting to Unicode list since it's of general

       From: <> AT Internet on 12/30/99 10:24 AM

       Received on: 12/30/99

       To: Peter Constable/IntlAdmin/WCT, <> AT
       Subject: Re: ZWL, ZWNL no difference?

       on 12/30/99 12:42 AM, at

> True, but I think the question still has some validity in the
> following way: In one scenario, a font designer has to list
> sequences of the form
> "f" + "i" -> "fi" ligature
> "f" + "f" -> "ff" ligature
> while in the other scenario the font designer has to list all
> sequences of the form
> "f" + ZWL + "i" -> "fi" ligature
> "f" + ZWL + "f" -> "ff" ligature

       Actually, the type designer would probably want to provide both
       sets of sequences for those cases were ligation control wasn't
       done by ZWL and ZWNL.

       As an aside, on this I would absolutely insist -- that ZWL and
       ZWNL be at most an *optional* way of specifying ligation
       control in plain text, allowing for ligation control in
       higher-level protocols without them. It would seriously
       undermine the technology that Apple's been selling for five
       years to make them obligatory.

> In other words, the burden on the font designer is exactly
> same, save for a minor detail. Thus it seems the
> implementations required to support ZWL vs. ZWNL should be
> fairly comparable. Some comments have suggested otherwise,
> however; for instance, I seem to recall John Jenkins saying
> that implementing support for ZWNL in ATSUI would be fairly
> simple, but that he wasn't at all sure if or how support for
> ZWL could be added. Why should there be that much difference?

       The complication comes in trying to make sure that fonts
       *without* the ZWL version of the tables will work correctly.
       This will mean adding ZWL 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 the landscape of text
       that uses them.

       The more difficult part is adding a step to parse the text for
       ZWL 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 no ZWL and overriding the user's collection
       of set features to include it.

       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 to support the new behavior.
       ZWL would require similar functionality on our part -- old
       fonts should continue to do the right thing without being
       formally updated to do so.

       John H. Jenkins

This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:57 EDT