MK> You could for example simply cut the Unicode character space into 16
MK> intervals 0x0XXX, 0x1XXX, etc. and open each interval as soon as you
MK> encounter a glyph from it.
If you are a client developer, however, it would be much more
productive, both in the short and long term, to implement support for
client-side fonts, whether using Xft or not. At this stage, spending
time on trying to work around the deficiencies of the core font
protocol is useless and probably even counterproductive.
(Am I repeating myself?)
In addition, you should recall that while opening one subfont is way
cheaper than opening the full font, opening all 16 of them is more
expensive than opening the whole font. In particular, the FreeType
backend performs some magic that will make this counterproductive.
(If somebody convinces me subrange specifications are useful and used,
I'll disable the magic when a non-trivial subrange specification
appreas. For now, I won't bother.)
MK> Many widget sets (e.g., Tk) open fonts only when needed, and that
MK> extends naturally to font subranges.
This approach breaks down, unfortunately, as soon as you try to go
beyond Level 1 Unicode, when you really need to know the full glyph
coverage of the available fonts.
In short: yes, there are various hacks that will allow you to push the
core fonts protocol further. They are mere hacks, however, and in a
situation in which a proper solution is already available,
implementing them is counterproductive.
Juliusz
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
