Jungshik Shin writes: > On Sat, 2 Aug 2003, Chisato Yamauchi wrote: > > > Although the pliability of handling such special fonts is also important, > > non BMP plane in XLFD is now the most important problem. Confusion is > > already seen such as linux-utf8 list. An official definition should be > > indicated right now. Why has XFree86 left this? > > That's because XFree86 is moving away from 15year-old XLFD-based > approach. As Owen wrote, we'd better let that poor thing rest in peace > and move along. With fontconfig/Xft, we don't need to worry about XLFD > any more except for the sake of backward compatibility. For non-BMP > characters, there isn't much issue with back. comp. to worry about. > > If you take a look at Mozilla's gfx/src/gtk/nsFontMetricsGTK.cpp > and gfx/src/gtk/nsFontMetricsXft.cpp > (or gfx/src/windows/nsFontMetricsWin.cpp) at > <http://lxr.mozilla.org/seamonkey>, you'll know what I mean. > Mozilla developers have put tremendous amount of 'heroic' efforts to make > CSS-style font selection work with XLFD-based font names. However, > a much simpler and shorter fontconfig based code(in > nsFontMetricsXft.cpp) works better that nsFontMetricsGTK.cpp (for XLFD-based > font names). > > Adding yet another field to make XLFD more complex doesn't help a bit > in this respect. Besides, in your example (GT fonts), I don't see why > you need to extend XLFD. Couldn't you just use different numbers in > the last field of XLFD? > > > gt200001.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.1 > > gt200002.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.2 > > gt200003.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.3 > > Instead of the above, the following should work as well, shouldn't it? > Am I missing something? > > > gt200001.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-1 > > gt200002.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-2 > > gt200003.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-3 > > > > Why do we persist in X-TT? The reason is that "libfreetype.a" > > does not useful at all in CJK. Especially the following two points are fatal. > > Well, X-TT's 'competitor' is not freetype module, but fontconfig > (+FT2 + Xft) > > > - Handling a proportional multi-bytes fonts is too slow. > > (The loading speed of libfreetype.a is 20 times slower than > > that of X-TT 1.4; I show a benchmark in next email.) > > > For the "with TTCap option" case, the option has been set to > > "fc=0x3400-0xe7ff:fm=0x5a00". This particular option setting > > indicates that "xtt" handles the glyphs that are within the CJK > > region (in unicode) with constant spacing, whose metrics are > > similar to that of "0x5a00". > > This is a nifty idea that can be utilized in Freetype2 and/or > fontconfig, but it seems to me that the fact that there's that much difference > in the perf. between two cases is yet another indication that > X11 core fonts have to go away. >
X11 core fonts need to stay for legacy applications and these applications have to retain their present functionality. Saying 'core fonts need to go way' is equivalent to saying 'lets change the core protocol'. That's out of the question. If a well understood modification to core font handling gives you a speed improvement for its present functionality it appears to be a valid enhancement. Egbert. _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
