On Wed, 2005-09-28 at 11:01 +0900, mpsuzuki hiroshima-u ac jp wrote: > 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? An ASCII name is (almost) always present; localized names are more often present in commercial fonts. Fontconfig tags each name with the language and territory so you can search for an appropriate name even if the font provides multiple localized names (which TTF does support). > 2) a font object knows its best script? Fontconfig automatically detects language support by measuring coverage against an approximate orthography for the language. This means that even incorrect OS/2 tables will not accidentally mark a font as supporting additional languages. Fontconfig does use the OS/2 table to disambiguate among hanzi languages -- a font covering all of GB18030 but which does not include Japanese in the OS/2 code page range bits is not marked as supporting Japanese, even though GB18030 includes all of the codepoints needed for Japanese support. This does rely on the fonts not setting code page range bits for the wrong language; so far, that's been reasonably successful. > 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? Fontconfig also has this support, and Qt and Pango both avail themselves of it. Unlike Windows or Mac OS X, it is entirely automatic so that fontsets are constructed from available fonts to provide as complete a coverage as the available fonts can provide. > 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? Client side fonts are quite efficient in this regard, rendering and caching only glyphs which are actually used. This permits efficient use of the actual font for the font menu. It's not as fast as using a single font for all menu entries, but the benefit to the user is probably worth the cost in most environments. -keith
Attachment:
signature.asc
Description: This is a digitally signed message part