Re: ZWL, ZWNL no difference?

Date: Thu Dec 30 1999 - 10:50:57 EST

       MD>That's why ZWNL is simpler to implement than ZWL.

       I understand: you were talking about a difference in terms of
       changes to existing fonts and software.

       MD>Of course, this is only the font support. Every other
       process: searching, sorting, etc. needs to be modified. Note
       that with these simple characters there is no way to
       distinguish the few semantic ligatures (that actually should
       not be ignored) from the bulk of the decorative ligatures
       (which must be ignored), unless one uses markup or adds yet
       more characters!

       The semantic/non-semantic distinction seems to be pretty
       significant. One option is to say that a ZWL is used *only* for
       semantic ligatures, but that other ligatures are controlled
       using out-of-band style information. So a font might contain

       "s" + ZWL + "t" -> "st" ligature
       "s" + "t" -> "st" ligature

       with the former always applicable but with the latter only
       applying if certain font features are enabled. In this
       scenario, processes like spell checking would not ignore ZWL.
       But, this has potential to end up in an ugly mess given no way
       to control users from forcing ligation using ZWL in cases of
       aesthetic, non-semantic ligation, with the result that spell
       checks, etc. don't work as they're supposed to.

       Given that you've clarified, Mark, what differences between use
       of ZWL and ZWNL you had in mind, it seems to me there is still
       a open question along the lines that Lloyd was meaning: Why is
       there any difference between ZWL and ZWNL in terms of what
       mechanisms in software are needed or in how complicated the
       mechanisms are?

       On 1999-12-27, John Jenkins wrote:

>There are two issues here. One is getting system software
       support. The other is getting applications to take advantage
       of the system software support. The latter can be an enormous
       uphill battle, as our experience getting people to support
       ATSUI shows.

>The former is also enormously problematical. The problem is
       that the TrueType spec doesn't offer 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 difficult to get it to handle ZWL; ZWNL would be
       comparatively simple. I would imagine that OpenType would have
       similar problems. Basically ZWL would be useless except for a
       plain-text exchange mechanism, and even there it would be

       As Lloyd observed, it seems that *both* ligation via ZWL and
       ZWNL can be implemented using existing rendering mechanisms
       (some changes may still be needed for other processes).



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