Raymond Toy writes: Yup. That's why I repeatedly vetoed a release of a distribution with Xft in the mainline, and still can't turn it on by default. I was overruled on the basis that if we put it in, someone would scratch the itch. That was what, five, six years ago? The only people who have done anything with Xft since then are me and Aidan. ... patches welcome ... The only ways to use Xft fonts AFAIK are through resources (use the FcFontName and fcFontName class and instance attributes on the various font resources) and from Lisp (eg, using set-face-font). I suspect Customize doesn't work, either. Note that here "menubar" is the name of a face, not a widget. "default" etc should work too. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Aidan> Ar an deichiú lá de mí na Samhain, scríobh Stephen J. Turnbull: Aidan> The menu has never worked with XFT. X resources usually work, customize has Aidan> never worked (Customize is *way* less important than the menu working), and Aidan> the following Lisp code usually works (you can change Monospace-11.5 to Aidan> whatever you’d like): Aidan> (with-fboundp '(fc-name-unparse fc-font-match fc-name-parse) Aidan> (set-specifier Aidan> (face-font 'default) Aidan> (cons '(x) Aidan> (fc-name-unparse Aidan> (fc-font-match (selected-device) Aidan> (fc-name-parse "Monospace-11.5:lang=en"))))) Aidan> (macrolet Aidan> ((define-tags-and-set-faces (&rest tag-details) Aidan> (cons Aidan> 'progn Aidan> (mapcan Aidan> (function* Aidan> (lambda ((tag-name regex size)) Aidan> `((define-specifier-tag ',tag-name nil Aidan> #'(lambda (charset) Aidan> (string-match ,regex Aidan> (symbol-name (charset-name charset))))) Aidan> (set-face-font 'default Aidan> (fc-name-unparse Aidan> (fc-font-match Aidan> (selected-device) Aidan> (fc-name-parse ,(format "-%d:lang=%s" size tag-name))) Aidan> nil '(x ,tag-name) 'append))))) Aidan> tag-details)))) Aidan> (define-tags-and-set-faces Aidan> (zh-tw "^chinese-\\(big5\\|cns\\)" 18) Aidan> (zh "^chinese-" 18) Aidan> (ja "^\\(japanese\\|katakana\\)-" 18) Aidan> (ko "^korean-" 18) Aidan> (am "^ethiopic-" 18) Aidan> (vi "^vietnamese-" 14) Aidan> (el "^greek-" 12) Aidan> (ru "^cyrillic-" 12) Aidan> (hu "^latin-iso8859-2" 12) Aidan> (ar "^arabic-" 16) Aidan> (lo "^lao" 14) Aidan> (he "^hebrew" 11.5) Aidan> (th "^thai" 14)))) Aidan> If you don’t care about writing anything but English, or at a stretch Aidan> something else Windows-1252-compatible, the #'set-specifier call should be Aidan> enough. Aidan> (I believe Raymond uses the above code already!) Yes, I use something very similar. It works pretty nicely. I did have to add a few additions because I changed the default font and size to something else, and that messed up the sizes of other faces like font-lock, slime, git mode, etc. Ray _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: A lot. There's something wrong in the Xft algorithms for computing the extent of a glyph, so that Xft often leaves turds on screen. This is definitely in the font rendering engine (perhaps at a lower level than Xft), not in XEmacs, because I've seen the opposite kind of defect in Mozilla (apparently they add a pixel or two to the given extent, because redisplay blots out one pixel from the top of the next line). I've tried adding a pixel but it didn't give very satisfactory results, and didn't even manage to get rid of all turds. So non-trivial work needs to be done on redisplay algorithms to work around this problem. Menus and customize don't respect fontconfig-style font names at all. I've done some work on this (in lisp/fontconfig.el), but not enough to actually get those subsystems working. Optional (but very important IMHO) is to recognize, parse, and appropriately translate the three major dialects of font name (fontconfig, Windows, XLFD -- maybe Mac is a fourth?) to the appropriate dialect expected by the XEmacs instance. Some widgets aren't yet Muleized (tabs, progress gauge), so you get mojibake for non-ASCII characters (I forget whether Latin-1 is mojibake back I think so). Strictly speaking this isn't part of "Xft", but it's closely related. As to how much work this actually includes, neither Aidan, nor I, nor Mike (the strongest advocate of Xft on the board), nor the original coders (some Russian guy and two of Mike's students) were willing to do it. I think that level of avoidance should provide a clue. :) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell <matsl(a)xemacs.org&gt; writes: Wait for Pango/GTK+ X.Y support? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Will that solve the problem for us with current Xft support not being good enough for making 21.5 stable? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

As always -- I just think it would be good to have a plan on how to move on here. But I think you just said that fixing Xft will need quite some work and getting GTK+ support will also need quite some work. Of course things takes time and effort. We have limited resources so we need to work smart. How can we do that in this case? Is there no code base we could steal[1] to fix this? Yours -- %% Mats Footnotes: [1] See your favorite "copy vs steal" quote _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

its support of different backends it would serve XEmacs well I think (or should I say hope because quick googling will not reveal all details I'm afraid.) Could the developers interested in upgrading GTK from v1 to v2 or v3 maybe be interested in using Pango!? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats, Maybe you (or someone) can answer a question for me. What is the scope of Pango in regards to what it would change in XEmacs? When I was working on icon-themes.el, there was a set of icons called pango. So does adopting Pango affect more than just fonts? Does it affect icons used, or borders, or menu text, or gutters, scrollbars, or any other part of what you see on the XEmacs screen? Pango seems to be often implemented in conjunction with a drawing library, Cairo. Would Cairo need to be implemented too, to cover all the things XEmacs might use pango for? If so, what would Cairo replace that is in XEmacs currently? I don't have an opinion either way, I am just trying to understand what changes are being contemplated. Steve On 11/22/2012 05:39 PM, Mats Lidell wrote: _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: Not that I know of. The cheapest stealable code base is GTK+, I guess. We can't just port Emacs display and event loop code, if that's what you mean. Getting a usable display from Xft probably isn't that hard, just requires a bit of tedious cutting and trying, and testing with various fonts (yes, it matters which fonts you use). Fixing the menus and Customize is going to require more effort, I think. I'm not sure that GTK+ doesn't suffer from the same issues, since AFAIK it is now based on fontconfig. However, GTK+ will have the advantage that you can call its font selector widget fairly easily, and most people will undoubtedly prefer that to Customize or our Options menu. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: It's already optional and non-default. There's no point in removing it, unless something clearly better is available on all platforms where Xft is used. The problem is that for Asian users, antialiased fonts are hardly optional, and for the rest of the world they are highly desirable. Either Pango or raw Xft should be default in the next public release. Besides the proposals to improve Xft and create a Pango-based "XEmacs device" (the lowlevel implementation of redisplay), AFAIK getting the GTK2 or GTK3 port in good shape would also provide this. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: Depends on how you define "as good as". By the historical standard of releases, it isn't.[1] Does 21.5 have new features like bignums, a fancy experimental GC, and more Common Lisp compatibility? Yes. Does it do Unicode halfway well, and in all configurations? Yes. But I don't think those are enough, especially since I see little evidence that bugs will get fixed quickly after a release. Xft is not "blocking progress". There's nothing in the redisplay area that prevents syncing to GNU, except maybe in font-lock. What's blocking progress is a lack of code contributions. We can either get that from the existing developer pool -- but the only currently active core developer only seems to care about Common Lisp -- or we can get new users. New users are going to want the fonts, I think, or they'll go where they can get them. Sure, but we already pretty much have that. The main thing that people can do without committing too much time is to sync GNU code. If you want to start on that, be my guest. You don't need to worry too much about my taste in code; I'll complain about crappy stuff like `display-message-or-buffer', but I won't veto it, or revert it if you commit it. Footnotes: [1] There are a large number of rough edges in Mule (especially autodetection has regressed), many new features are undocumented and poorly understood even by developers (eg, behaviors), there are some issues with the new window management code (Mike blames them on non-core code that depends on undocumented features, which is plausible enough, but users are still going to perceive them as bugs), and we need to do something about the PUI (package user interface) code and bootstrapping (which is no worse than 21.4, but 21.4 users don't need to deal with it any more, since there have not been all that many changes to packages, while new users will find it really annoying). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: There isn't, really. For some users it's not as good yet, and for all users there are lots of little bugs introduced by changes Ben made. I suspect there are probably a few lingering issues with Aidan's improved Common Lisp support that will show up if everybody converts to 21.5 (eg, compiled user code that hasn't been converted to true multiple values). Aidan has been really good about fixing any bugs reported quickly, but it will contribute to an overall impression of bugginess which isn't going to attract new users or comfort older ones. In any case, there's a lot of work to be done. Until people start regularly putting in effort towards addressing the slowly accumulating bugs in the tracker, and syncing GNU code, a public release will mostly likely just generate disappointment. I don't ask for *lots* of work, but until we've got more than one person committing at least once a *month*.... Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: By your standard ("does what 21.4 does"), getting antialiased fonts working reasonably well is not in the minimal set. In my opinion, though, it is. I believe that without Xft/Pango/GTK+ quality fonts we won't get any new users, in which case a public release can only hurt our reputation for quality (such as it is at this point, but why make it worse?) That's only an opinion; if put to a vote, I'd probably vote against, but I would obey the majority if they say to do 21.6 with whatever we've got right now. Regards, Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Vin Shelton writes: Sure. Is that what we want to do? I was planning to do another beta around Christmas anyway. If it's just a matter of reversioning and somebody will write the NEWS, no problem. But I can't take any responsibility for fixing bugs that arise. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: If there's interest in this, there are four things that are an absolute minimum to get the ball rolling: 1. Somebody[TM] to put the question to XEmacs Review, to make sure that there aren't more than one or two reviewers actively opposed (which isn't appropriate for me to do since I'm not a proponent of an immediate release). 2. Somebody[TM] to write the short blurb for the announcements (same caveat applies). Basically this amounts to saying why this release is happening now. 3. Somebody[TM] to edit CHANGES-beta into a proper NEWS file (which I won't have time for until at least late March -- even a halfway job will require 1-2 man-days, and a good job might take twice that). 4. Assuming I am going to do the admin work (eg, rolling releases, caring for our web and net infrastructure, and helping to answer questions and fix bugs), I need to know the proposed release date about a month in advance for personal planning purposes, because my time is *really* tight until late March. The work to finish 1-3 has to happen before we can release, but for now we only need some idea of who probably could do them. Only 4 needs to happen more or less immediately, and that only if we're willing to have me do the work mentioned. I personally don't have any reservations about doing the admin stuff mentioned, as long as there's enough enthusiasm for the release that tasks 1-3 get done. Oh, and while the work described above really ought to be done by Reviewers, if current non-reviewers want to step up, it's easy enough to appoint new reviewers. :-) Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Thanks Stephen for nailing down the minimal list. I find it very encouraging to see just four items on it. It almost seems to be doable. OK. Done. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

One of them is the customize problem which Raymond Toy and I suffered from. (Xemacs -vanilla running customize and xemacs freezes) if this is going to happen to a broader user base, it would be quite annoying. Uwe Brauer _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta