JS> There are many other writing systems and scripts for which there's
JS> NO 'legacy' encoding defined in and outside X11.
We're aware of that (Tifinagh is the example I like to give). The
point Keith was making (if I understood him correctly) was that core X
fonts should only be used for glyphs covered by legacy encodings. For
new glyphs, client-side fonts (Xft or otherwise) should be used
instead.
Of course, this is only reasonable if you believe (as I, for one,
certainly do) that RENDER is being deployed fast enough to make
exclusive use of client-side fonts a reasonable approach in the
foreseeable future. Someone at Sun may want to comment.
JS> It's 'ksc5601.1992-3' with *almost* the same (but not as complete
JS> as) coverage of *modern* Korean Hangul as iso10646-1. The encoding
JS> file for this
Patch 4912, if anyone is interested. Note, however, that Xlib does
not currently know how to effectively use fonts with this encoding.
JS> along with a patch to the encoding file for ksc5601.1987-0
Patch 4910, which fixes a bug I am guilty for. Note that the problem
is *not* user-visible, due to the seventh generation autonomously
intelligent self-correcting design of the fontenc layer. The fix just
saves a few microseconds the very first time a ksc5601 scalable font
is used (as well as a couple hundred KB of storage, but what's a
little disk space between friends).
Both patches are due to Jungshik, to whom I am very grateful.
Juliusz
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
