Re: [Fonts] After-XTT's extension of the encoding field.
OK, so you are not selecting different ranges but different files? Is it a standard procedure to distribute one font accross several files or was the single file just split into separate ones just to avoid blowing up the XFontStruct? GT fonts is a quite special fonts. The code ranges of all files follow that of jisx0208. There is Konjakumojikyo fonts which inclues over 10 glyphs in Japan. Although I have not tried it yet, it seems that it also use the existing code set and all glyphs are divided into many files. 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? Two further issues: 1. would it be possible to convert xtt to use freetype2 instead of freetype1? This would allow us to remove the freetype1 sources from the tree. 2. it is planned to extend the freetype module to meet all core font requirements, also is planned to convert all bitmapped fonts to bitmapped truetype fonts. This would to some extend collide with the xtt renderer: whichever renderer is loaded first would be chosen to render all available formats it can handle. Which features does xtt offer which the freetype module is lacking of? I also think that it is not good that many font backends exist. 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. - 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.) - The modification of a font(such as auto italic and double striking, etc.) cannot be used at all. That is, libfreetype.a should also have all options of TTCap. Have you seen CJK's *TYPICAL* fonts.dir of TrueType fonts? It is following: kochi-mincho.ttf -kochi-kochi mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0 ds=m:kochi-mincho.ttf -kochi-kochi mincho-bold-r-normal--0-0-0-0-c-0-jisx0208.1983-0 eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi mincho-medium-i-normal--0-0-0-0-c-0-jisx0208.1983-0 ds=m:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi mincho-bold-i-normal--0-0-0-0-c-0-jisx0208.1983-0 bw=0.5:kochi-mincho.ttf -kochi-kochi mincho-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0 bw=0.5:ds=m:kochi-mincho.ttf -kochi-kochi mincho-bold-r-normal--0-0-0-0-c-0-jisx0201.1976-0 bw=0.5:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi mincho-medium-i-normal--0-0-0-0-c-0-jisx0201.1976-0 bw=0.5:ds=m:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi mincho-bold-i-normal--0-0-0-0-c-0-jisx0201.1976-0 bw=0.5:kochi-mincho.ttf -kochi-kochi mincho-medium-r-normal--0-0-0-0-c-0-iso8859-1 bw=0.5:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi mincho-medium-i-normal--0-0-0-0-c-0-iso8859-1 bw=0.5:ds=m:kochi-mincho.ttf -kochi-kochi mincho-bold-r-normal--0-0-0-0-c-0-iso8859-1 bw=0.5:ds=m:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi mincho-bold-i-normal--0-0-0-0-c-0-iso8859-1 fc=0x3400-0xe7ff:vl=y:kochi-mincho.ttf -kochi-kochi mincho-medium-r-normal--0-0-0-0-p-0-iso10646-1 fc=0x3400-0xe7ff:vl=y:ds=m:kochi-mincho.ttf -kochi-kochi mincho-bold-r-normal--0-0-0-0-p-0-iso10646-1 fc=0x3400-0xe7ff:vl=y:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi mincho-medium-i-normal--0-0-0-0-p-0-iso10646-1 fc=0x3400-0xe7ff:vl=y:ds=m:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi mincho-bold-i-normal--0-0-0-0-p-0-iso10646-1 fs=c:kochi-mincho.ttf -kochi-kochi pmincho-medium-r-normal--0-0-0-0-p-0-jisx0208.1983-0 fs=c:ds=mb:kochi-mincho.ttf -kochi-kochi pmincho-bold-r-normal--0-0-0-0-p-0-jisx0208.1983-0 fs=c:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi pmincho-medium-i-normal--0-0-0-0-p-0-jisx0208.1983-0 fs=c:ds=mb:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi pmincho-bold-i-normal--0-0-0-0-p-0-jisx0208.1983-0 fs=c:bw=0.5:kochi-mincho.ttf -kochi-kochi pmincho-medium-r-normal--0-0-0-0-p-0-jisx0201.1976-0 fs=c:bw=0.5:ds=mb:kochi-mincho.ttf -kochi-kochi pmincho-bold-r-normal--0-0-0-0-p-0-jisx0201.1976-0 fs=c:bw=0.5:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi pmincho-medium-i-normal--0-0-0-0-p-0-jisx0201.1976-0 fs=c:bw=0.5:ds=mb:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi pmincho-bold-i-normal--0-0-0-0-p-0-jisx0201.1976-0 fs=c:bw=0.5:kochi-mincho.ttf -kochi-kochi pmincho-medium-r-normal--0-0-0-0-p-0-iso8859-1 fs=c:bw=0.5:ds=mb:kochi-mincho.ttf -kochi-kochi pmincho-bold-r-normal--0-0-0-0-p-0-iso8859-1 fs=c:bw=0.5:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi pmincho-medium-i-normal--0-0-0-0-p-0-iso8859-1 fs=c:bw=0.5:ds=mb:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi pmincho-bold-i-normal--0-0-0-0-p-0-iso8859-1 hi=y:fc=0x3400-0xe7ff:vl=y:kochi-mincho.ttf -kochi-kochi pmincho-medium-r-normal--0-0-0-0-p-0-iso10646-1 hi=y:fc=0x3400-0xe7ff:vl=y:ds=mb:kochi-mincho.ttf -kochi-kochi pmincho-bold-r-normal--0-0-0-0-p-0-iso10646-1
Re: [Fonts] After-XTT's extension of the encoding field.
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? gt21.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.1 gt22.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.2 gt23.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? gt21.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-1 gt22.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-2 gt23.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. - The modification of a font(such as auto italic and double striking, etc.) cannot be used at all. That is, libfreetype.a should also have all options of TTCap. Yeah, TTCap is useful, but it appears that we're trying to solve the wrong problem turning away from the real issue. The real problem is that we don't have quality CJK fonts in multiple styles. Anyway, fontconfig offers 'artificial slanting' although it doesn't make much sense to have 'italic' or 'slant' typefaces for CJK. As for 'artificial bold', there's a patch somewhere, but hasn't been accepted because Freetype2 reportedly will come up with a better solution for 'artificial bold'. Have you seen CJK's *TYPICAL* fonts.dir of TrueType fonts? It is following: Not many people would be fond of tweaking fonts.dir/scale files these days :-) Why would they when just dropping truetype fonts in fontconfig in one of directories listed in the font search path works like a charm? Jungshik P.S. If merging X-TT and freetype module is not gonna happen soon, it would be nice if X-TT makes use of fontenc library used by freetype library. With fontenc library, freetype module doesn't have to hardcode font encoding to Unicode mapping tables. Because font encodings are not hard-coded, it's easy to add a new encoding although these days we don't care much. Moreover, it'll cut down the size of X-TT significantly. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
On Sat, Aug 02, 2003 at 10:10:03PM +0900, Jungshik Shin wrote: 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. Just so people don't get the wrong idea about what XFree86 is doing, core (server-side) font support will continue to be supported and maintained while ever there are sections of our user base that need it. The same is true of our inclusion of the 'xtt' module as an alternative to the 'freetype' module. Non BMP planes in XLFD hasn't been addressed by XFree86 because it wasn't a pressing issue for anyone. It is being addressed now via this discussion. Since few people seem to be interested in this issue, and if the death of XLFD is imminent, then it's probably good enough for those who are interested to agree on how to handle it according to their needs. Yeah, TTCap is useful, but it appears that we're trying to solve the wrong problem turning away from the real issue. The real problem is that we don't have quality CJK fonts in multiple styles. A practical engineering solution is about getting the results you need today with the resources available. It doesn't matter if TTCap one day becomes unnecessary because of the availability of better fonts. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
