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
