Re: After-XTT's extension of the encoding field.

Chisato Yamauchi writes:
 > > 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 100000 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. 

This definitely drives core fonts to the edge.
Core fonts were not designed for that. 

 > 
 >   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.

Would it be possible to do that?

 > 
 >   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".

I would agree that these are valid issues.

Has anybody looked at merging these XTT functionalities into the 
freetype module?

Egbert.