On Tue, 18 Nov 2003 19:57:34 EST, Vin Shelton said: Anybody who is even *thinking* of fixing the font mess has to take into consideration that the X world is heading in the Xft direction. Gtk2 is using it, and the writing is on the wall for XFree86 in general.

On Wed, 19 Nov 2003 18:33:02 +0900, "Stephen J. Turnbull" said: Doesn't matter. Jim Gettys says this about Xft (http://freedesktop.org/~jg/roadmap.html) --- Xft2 provides a client-side font API for X applications. It uses Fontconfig to select fonts, Freetype 2 for rendering the fonts and the X protocol for drawing them on the screen. When available, Xft uses the Render extension to accelerate text drawing. When Render is not available, Xft uses the core protocol to draw client-side glyphs. This provides completely compatible support of client-side fonts for all X servers, enabling application developers the benefits of anti-aliased, subpixel decimated text on all X implementations. Xft1 is obsolete and should not be used; it did not provide AA text on old X servers, and combined this functionality with what is now Fontconfig, which has been made a separate library usable by all applications, not just X applications. Both Qt and GTK+ in versions since late 1992 have used Xft2 for their text rendering. Xft2 is stable, and now widely available and deployed on open source systems. --- So Render is nice but not required, and Xft can run on anything that provides the base X11 protocol. It's got one of the more sane font models around. Looks like a winner direction to me, as long as we're willing to make Xft a pre-req library (not like we don't have a bunch of those already).

Hrvoje> For me the even more important point is that the Xft patch is, by Hrvoje> Matthias's own admission, completely broken under Mule. If that is Hrvoje> not enough for a veto, I don't know what is. Huh? All kinds of things are "completely broken under Mule" or were for the longest time? (Like Windows, I think.) The point here is that the Xft stuff can be turned off at configure time, and then it won't affect Mule at all. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

Hrvoje> I'm personally using Mule (for Latin 2), and I'm not aware of this Hrvoje> huge list of XEmacs features broken under Mule. Windows? Hrvoje> Code that is completely broken under Mule should not be introduced to Hrvoje> XEmacs, especially if the maintainers themselves say that they don't Hrvoje> understand Mule and show no evidence of willingness to fix the Hrvoje> breakage in the near future. I didn't see that lack of willingness. Hrvoje> Asking people to turn Mule off so they can enjoy antialiased font Hrvoje> display is ridiculous. Huh? Right now they can't have antialiased font display period. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

Matthias Neubauer <neubauer(a)informatik.uni-freiburg.de&gt; writes: On the display level, you only have to deal with one character set, the internal encoding used by Mule. That is a variable width encoding that shares some properties with UTF-8, but is not based on Unicode. It's possible to convert this internal encoding to UTF-8, but it requires mapping tables from Mule characters to Unicode characters, and those mapping tables are huge. Such tables might exist in 21.5, but I'm not sure.

Michael Sperber <sperber(a)informatik.uni-tuebingen.de&gt; writes: First, one item hardly constitutes a huge list. Second, it doesn't justify introducing new breakage. I'm aware of that. I don't want to have conversations like this: "I heard XEmacs now supports Xft. How do I enable it?" "Configure --with-xft." "Croatian characters no longer work!" "I forgot to mention: Xft completely breaks Mule, you have to compile without Mule to get Xft." (Not to mention that East-Asian users don't have a choice of whether to use Mule or not: for them it's a necessity.) We are either serious about supporting Mule or we are not. I am surprised that you, as a developer, would even suggest introducing a major feature that breaks it.

Hrvoje> I'm personally using Mule (for Latin 2), and I'm not aware Hrvoje> of this huge list of XEmacs features broken under Mule. ms> Windows? That's both historically false and practically an irrelevant analogy. Historically, Mule did not break Windows. Windows broke Mule. Practically, Ben was one of the most important proponents of Windows and also the primary Mule developer; we could be pretty sure he would fix it, and he has done so. ms> They also offered (despite your claim to the contrary) on ms> fixing the breakage. They _did not_ make that offer. They offered to fix a list of things to get the patch in. But they want other people to find the problems, make the current list smaller, specify the issues, do the design, and suggest implementations for them. They obviously expect others to maintain any Mule-related aspects of the patch once the initial fixing is done. ***** As you say, we have a big problem here. Programmers are always biased in favor of high-quality features as defined by "works for me" rather than high-quality applications that work for everybody. This is the main reason why XEmacs 21.5 today is substantially farther from release than 21.2 was three years ago. It has _not_ benefitted at all from Martin's anal-retentive attention to bug-fixing (or yours to stat(2)-removal), it is noticably bigger and slower than 21.4 (disastrously so for Steve Y) but we don't know why, it is full of half-baked features---eg, no substantial improvements in the widgets, which Vin just disabled by default in 21.4!---most of which are bitrotting, and we're already heading further in that direction. Doesn't this bother you at all? Why are you fighting a request for some badly needed clean-up as the price of getting approval for a feature that will aggravate the need for the requested clean-up? -- 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.

ms> You'll note that Hrvoje chose this particular way of putting ms> things. In fact, the analogy holds for Xft. The sentence ms> would be "Xft breaks Mule." Right. Put that way, it's obviously unacceptable, unless the breakers are willing to go as far as Ben does to make it right. I see no evidence of such willingness. Let's not argue Ben's sense of timing, he said he was going to make Mule work correctly on Windows, and he has done it. Didn't take a weatherman to figure out which way that gale was blowing. But this situation smells to me much more like syntax table properties and integrating GTK+, both mistakes. The GTK+ analogy is especially troubling. Lots of user enthusiasm, but except for right after the release of 21.4, when Bill P was fairly active, the top patchers to GTK have been Ben (refactoring) and James Lewis-Moss, Debian maintainer of xemacs packages (configuration nits). Nothing has been done on fundamental problems, especially on porting to GTK+ 2.x and dealing with the fact that GTK+/GNOME have completely gone their own way with respect to application configuration. And I'm still seeing lots of GTK+ bitches on c.e.x and xemacs-beta. Wouldn't you be worried in my position? Stephen> Doesn't this bother you at all? Why are you fighting a Stephen> request for some badly needed clean-up as the price of Stephen> getting approval for a feature that will aggravate the Stephen> need for the requested clean-up? ms> I didn't. I fought just about once. I explicitly said that ms> everything you said about this patch is valid. So just tell us what you and/or Eric and Matthias plan to do about those criticisms, or give a design that shows how we can work on the other problems without effectively doing `patch -R < xft-3.diff' and rewriting the Xft support from scratch every time we improve Mule support. It may not be all that hard; Matthias in particular has given some reasons for hope that straightforward solutions are available for on several of the issues. But that hope needs to be supported and the plans made more concrete. ms> I asked you to write up a plan acceptable to you. ms> Are you're effectively saying there is none? No. I'm saying "writing up a plan is not my job, man." Writing up a plan for something like this is most of the hard work, as you well know. That's why you want me to do it, and that's why I want you to do it, right? :-) I'm willing to help, but the responsibility has to be on the people who want to put the patch into the trunk. If you want me to do the planning, you're going to have to wait on my convenience. If somebody else does that work, I'll make time to review plans, improve Mule documentation, review and test code, etc. And that's a reasonably plausible commitment; I've already made several contributions (hey, who was that masked man posting texinfo docs for fontconfig?) to this line of work. I see no comparable credibility in claims from the Xft crowd that they'll support Mule. -- 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.