Re: ZWL, ZWNL no difference?

From: Mark E. Davis (markdavis@ispchannel.com)
Date: Thu Dec 30 1999 - 10:35:28 EST


I have not made myself sufficiently clear. Let me try again.

A. If we have an existing font, with existing ligature glyph mappings,
then
- changing the font for ZWNL support means mapping it to the empty glyph.
- changing the font for ZWL support means mapping it to the empty glyph,
plus adding all the new triple ligature mappings.

B. If we have an existing font, without existing ligature glyph mappings,
then
- changing the font for ZWNL support means mapping it to the empty glyph.
- changing the font for ZWL support means mapping it to the empty glyph,
plus adding all the new triple ligature mappings.

C. If we have a font with multiple levels of ligature glyph mapping
support, e.g.

level0 : no ligatures
level1 : f,f => ff-lig; f,i => fi-lig;
level2 : f,f => ff-lig; f,i => fi-lig; c,t => ct-lig; s,t => st-lig;

- changing the font for ZWNL support means mapping it to the empty glyph.
- changing the font for ZWL support means mapping it to the empty glyph,
plus adding all the new triple ligature mappings to every level, e.g.
ending up with:

level0 : f,ZWL,f => ff-lig; f,ZWL,i => fi-lig; c,ZWL,t => ct-lig; s,ZWL,t
=> st-lig
level1 : f,f => ff-lig; f,i => fi-lig; f,ZWL,f => ff-lig; f,ZWL,i =>
fi-lig; c,ZWL,t => ct-lig; s,ZWL,t => st-lig
level2 : f,f => ff-lig; f,i => fi-lig; c,t => ct-lig; s,t => st-lig;
f,ZWL,f => ff-lig; f,ZWL,i => fi-lig; c,ZWL,t => ct-lig; s,ZWL,t => st-lig

Note that in practice, different levels may not be simple supersets of one
another, so it would take a little judgment to determine the exact set to
add to each level. For example, there may be an ff-lig1glyph plus an
ff-lig2 glyph, one being more florid.

A font vendor, right now, can map the unassigned characters from
2060-2069, E0000-E0FFF to the empty glyph. If we end up adding ZWNL and/or
ZWL, then they will go in one of those positions. Rendering engines should
(but may not) currently filter out all unassigned characters in this
range, since their effect on rendering cannot be predicted. But once ZWNL
or ZWL are approved and allocated, the rendering engine can pass them
through to the font table execution code. Once that is done, then ZWNL
would work with no further action by the font vendor. The vendor would
have to add the extra ligature mappings to the font for ZWL to work.

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

----

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!

As to the markup issue: processes that handle inline markup already need to take into account the fact that markup may intersect semantic boundaries when processing; that is "<span style="color:red">Wach</span>stube" should still count as one word for spell-checking, etc. even though the first 4 words are red. Of course in practice, most programs convert inline markup into out-of-band styles for internal processing, since it is otherwise extremely painful to process. Once the markup is converted to out-of-band styles, then this is not a problem.

Mark

peter_constable@sil.org wrote:

> >What is the difference [between the use of ZWL and of ZWNL]? > > MD>With ZWL, the font designer has to actively add *all* > sequences of the > form: > > "f" + ZWL + "i" -> "fi" ligature > "f" + ZWL + "f" -> "ff" ligature > ... > if those ligatures are to work with ZWL. There is no magic wand > that tells the software how ZWL would work, otherwise. > > 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" -> "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 > > 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 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? > > Peter



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