Re: [AC21.5] internals.texi: document some issues raised by Xft

Ben> I now really consider the exposure of consoles to be a Ben> mistake. Ben> I'm interested in seeing if we can "de-expose" them and use Ben> devices in all cases instead. What do you think? That kind of abstraction is your pidgen; I'm willing to bet my time on your judgment. However, it's not obvious to me that "device" is the right abstraction, in that Xft and X11 text rendering will share the same screen (and associated graphics will be done by core X protocol), but at least at present need somewhat different APIs (because the fonts are specified differently). At least in X.org X11R6.8, fonts have their own drawing methods internally (this isn't exposed to Xlib AFAICS, but rather is used internally in the generic wrappers used to handle the Xmb/Xwc/Xutf8 variants of text-handling routines). I'm wondering if we shouldn't go in that direction. Then devices themselves might very well disappear, or at least end up in a very different position in this hierarchy. Ben> Note also another issue under Windows, if we want to support Ben> glyph shaping, as required for Arabic, Devanagari, etc. Ben> Windows has built-in routines to take care of this but you Ben> need to pass the whole string of text and do text-width Ben> calculations similarly on the whole string rather than Ben> char-by-char. Don't we already semi-abstract to this? AFAIK we do geometry calculations on runs of text, defined more or less by "all these characters will be represented by the same font." The Xft code that I borrowed from Knauel and Neuebaur does this (although come to think of it that routine was scammed from the MS Windows code). -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.