(I'm just posting to Unicode list since it's of general
From: <email@example.com> AT Internet on 12/30/99 10:24 AM
Received on: 12/30/99
To: Peter Constable/IntlAdmin/WCT, <firstname.lastname@example.org> AT
Subject: Re: ZWL, ZWNL no difference?
on 12/30/99 12:42 AM, email@example.com 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