Re: [Fonts] After-XTT's extension of the encoding field.
Juliusz Chroboczek writes: EE Saying 'core fonts need to go way' is equivalent to saying EE 'lets change the core protocol'. That's out of the question. I don't think the protocol spec requires the existence of any fonts beyond fixed and cursor. Right, but this doesn't solve the real problem. Look at all the legacy apps which rely on core font technology. These cannot be satisfied with just cursor and fixed. Some of them have a very clear idea which font they want and even have this hardcoded someplace. These apps exist and will continue to exist. Some of them are binary only and many of those cannot be fixed ie. converted to a new font rendering model. Egbert. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
EE There is a subsetting mechanism already (see XLFD specs), you can EE use a bracket notation like : ...-iso8859-1[65 70 80_90] means only EE use glyps 65, 70, 80-90. I don't know if this has ever been EE implemented with any renderer. It is implemented in all of our renderers with the exception of the bitmap scaler. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
CY But do XFree86's developers accept our patches for libfreetype.a? I do not believe that TTCap is a good idea, and will not implement it in the FreeType backend. The way to go is to implement all font configuration through fontconfig. Unlike fonts.dir, the fontconfig cache is an extensible data structure that can be used to store any relevant information. A very rough beginning can be found on http://www.pps.jussieu.fr/~jch/software/files/fcfpe.c Please do not redistribute this code yet, and let me know if you want to hack at it. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
JS Well, X-TT's 'competitor' is not freetype module, but fontconfig JS (+FT2 + Xft) Hear, hear. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
DD A practical engineering solution is about getting the results you DD need today with the resources available. It doesn't matter if DD TTCap one day becomes unnecessary because of the availability of DD better fonts. Just to clarify, Yamauchi-san is referring to a TTCap field that specifies the metrics of glyphs in a given range. The core protocol requires that the metrics of all glyphs be computed at font open time (actually at QueryFont time). In practice, this requires rasterising all glyphs in a font when opening a font, which for large fonts can take up to a few minutes. To work around this problem, both X-TT and freetype trust the fonts.dir file when the spacing is -c-. While this works well with ideographic fonts from the 1990s, it doesn't help with modern fonts, which tend to have proportional Latin glyphs. This extension is orthogonal to X-TT's ability to slant or bolden fonts, which is what I believe you (David) are referring to. (It is my opinion that the proper workaround is to have a general mechanism that allows caching of glyph metrics across font instantiations, and it wouldn't be difficult to convince Keith to add such an interface to fontconfig. I do not believe that fonts.dir is the right place to store such information.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
EE Saying 'core fonts need to go way' is equivalent to saying EE 'lets change the core protocol'. That's out of the question. I don't think the protocol spec requires the existence of any fonts beyond fixed and cursor. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
EE Generating fonts for asian character sets takes much more effort, EE therefore it can be expected that TTCap will remain a valid EE 'workaround' for a long time. TTCap was based on the IMHO erroneous assumption that it is better to hack extensions to fonts.dir rather than provide an extensible database for font-related information. Today, we do have just such an extensible database: fontconfig. As far as the implementation goes, TTCap lives in the font backend, which implies that somebody got the layering wrong. I do not deny that TTCap does work around real problems. However, I do not believe that TTCap is something we want to follow. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
From: Juliusz Chroboczek [EMAIL PROTECTED] Subject: Re: [Fonts] After-XTT's extension of the encoding field. Date: 04 Sep 2003 17:04:08 +0200 I do not believe that TTCap is a good idea, and will not implement it in the FreeType backend. However, I already started the experiment of enhancemnet of libfreetype.a The way to go is to implement all font configuration through fontconfig. Unlike fonts.dir, the fontconfig cache is an extensible data structure that can be used to store any relevant information. Probably, I think that I understand what you want to do. Perhaps you are going to do fundamental solution. Althougn I don't believe fontconfig itself, when can the people in CJK use OpenType satisfactorily in XLFD? Next release of XFree? Chisato Yamauchi ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
David Dawes writes: 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. Indeed core fonts should continued to be supported so that legacy application continue to work as they do today. However one should carefully deliberated if the functionality of the core fonts should still be extended as has been done in the past. This has not improved the quatlity of the code and introduced some very questionable hacks. These questionable hacks should be fixed or removed as they introduce instabilities or lead to unexpected results. 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. Care must be taken not to introduce more 'hacks' which may have unexpected side effects. Estimating these side effects was the reason why I started this discussion here. 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. Indeed. Those used to plethora of font styles available for latin character sets don't realize the pain of those who need fonts with more than 256 glyphs. Generating fonts for asian character sets takes much more effort, therefore it can be expected that TTCap will remain a valid 'workaround' for a long time. Egbert. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] 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 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. 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. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
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? 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. 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
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
Re: [Fonts] After-XTT's extension of the encoding field.
Owen Taylor writes: On Tue, 2003-07-29 at 04:44, Egbert Eich wrote: The After-XTT project which has picked up the long orphaned xtt truetype font renderer has submitted patches to xtt which recently were committed to the CVS. One of the changes prepares for the extention of the font encoding field: [From the changelog] - Preparation for extending the encoding field of XLFD. X-TT permits the following additional XLFD format: -foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.0 -foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.1 The last number can be used to indicate the plane number of a huge character set. This will work around an Xlib problem that the XCharStruct array of huge - but sparsely populated - fonts can get large. To get a uniform behavior it would be desirable if the 'plane' field would be interpreted equally by all renderers. Ideas/comments/opinions on this extensions? Let the poor thing die in peace... Old X fonts are pretty much irretrievably broken, we have a good replacement system. Adding extensions such as the above that are basically API extensions (they do no good unless the app knows about them) doesn't make sense at this point. Well, in legacy apps you usually specify the fonts using app defaults. There is a subsetting mechanism already (see XLFD specs), you can use a bracket notation like : ...-iso8859-1[65 70 80_90] means only use glyps 65, 70, 80-90. I don't know if this has ever been implemented with any renderer. Using a new notation like a.b to mark pages assigns it to this purpose, limiting future encoding specifications. However one could extend the bracket notation to mark pages instead of individual fonts or font ranges. Egbert. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
On Tue, 2003-07-29 at 10:09, Egbert Eich wrote: Owen Taylor writes: On Tue, 2003-07-29 at 04:44, Egbert Eich wrote: The After-XTT project which has picked up the long orphaned xtt truetype font renderer has submitted patches to xtt which recently were committed to the CVS. One of the changes prepares for the extention of the font encoding field: [From the changelog] - Preparation for extending the encoding field of XLFD. X-TT permits the following additional XLFD format: -foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.0 -foo-foo-medium-r-normal--0-0-0-0-c-0-foo.2000-0.1 The last number can be used to indicate the plane number of a huge character set. This will work around an Xlib problem that the XCharStruct array of huge - but sparsely populated - fonts can get large. To get a uniform behavior it would be desirable if the 'plane' field would be interpreted equally by all renderers. Ideas/comments/opinions on this extensions? Let the poor thing die in peace... Old X fonts are pretty much irretrievably broken, we have a good replacement system. Adding extensions such as the above that are basically API extensions (they do no good unless the app knows about them) doesn't make sense at this point. Well, in legacy apps you usually specify the fonts using app defaults. Sure, but you aren't exactly going to say I want this font, but everything I'm going to use comes from one plane. Or I see that as unlikely, anyways. Regards, Owen ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
Owen Taylor writes: Well, in legacy apps you usually specify the fonts using app defaults. Sure, but you aren't exactly going to say I want this font, but everything I'm going to use comes from one plane. Or I see that as unlikely, anyways. This extension came from the After-XTT people from Japan. I'm sure they have some use for it. They would be the best to comment on this. Egbert. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
From: Egbert Eich [EMAIL PROTECTED] Subject: Re: [Fonts] After-XTT's extension of the encoding field. Date: Tue, 29 Jul 2003 18:11:21 +0200 This extension came from the After-XTT people from Japan. I thought of this extension from a argument with Jamus Su. It seems that there were some discussion on some mail lists of supporting non BMP glyphs. For example, http://mail.nl.linux.org/linux-utf8/2000-12/index.html Re: X font aliases and UTF-8 xterm, Ienup Sung Re: X font aliases and UTF-8 xterm, Robert Brady Re: X font aliases and UTF-8 xterm, Roman Czyborra But I like no proposals in them which cause confusion obviously. Therefore I think that we actually cannot but extend Encoding Field. The extension of X-TT 1.4 does not have any problems about compatibility, so I implemented this extention to X-TT without many discussion. Even if this extension is not accepted, there is no necessity of deleting this extension. In Japan, there are the GT fonts which includes 66773 glyphs. To use GT fonts, I implemented this extention. It is also one of the reasons. I use them like: 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 : : The code range of gt is the same of that of jisx0208. Chisato Yamauchi After X-TT Project ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
