>It scares me whenever someone proposes that proprietary font mechanisms
>should be necessary to render Unicode correctly. Marco Cimarosti
>expressed the same concern earlier. No matter how "open" OpenType,
>TrueType, AAT, ATSUI, etc. are or claim to be, there *must* be a way to
>render Unicode characters correctly without relying on them. I don't
>even know what a GSUB or a GPOS is, and as a Unicode user and
>implementor (but not a font designer) I shouldn't have to.

These font technologies are just supposed to work, without the user needing
to know any differently. But, if the user *does* know the difference, then
they also hold the potential for some advanced capabilities, such as
discretionary ligation. Now there are two caveats to making these fonts
just work:

- There must be application support (on Mac OS, apps must be written to the
appropriate interfaces; on Windows, Uniscribe is now provided using the
standard interfaces, but Uniscribe limits you to only those capabilities
that have been programmed into Uniscribe).

- Some other infrastructure pieces are needed to make the picture complete,
specifically tagging runs of text to indicate language and/or writing
system, and the app pass that info on to the font/rendering system. This is
so that fonts will apply writing system-specific behaviours without user
intervention; e.g. not doing fi ligation be default for Turkish, and
picking alternate italic forms in Cyrillic for certain languages.