on 12/30/99 7:30 AM, Mark E. Davis at markdavis@ispchannel.com wrote:
>
> 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.
>
In practice, GX and AAT don't filter out any unassigned characters before
doing the character-glyph mapping, and I doubt that OT systems do, either.
We *could* add them to the list of Unicode code points whose "empty box"
display is actively suppressed, but that's a different matter -- and we'd
rather not, because that could potentially interfere with the last resort
font and font substitution (or whatever we're calling it these days).
The *real* complication with ZWL is to update the rendering engine so that
older fonts will continue to work "properly" without having to be updated.
This is something we've been pushing really hard to do and we'd want to
continue to do it. Realistically, however, we might be forced simply to
punt and say that ZWL would only work with fonts explicitly updated to
support its use.
=====
John H. Jenkins
jenkins@apple.com
tseng@blueneptune.com
http://www.blueneptune.com/~tseng
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:57 EDT