Hi

I think your proposal is a propose of "localized font name"
(like Microsoft Windows fontmenu, or classic QuickDraw based
fontmenu on MacOS) or "localized sample text" (like recent
fontpanel on MacOS X). If I'm misunderstanding, please correct.

There are a few problem:

1) font name in font file is localized? internationalized?
----------------------------------------------------------
>For example, many CJK fonts will have TTF names in East Asian
>languages (i.e., Chinese, Japanese, or Korean) stored in the
>font file itself.

This is correct for commercial fonts, but incorrect for free
font. Most CJK free font developers don't assume as the font
handler is capable to handle non-ASCII font name, and often
use US-ASCII font name or UTF16-ed ASCII font name. For example,
Japanese free TTF, Sazanami Gothic and Sazanami Mincho has
their name in ASCII.

[NOTE]
BTW, I'm afraid that Mac OS X changes the script to display
fontname by language environment. Traditional QuickDraw system
uses localized fontname always, but ATSUI does not. See

	http://www.gyve.org/~mpsuzuki/ats_benchmark.html


2) a font object knows its best script?
---------------------------------------
This is accurate for commercial fonts designed for Microsoft
Windows, MacOS, and traditional X window system, but inaccurate
for recent Unicode-oriented desktop environment for Linux,
Solaris, AIX etc. In such systems, to avoid from handling
various font files for various scripts, there is a tendency
to push everything into single font file. Unfortunately, the
separation of the script and UCS-2 codepoint separation is
badly-designed. Parsing traditional TTF header (OS/2 etc)
is not sufficient to detect the best script of a given UCS-2
font. I think, the scripts which requires special OpenType
layout features (like South Asian and African scripts) won't
be merged in near future, because development is ongoing,
but the unification tendency is clear for CJK scripts.

If a given font insists as "I have all character for UCS-2
codepoint", how proposed fontmenu displays it?

[NOTE]
The glyph shape for Hanzi is dependent on Simpl. C, Trad.C, J
and K, in reality (you can find OpenType categorizes all Hanzi
into single "hani" script class, but divide it into sub-categories
by language class: JAN, KOR, ZHS, ZHT). In the other words,
OpenType thinks traditional TTF mechanism is insufficient to
specify the best script, and introduced new mechanism.

3) menu for fontset?
--------------------
Microsoft Windows and Mac OS X have a feature to lap over
multiple TTFs. The font menu of Microsoft Windows don't have
menu to control that, but fontpanel of Mac OS X provide to
edit "font collection". How do you think about the requirement
of such features?

4) heaviness
------------
I think proposed fontmenu must access all font contents to
render its fontname. I suppose both of Microsoft Windows and
MacOS/Mac OS X uses kernel space font cache maximumly, but
how about UNIX platforms? Thinking about the situation using
xfs at remote server, scanning all font contents can be heavy
work and users may be forced to wait. There's any proposal
about that?

Regards,
mpsuzuki



P.S.
>    http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/

BTW, proposal of a few terminology fixes of your hard-worked web page.

> and the second is in the "Guo Biao" encoding...

"Guo Biao" means just National Standard. Possibly you don't
want to call ISO-10646 as "ISO encoding" :-). The encoding
should be noted as GB-2312, GB-18030, etc. In fact, legacy
PC encoding of TrueType fonts designed for Chinese script on
Microsoft platform was based on GB-2312.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<