Mats> So before a schedule we will need a list of things that is Mats> supposed to be in the release. Is there such a list or is it Mats> in the developers heads? As far as I know, only Ben has anything resembling a plan, and he's not talking much lately. And from the users' point of view, the developers sees releases as a vehicle for publishing their private projects, more than for serving users. For 21.4, there was a large backlog of projects that were mostly complete that were user-oriented features. However, in 21.5, although there are projects that are user-oriented (Xft, GTK2, Unicode support) at present the "just needs a little cleanup" code is basically technical or even pure research (eg, modules, KKCC). So I would say this is your chance to speak up and say what you want. -- School of Systems and Information Engineering 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.

Malcolm Purvis <malcolmp(a)xemacs.org&gt; writes: That isn't going to be easy. Xft support is a long way off complete, and it looks like there are significant architectural difficulties with bringing it up to a really decent performance level. One of the real killers is that Xft performance is significantly lower than core font performance, which really shows up some of the inefficiencies in redisplay. Another is that some of those inefficiencies make for ... drawing issues, which are non-trivial to resolve. Aside from the gross issues, there are some subtle clipping issues with character drawing that are going to be very hard to resolve. I agree that these would be sensible release targets, though. I also think that they would win an awful lot of interest, suddenly, because a lot of people *really* want Xft support in an Emacs of some sort. Daniel

giacomo boffi <giacomo.boffi(a)polimi.it&gt; writes: What font do you people use for an Xft-enabled XEmacs? How do you set it? I have something like this normally set in .Xresources: XEmacs.default.attributeFont: -xos4-Terminus-Medium-R-Normal--14-140-72-72-C-80-iso8859-* What would be the best replacement for Xft?

Hrvoje Niksic <hniksic(a)xemacs.org&gt; writes: Stephen has written good documentation in the 'internals' manual about this, at least in his branch. Anyway, you can /only/ set the Xft font via X resources. I have: XEmacs*Tabs.xftFont: Bitstream Vera Sans-10 XEmacs*menubar*xftFont: Bitstream Vera Sans-10 XEmacs.modeline.attributeFont: Bitstream Vera Sans-14 XEmacs.default.attributeFont: Bitstream Vera Sans Mono-15 That works nicely for me. Daniel

Mike FABIAN writes: # fc-match "Terminus:style=Regular:pixelsize=14" ter-u14n_iso-8859-1.pcf.gz: "Terminus" "Regular" # on debian "terminus" is a set of pcf fonts, that shouldn't be scalable and shouldn't support antialiasing

giacomo boffi <giacomo.boffi(a)polimi.it&gt; writes: Those are some of the drawing issues I was referring too. One of the causes of those, and of poorly drawn characters[1], seems to be clipping issues, but I have not been able to chase 'em down inside the redisplay engine. Daniel Footnotes: [1] Oblique fonts tend to lose their right edge; lowercase 'd' is especially bad in italic Vera Sans Mono on my machine.

Fruhwirth> I consider it a smart move, if sjt-xft was merged into Fruhwirth> MAIN and released explicitly tagged as Fruhwirth> "experimental". Remember the hype X.Org experienced Fruhwirth> when they announced XComposite in 6.8.2? No, I don't---I could care less, I use X11 to display XEmacs, and not much more. And that's an important point. Most of the people currently using XEmacs want well-integrated features, not hype. They have work to do. Yes, they'll know about anti-aliased fonts, which makes work less painful and more productive, and maybe even Xft, but they will not be expecting to configure them with .Xresources! Fruhwirth> So don't be overmodest, the sjt-xft branch is really Fruhwirth> worth to be merged and tagged experimental. You're right about performance, IMO. Release XEmacs with Xft and the hackers (and AMD) will fix the performance problems. However, I would die of shame to release an XEmacs that doesn't have a reasonable interface for customizing faces (and Customize---besides being totally ignorant of Xft at the moment---is not reasonable, we must do better than that). And I think most of the UI hackers we really want would look at sjt-xft and say "Oh God" and go away. The Xft branch as currently constituted is a proof of concept, not ready for prime time, and there are 5 years of history (starting with the run-up to release of 21.4) that says nobody is willing to do the work that is needed. I'm talking about lisp/cus*.el, src/faces.*, and stuff like that. Until that stuff is under control (which IMO means a complete refactoring, not simply ever more kludges to fix design breakage), the only people who are going to be able to use such an XEmacs are already using it. That is *my* number one priority for a release. Number two is Unicode as the internal encoding (as an option). Given those two, Xft is as easy as "Well, hel-lo-o-o World!" But without them, it's overengineering. -- School of Systems and Information Engineering 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.