>Well, I am not saying that it would be easy, or that it would be worth
>doing, but would it really take *millions* of dollars for implementing
>Unicode on DOS or Windows 3.1?
Win95 could perhaps be looked at as a revision of Win3.x that provides
partial support for Unicode.
>> Pre-composed Latin characters in the PUA don't require
>> any special rendering support, they'd be rendered the same
>> as any precomposed BMP Latin character.
>
>I thought that the PUA was being considered here as a place to put the
extra
>*glyphs* needed internally by a rendering engine -- not as a direct mean
of
>encoding text.
>
>In the case of PUA being used as a repository of extra glyphs, special
>rendering support is indeed required: which is, the part of the rendering
>engine that maps sequences of base letter + diacritics to the precomposed
>PUA code points.
Why would you encode presentation form glyphs in the PUA if you don't
expect them to be encoded directly in documents. "Smart font" rendering
systems map character codes into glyph ids, and so these glyphs don't need
to be encoded in the cmap. If you *do* encode them in the PUA, you had
better count on people encoding those presentation forms directly in their
documents.
>Does this mean that TrueType fonts for Windows NT would be capable of
>breaking the 64-KB barrier and support a whole Unicode font which also
>support extended planes? Really TrueType or OpenType?
OT and TT fonts have a limit of 64K glyphs. Either OT or TT fonts can
support cmaps that use 32-bit character values, but the only OS on which
this is currently supported is Win2K. It would be possible for an app to
read the cmap directly and then draw text in terms of glyph IDs on
Win9x/Me/NT4 if desired or needed, however.
- Peter
---------------------------------------------------------------------------
Peter Constable
Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
E-mail: <[EMAIL PROTECTED]>
