* Antialiased text on X11 @ 2005-03-10 21:45 James Cloos 2005-03-10 22:25 ` Stefan Monnier 0 siblings, 1 reply; 44+ messages in thread From: James Cloos @ 2005-03-10 21:45 UTC (permalink / raw) There have been various pleas and debates on this posted on and off over at least the past several months. There are several options for doing this, but I beleive Cairo (cf http://cairographics.org) is the best choice. This would not be on top of the current X11 support, but parallel to it (and to the mac and win gui support). This leaves the X11 code as is to support platforms w/o cairo and by keeping legacy stuff out helps to ensure the new port is clean. The Cairo team recently released version 0.4 but is about to change the API considerably. It looks unlikely that there will be any significant API changes after this shakeup. Any work on a cairo gui for emacs should wait at least a fortnight or two to ensure a stable API. Which fits in well with getting 22.1 relased first. :-) This should provide a clean platform for antialiased text, overlays of combining diacritics and other typographic features within the text buffers and should work well for emacs applications like preview-latex, xml modes with a similar intent or any graphics-heavy app. -JimC -- James H. Cloos, Jr. <cloos@jhcloos.com> PS. I can spend devel time on this, though will wait until cairo's api is settled. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-10 21:45 Antialiased text on X11 James Cloos @ 2005-03-10 22:25 ` Stefan Monnier 2005-03-10 23:15 ` Han Boetes 2005-03-10 23:19 ` James Cloos 0 siblings, 2 replies; 44+ messages in thread From: Stefan Monnier @ 2005-03-10 22:25 UTC (permalink / raw) Cc: emacs-devel > This would not be on top of the current X11 support, but parallel to > it (and to the mac and win gui support). This leaves the X11 code > as is to support platforms w/o cairo and by keeping legacy stuff out > helps to ensure the new port is clean. A Cairo port will probably make sense at some point, but I think that anti-aliasing support for X11 (using xft) is more urgent. Stefan ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-10 22:25 ` Stefan Monnier @ 2005-03-10 23:15 ` Han Boetes 2005-03-11 4:58 ` Jan D. 2005-03-18 21:21 ` Ali Ijaz Sheikh 2005-03-10 23:19 ` James Cloos 1 sibling, 2 replies; 44+ messages in thread From: Han Boetes @ 2005-03-10 23:15 UTC (permalink / raw) Stefan Monnier wrote: > A Cairo port will probably make sense at some point, but I think that > anti-aliasing support for X11 (using xft) is more urgent. A lot of people _think_ they need AA support. Until I tell them about the terminus-font that is. :-) I tested the AA branch but that developer dislikes gtk so much he nearly ripped it out. And that's the only toolkit that supports AA! # Han ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-10 23:15 ` Han Boetes @ 2005-03-11 4:58 ` Jan D. 2005-03-18 21:21 ` Ali Ijaz Sheikh 1 sibling, 0 replies; 44+ messages in thread From: Jan D. @ 2005-03-11 4:58 UTC (permalink / raw) Cc: emacs-devel > Stefan Monnier wrote: >> A Cairo port will probably make sense at some point, but I think that >> anti-aliasing support for X11 (using xft) is more urgent. > > A lot of people _think_ they need AA support. Until I tell them about > the terminus-font that is. :-) > > I tested the AA branch but that developer dislikes gtk so much he > nearly > ripped it out. And that's the only toolkit that supports AA! Where is that branch? How do you access it? Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-10 23:15 ` Han Boetes 2005-03-11 4:58 ` Jan D. @ 2005-03-18 21:21 ` Ali Ijaz Sheikh 2005-03-18 22:39 ` Drew Adams 2005-03-19 0:59 ` Antialiased text on X11 Miles Bader 1 sibling, 2 replies; 44+ messages in thread From: Ali Ijaz Sheikh @ 2005-03-18 21:21 UTC (permalink / raw) Han Boetes wrote: > Stefan Monnier wrote: > >>A Cairo port will probably make sense at some point, but I think that >>anti-aliasing support for X11 (using xft) is more urgent. > > > A lot of people _think_ they need AA support. Until I tell them about > the terminus-font that is. :-) I think that is a generalization; and a matter of opinion. I have tried the terminus font; and atleast a hundred other fonts. The fact of the matter is that anti-aliased fonts specially on LCD screens look much better than non-antialiased fonts. Its rather sad that I have to use xemacs on windows (such a heresy) in order to have my fonts antialised. Ali ^ permalink raw reply [flat|nested] 44+ messages in thread
* RE: Antialiased text on X11 2005-03-18 21:21 ` Ali Ijaz Sheikh @ 2005-03-18 22:39 ` Drew Adams 2005-03-19 22:45 ` The WHY of Xft [was: Re: Antialiased text on X11] James Cloos 2005-03-19 0:59 ` Antialiased text on X11 Miles Bader 1 sibling, 1 reply; 44+ messages in thread From: Drew Adams @ 2005-03-18 22:39 UTC (permalink / raw) The fact of the matter is that anti-aliased fonts specially on LCD screens look much better than non-antialiased fonts. Its rather sad that I have to use xemacs on windows (such a heresy) in order to have my fonts antialised. I'm not an expert on anti-aliasing, but I use Windows XP on an LCD with ClearType smoothing of screen font edges, and it works beautifully. I only wish I had the same effect when I use Emacs on Linux (I'm not saying there is no way to do that, but I'm ignorant of it). If you use Windows XP, try this: 1. Right-click the desktop, choose Properties. 2. Open the Appearance tab (panel). 3. Click the Effects... button. 4. Check the box labeled "Use the following method to smooth edges of screen fonts" 5. Choose ClearType or Standard (I use ClearType). 6. Click OK. Click OK. Does that not do what you want? ^ permalink raw reply [flat|nested] 44+ messages in thread
* The WHY of Xft [was: Re: Antialiased text on X11] 2005-03-18 22:39 ` Drew Adams @ 2005-03-19 22:45 ` James Cloos 2005-03-19 23:47 ` Miles Bader 0 siblings, 1 reply; 44+ messages in thread From: James Cloos @ 2005-03-19 22:45 UTC (permalink / raw) It should be pointed out that antialiasing and sub-pixel rendering are just two of the benefits of the client-side font system brought by Xft and friends. The other benefits are just as important. Control and installation of fonts are easier for most users, fonts with large encodings -- such as CJKV fonts or any iso10646-encoded font -- use *much* less vm and data transfer between client and server is reduced for most workloads. Even w/o antialiasing the user's experience improves. -JimC -- James H. Cloos, Jr. <cloos@jhcloos.com> <http://jhcloos.com> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: The WHY of Xft [was: Re: Antialiased text on X11] 2005-03-19 22:45 ` The WHY of Xft [was: Re: Antialiased text on X11] James Cloos @ 2005-03-19 23:47 ` Miles Bader 2005-03-20 16:49 ` The WHY of Xft James Cloos 0 siblings, 1 reply; 44+ messages in thread From: Miles Bader @ 2005-03-19 23:47 UTC (permalink / raw) Cc: emacs-devel On Sat, 19 Mar 2005 17:45:42 -0500, James Cloos <cloos@jhcloos.com> wrote: > It should be pointed out that antialiasing and sub-pixel rendering are > just two of the benefits of the client-side font system brought by Xft > and friends. > > The other benefits are just as important. Control and installation of > fonts are easier for most users Can you explain in more detail? I use debian, and Emacs already seems able to use the same fonts as xft-using programs, albeit not in anti-aliased form. > fonts with large encodings -- such as > CJKV fonts or any iso10646-encoded font -- use *much* less vm and data > transfer between client and server is reduced for most workloads. Doesn't the X server already support partial loading of large fonts? [I mean the "-deferglyphs 16" in the X startup options.] -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: The WHY of Xft 2005-03-19 23:47 ` Miles Bader @ 2005-03-20 16:49 ` James Cloos 2005-03-20 22:30 ` Miles Bader 2005-03-21 0:32 ` Kenichi Handa 0 siblings, 2 replies; 44+ messages in thread From: James Cloos @ 2005-03-20 16:49 UTC (permalink / raw) Cc: emacs-devel, miles >>>>> “Miles” == Miles Bader <snogglethorpe@gmail.com> writes: >> The other benefits are just as important. Control and installation >> of fonts are easier for most users Miles> Can you explain in more detail? I use debian, and Emacs Miles> already seems able to use the same fonts as xft-using programs, Miles> albeit not in anti-aliased form. That is becasue debian did the hard work for those fonts that it includes as part of the distribution. The hard part for users comes when they want to install a font not part of the dist, whether one they've purchased or otherwise acquired. It is much easier to just drop a font into ~/.fonts than to mess with fonts.dir and fonts.scale files, etc. At least for those who've not been doing so for a couple of decades.... ☺ fc-cache should be run when the contents of the searched directories change, but cli-averse users will probably use a gui not unlike that on doze or macs which can do that for them. mkfontscale has helped ease installation of server-side fonts, but it is still not as easy. Obviously for emacs it is less of an issue than for something like gimp, but I’m sure it will come up for some. Especially if packages like preview-latex can use the client-side fonts to preview the entire document as it is being edited rather than just selected portions. >> fonts with large encodings -- such as CJKV fonts or any >> iso10646-encoded font -- use *much* less vm and data transfer >> between client and server is reduced for most workloads. Miles> Doesn’t the X server already support partial loading of large Miles> fonts? [I mean the “-deferglyphs 16” in the X startup Miles> options.] I’m not familiar with deferglyphs; I don't remember it from any of the discussions I read or participated in on the fontconfig, xfree or freedesktop lists. And I cannot find it in X(7x) or Xorg(1x). My understanding is that when a (server-side) font is opened by the X server it must determine all of the glyphs’ metrics, which requires rendering all of them. There are also still at least a couple of things I forgot to mention. Server-side unicode fonts are limited to the bmp, so one cannot edit scripts that use non-bmp characters w/o switching to client-side fonts. Client-side fonts are also necessary to take full advantage of opentype features. -JimC -- James H. Cloos, Jr. <cloos@jhcloos.com> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: The WHY of Xft 2005-03-20 16:49 ` The WHY of Xft James Cloos @ 2005-03-20 22:30 ` Miles Bader 2005-03-21 14:24 ` David Hansen 2005-03-21 16:12 ` James Cloos 2005-03-21 0:32 ` Kenichi Handa 1 sibling, 2 replies; 44+ messages in thread From: Miles Bader @ 2005-03-20 22:30 UTC (permalink / raw) Cc: emacs-devel, miles On Sun, 20 Mar 2005 11:49:50 -0500, James Cloos <cloos@jhcloos.com> wrote: > My understanding is that when a (server-side) font is opened by the > X server it must determine all of the glyphs' metrics, which requires > rendering all of them. I think this is not true -- it seems to be exactly this behavior which -deferglyphs stops. Without -deferglyphs, there was indeed a noticeable freeze when using a CJK font for the first time; I've not encountered this freeze since. Debian has had -deferglyphs as the default for quite a long time (e.g. if you use gdm, in /etc/X11/gdm/gdm.conf); perhaps other distros do not. Can xft still use bitmap fonts? In the case of CJK, the commonly available X bitmap fonts do seem to be generally more attractive at typical text-editor size than what freetype produces for commonly[*] available scaled fonts. [*] By commonly available, I really mean "free and packaged in Debian" ... Not the best definition I suppose, but maybe indicative of what a typical lazy user like me sees... I'm all for xft BTW; don't let my sniping give you the opposite impression... :-) -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: The WHY of Xft 2005-03-20 22:30 ` Miles Bader @ 2005-03-21 14:24 ` David Hansen 2005-03-21 16:12 ` James Cloos 1 sibling, 0 replies; 44+ messages in thread From: David Hansen @ 2005-03-21 14:24 UTC (permalink / raw) On Mon, 21 Mar 2005 07:30:55 +0900 Miles Bader wrote: > Can xft still use bitmap fonts? In the case of CJK, the commonly > available X bitmap fonts do seem to be generally more attractive at > typical text-editor size than what freetype produces for commonly[*] > available scaled fonts. Debian unstable (but AFAIK you have to manually edit this file on Debian): $ cat /etc/fonts/local.conf <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <include ignore_missing="yes">/var/lib/defoma/fontconfig.d/fonts.conf</include> <!-- Uncomment below to enable bitmapped fonts --> <dir>/usr/X11R6/lib/X11/fonts</dir> <!-- Uncomment below to enable subpixel rendering --> [...] David ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: The WHY of Xft 2005-03-20 22:30 ` Miles Bader 2005-03-21 14:24 ` David Hansen @ 2005-03-21 16:12 ` James Cloos 1 sibling, 0 replies; 44+ messages in thread From: James Cloos @ 2005-03-21 16:12 UTC (permalink / raw) Cc: emacs-devel, miles >>>>> "Miles" == Miles Bader <snogglethorpe@gmail.com> writes: Miles> I think this is not true -- it seems to be exactly this Miles> behavior which -deferglyphs stops. I’ve now found deferglyphs in Xserver(1). As I said, it is new to me, but it does seem to address that one issue. Miles> Can xft still use bitmap fonts? Xft can use anything freetype can render, including at least bdf, pcf and sfnt bitmaps. -JimC -- James H. Cloos, Jr. <cloos@jhcloos.com> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: The WHY of Xft 2005-03-20 16:49 ` The WHY of Xft James Cloos 2005-03-20 22:30 ` Miles Bader @ 2005-03-21 0:32 ` Kenichi Handa 1 sibling, 0 replies; 44+ messages in thread From: Kenichi Handa @ 2005-03-21 0:32 UTC (permalink / raw) Cc: miles, snogglethorpe, emacs-devel In article <m3r7iamfdd.fsf@lugabout.cloos.reno.nv.us>, James Cloos <cloos@jhcloos.com> writes: > There are also still at least a couple of things I forgot to mention. > Server-side unicode fonts are limited to the bmp, so one cannot edit > scripts that use non-bmp characters w/o switching to client-side > fonts. Client-side fonts are also necessary to take full advantage > of opentype features. And, from a viewpoint of multilingualization, the biggest advantage of using local-side font (via Xft or by freetype directly) is that we can access such OpenType tables as GSUB/GPOS for Indic, and etc. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-18 21:21 ` Ali Ijaz Sheikh 2005-03-18 22:39 ` Drew Adams @ 2005-03-19 0:59 ` Miles Bader 2005-03-19 6:27 ` Jan D. 1 sibling, 1 reply; 44+ messages in thread From: Miles Bader @ 2005-03-19 0:59 UTC (permalink / raw) Cc: emacs-devel On Fri, 18 Mar 2005 16:21:06 -0500, Ali Ijaz Sheikh <ali@binish.com> wrote: > > A lot of people _think_ they need AA support. Until I tell them about > > the terminus-font that is. :-) > > I think that is a generalization; and a matter of opinion. Well, surely not, since he was relating his experience, not stating a general rule... :-) But I understand your point. > The fact of the matter is that anti-aliased > fonts specially on LCD screens look much better than non-antialiased > fonts. This however, _is_ a generalization, and a matter of opinion. I use beautiful anti-aliased fonts (with sub-pixel rendering on an LCD) every day in firefox and gnome apps (ft2's auto-hinting is incredibly good), and I also use Emacs alongside them. Emacs is not noticeably less beautiful. The reason is simply that -- like Hans -- I've found a font that I really like which looks good without anti-aliasing. I think that in general what Hans says is correct: it depends very much on the particular font whether anti-aliasing helps significantly or not (there are certain fonts which I far _prefer_ "non-smoothed", and wish I knew how to make ft stop smoothing just those fonts). However Emacs not supporting anti-aliasing certainly restricts one's choices of fonts, because many fonts out there don't look good without AA, and one's choice of sizes, because at extremely small sizes AA becomes much more necessary. If a user particularly likes a font that needs AA, he's surely going to be a bit annoyed that he can't use it in Emacs. Obviously you are. :-) So I think Emacs should definitely support AA when it can, but it's surely not as fundamental a requirement as has been suggested... [The question of whether to support just xft or try to go for an entire new rendering layer like Cairo is interesting -- my impression is that porting to a new rendering layer is actually fairly straight-forward; it might be the easier task than figuring out the convoluted Emacs font-selection machinery (required in either case I guess -- but it means that "xft only" might not be any easier really)!] -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-19 0:59 ` Antialiased text on X11 Miles Bader @ 2005-03-19 6:27 ` Jan D. 2005-03-19 7:39 ` Miles Bader ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Jan D. @ 2005-03-19 6:27 UTC (permalink / raw) Cc: Ali Ijaz Sheikh, emacs-devel > [The question of whether to support just xft or try to go for an > entire new rendering layer like Cairo is interesting -- my impression > is that porting to a new rendering layer is actually fairly > straight-forward; it might be the easier task than figuring out the > convoluted Emacs font-selection machinery (required in either case I > guess -- but it means that "xft only" might not be any easier > really)!] I have started on Xft support, but it is really something for the release after the next, so I don't spend much time on it yet. I can confirm your reasoning, the Emacs font-selection machinery is indeed the most tricky part, I have not done that fully, so I can't change font yet. But part of the problem is that the Xft font selection is entirely new compared to the old X font selection. The rendering was not that difficult, it was more finding the right font metrics that required some thought. Finally, the rendering (i.e. the actual drawing of text) is trivial in comparison. To use Cairo would not have helped a bit, rather the opposite. I'd would requre we dump most of the redisplay engine and let Cairo take care of it for Cairo to give any extra value. I am doing an Xft solution, I did not find the talked about Xft branch, so I started from scratch. The main reason for doing this is that I wanted to use the GTK file selection dialog, but since that dialog displays all fonts, including antialiased, Emacs can currently not use it. Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-19 6:27 ` Jan D. @ 2005-03-19 7:39 ` Miles Bader 2005-03-19 16:31 ` Stefan Monnier 2005-03-22 12:45 ` Oliver Scholz 2 siblings, 0 replies; 44+ messages in thread From: Miles Bader @ 2005-03-19 7:39 UTC (permalink / raw) Cc: emacs-devel, Ali Ijaz Sheikh, miles On Sat, 19 Mar 2005 07:27:38 +0100, Jan D. <jan.h.d@swipnet.se> wrote: > I am doing an Xft solution, I did not find the talked about Xft branch, > so I started from scratch. No biggie I think -- the "xft branch" was pretty crufty as I remember it, more a proof of concept than anything else. Since you're well-acquainted with Emacs internals, you're probably a good person to do the job right. [The original archive containing that work was at http://www.cs.ubc.ca/~cmg/{archive}, but it seems to be gone now.] -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-19 6:27 ` Jan D. 2005-03-19 7:39 ` Miles Bader @ 2005-03-19 16:31 ` Stefan Monnier 2005-03-19 16:53 ` Han Boetes ` (3 more replies) 2005-03-22 12:45 ` Oliver Scholz 2 siblings, 4 replies; 44+ messages in thread From: Stefan Monnier @ 2005-03-19 16:31 UTC (permalink / raw) Cc: snogglethorpe, emacs-devel, Ali Ijaz Sheikh, miles [-- Attachment #1: Type: text/plain, Size: 1067 bytes --] > I have started on Xft support, but it is really something for the release > after the next, so I don't spend much time on it yet. I can confirm your > reasoning, the Emacs font-selection machinery is indeed the most tricky > part, I have not done that fully, so I can't change font yet. But part of > the problem is that the Xft font selection is entirely new compared to the > old X font selection. Feel free to put it on an Arch branch somewhere, or a branch in the CVS ;-) > I am doing an Xft solution, I did not find the talked about Xft branch, so > I started from scratch. The main reason for doing this is that I wanted to > use the GTK file selection dialog, but since that dialog displays all fonts, > including antialiased, Emacs can currently not use it. I don't think you wasted your time, but in case you're interested, I've appended a patch I extracted from that xft branch at some point. I had some trouble extracting the patch, so there might be some missing bits and some unrelated extra bits. It surely doesn't compile. Stefan [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: xft-2.patch --] [-- Type: text/x-patch, Size: 39734 bytes --] Seulement dans xft-base/src: .arch-ids Seulement dans xft-base/src: bitmaps Seulement dans xft-base/src: ChangeLog Seulement dans xft-base/src: ChangeLog.1 Seulement dans xft-base/src: ChangeLog.2 Seulement dans xft-base/src: ChangeLog.3 Seulement dans xft-base/src: ChangeLog.4 Seulement dans xft-base/src: ChangeLog.5 Seulement dans xft-base/src: ChangeLog.6 Seulement dans xft-base/src: ChangeLog.7 Seulement dans xft-base/src: ChangeLog.8 Seulement dans xft-base/src: ChangeLog.9 Seulement dans xft/src.xft: config.h Seulement dans xft-base/src: config.in Seulement dans xft-base/src: COPYING Seulement dans xft-base/src: .cvsignore Seulement dans xft-base/src: cxux-crt0.s Seulement dans xft-base/src: .dbxinit diff -u --recursive xft-base/src/dispextern.h xft/src.xft/dispextern.h --- xft-base/src/dispextern.h 2005-03-10 18:22:52.123027247 -0500 +++ xft/src.xft/dispextern.h 2005-03-10 18:18:01.264178566 -0500 @@ -31,6 +31,11 @@ #include <X11/Intrinsic.h> #endif /* USE_X_TOOLKIT */ +#define HAVE_XFT +#ifdef HAVE_XFT +#include <X11/Xft/Xft.h> +#endif + #else /* !HAVE_X_WINDOWS */ /* X-related stuff used by non-X gui code. */ @@ -1092,6 +1097,7 @@ /* Font in which this string is to be drawn. */ XFontStruct *font; + XftFont *xftfont; /* Font info for this string. */ struct font_info *font_info; @@ -1368,6 +1374,16 @@ an id as returned from load_pixmap. */ int stipple; +#ifdef HAVE_XFT + XftFont *xftfont; + XftColor xftforeground; + XftColor xftbackground; + XftDraw *draw; +#endif + + /* Reverse the foreground and background to make the cursor */ + int reverse_color; + #else /* not HAVE_WINDOW_SYSTEM */ /* Dummy. */ diff -u --recursive xft-base/src/dispnew.c xft/src.xft/dispnew.c Seulement dans xft/src.xft: epaths.h Seulement dans xft-base/src: epaths.in diff -u --recursive xft-base/src/fontset.c xft/src.xft/fontset.c diff -u --recursive xft-base/src/frame.c xft/src.xft/frame.c Seulement dans xft-base/src: .gdbinit Seulement dans xft-base/src: .gdbinit-union diff -u --recursive xft-base/src/keyboard.c xft/src.xft/keyboard.c Seulement dans xft-base/src: m Seulement dans xft/src.xft: Makefile.c Seulement dans xft-base/src: Makefile.in Seulement dans xft-base/src: makefile.nt Seulement dans xft-base/src: makefile.w32-in Seulement dans xft-base/src: README Seulement dans xft-base/src: s Seulement dans xft-base/src: stamp-h.in Seulement dans xft-base/src: temacs.opt diff -u --recursive xft-base/src/window.c xft/src.xft/window.c diff -u --recursive xft-base/src/xdisp.c xft/src.xft/xdisp.c --- xft-base/src/xdisp.c 2005-03-10 18:22:58.088270349 -0500 +++ xft/src.xft/xdisp.c 2005-03-10 18:18:05.170337510 -0500 @@ -17332,10 +17233,10 @@ default font, but record the fact that we couldn't load it in the glyph string so that we can draw rectangles for the characters of the glyph string. */ - if (s->font == NULL) + if (0 && s->font == NULL) { s->font_not_found_p = 1; - s->font = FRAME_FONT (s->f); + s->xftfont = FRAME_FONT (s->f); } /* Adjust base line for subscript/superscript text. */ @@ -17399,17 +17300,17 @@ ++glyph; } - s->font = s->face->font; + s->xftfont = s->face->xftfont; s->font_info = FONT_INFO_FROM_ID (s->f, s->face->font_info_id); /* If the specified font could not be loaded, use the frame's font, but record the fact that we couldn't load it in S->font_not_found_p so that we can draw rectangles for the characters of the glyph string. */ - if (s->font == NULL || glyph_not_available_p) + if (0 && (s->font == NULL || glyph_not_available_p)) { s->font_not_found_p = 1; - s->font = FRAME_FONT (s->f); + s->xftfont = FRAME_FONT (s->f); } /* Adjust base line for subscript/superscript text. */ @@ -18433,7 +18320,7 @@ double *res; struct it *it; Lisp_Object prop; - XFontStruct *font; + XftFont *font; int width_p; { double pixels; @@ -18601,7 +18488,7 @@ int ascent = 0; double tem; struct face *face = FACE_FROM_ID (it->f, it->face_id); - XFontStruct *font = face->font ? face->font : FRAME_FONT (it->f); + XftFont *font = face->xftfont ? face->xftfont : FRAME_FONT (it->f); PREPARE_FACE_FOR_DISPLAY (it->f, face); @@ -18726,7 +18613,7 @@ if (it->what == IT_CHARACTER) { XChar2b char2b; - XFontStruct *font; + XftFont *font; struct face *face = FACE_FROM_ID (it->f, it->face_id); XCharStruct *pcm; int font_not_found_p; @@ -18770,7 +18657,7 @@ /* Get font to use. Encode IT->char_to_display. */ get_char_face_and_encoding (it->f, it->char_to_display, it->face_id, &char2b, it->multibyte_p, 0); - font = face->font; + font = face->xftfont; /* When no suitable font found, use the default font. */ font_not_found_p = font == NULL; @@ -18921,8 +18808,8 @@ from the charset width; this is what old redisplay code did. */ - pcm = rif->per_char_metric (font, &char2b, - FONT_TYPE_FOR_MULTIBYTE (font, it->c)); + pcm = rif->per_char_metric (font, &char2b, + FONT_TYPE_FOR_MULTIBYTE (font, it->c)); if (font_not_found_p || !pcm) { @@ -18982,7 +18869,7 @@ /* Note: A composition is represented as one glyph in the glyph matrix. There are no padding glyphs. */ XChar2b char2b; - XFontStruct *font; + XftFont *font; struct face *face = FACE_FROM_ID (it->f, it->face_id); XCharStruct *pcm; int font_not_found_p; @@ -19006,7 +18893,7 @@ face = FACE_FROM_ID (it->f, it->face_id); get_char_face_and_encoding (it->f, it->char_to_display, it->face_id, &char2b, it->multibyte_p, 0); - font = face->font; + font = face->xftfont; /* When no suitable font found, use the default font. */ font_not_found_p = font == NULL; @@ -19095,7 +18982,7 @@ face = FACE_FROM_ID (it->f, face_id); get_char_face_and_encoding (it->f, ch, face->id, &char2b, it->multibyte_p, 0); - font = face->font; + font = face->xftfont; if (font == NULL) { font = FRAME_FONT (it->f); diff -u --recursive xft-base/src/xfaces.c xft/src.xft/xfaces.c --- xft-base/src/xfaces.c 2005-03-10 18:22:58.188274425 -0500 +++ xft/src.xft/xfaces.c 2005-03-10 18:18:04.915327133 -0500 @@ -1063,7 +1063,8 @@ /* Free the font. */ BLOCK_INPUT; #ifdef HAVE_X_WINDOWS - XFreeFont (dpyinfo->display, font_info->font); + // FIXME -- cmg + //XFreeFont (dpyinfo->display, font_info->font); #endif #ifdef WINDOWSNT w32_unload_font (dpyinfo, font_info->font); @@ -5146,7 +5147,7 @@ if (face->font) { #ifdef HAVE_X_WINDOWS - xgcv.font = face->font->fid; + //xgcv.font = face->font->fid; #endif #ifdef WINDOWSNT xgcv.font = face->font; @@ -5154,7 +5155,7 @@ #ifdef MAC_OS xgcv.font = face->font; #endif - mask |= GCFont; + //mask |= GCFont; } BLOCK_INPUT; @@ -5169,6 +5170,53 @@ face->gc = x_create_gc (f, mask, &xgcv); UNBLOCK_INPUT; } +#ifdef HAVE_XFT + BLOCK_INPUT; + if (face->draw == 0) + { + XWindowAttributes atts; + XGetWindowAttributes (FRAME_X_DISPLAY(f), FRAME_X_WINDOW(f), &atts); + face->draw = XftDrawCreate (FRAME_X_DISPLAY(f), + (Drawable) FRAME_X_WINDOW(f), + atts.visual, atts.colormap); + } + if (face->font != 0 && face->xftfont == 0) + { + char *name = "-adobe-helvetica-medium-r-narrow--*-*-*-*-*-0-iso8859-1"; + /* + char *name; + XFontStruct *fs = face->font; + Atom value; + XGetFontProperty (fs, XA_FONT, &value); + name = (char *) XGetAtomName(FRAME_X_DISPLAY (f), value); + */ + + face->xftfont = XftFontOpenXlfd (FRAME_X_DISPLAY (f), DefaultScreen(FRAME_X_DISPLAY(f)), name); + xassert(face->xftfont); + //XFree (name); + } + { + XWindowAttributes atts; + XColor newcolor; + XGetWindowAttributes (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), &atts); + face->xftforeground.pixel = face->foreground; + newcolor.pixel = face->foreground; + XQueryColor (FRAME_X_DISPLAY (f), atts.colormap, &newcolor); + face->xftforeground.color.red = newcolor.red; + face->xftforeground.color.green = newcolor.green; + face->xftforeground.color.blue = newcolor.blue; + face->xftforeground.color.alpha = 0xffff; + face->xftbackground.pixel = face->background; + newcolor.pixel = face->background; + XQueryColor (FRAME_X_DISPLAY (f), atts.colormap, &newcolor); + face->xftbackground.color.red = newcolor.red; + face->xftbackground.color.green = newcolor.green; + face->xftbackground.color.blue = newcolor.blue; + face->xftbackground.color.alpha = 0xffff; + } + UNBLOCK_INPUT; + +#endif /* HAVE_XFT */ #endif /* HAVE_WINDOW_SYSTEM */ } @@ -6879,6 +6927,9 @@ { bcopy (base_face, face, sizeof *face); face->gc = 0; +#ifdef HAVE_XFT + face->xftfont = 0; +#endif /* Don't try to free the colors copied bitwise from BASE_FACE. */ face->colors_copied_bitwise_p = 1; diff -u --recursive xft-base/src/xfns.c xft/src.xft/xfns.c --- xft-base/src/xfns.c 2005-03-10 18:22:58.232276218 -0500 +++ xft/src.xft/xfns.c 2005-03-10 18:18:05.279341946 -0500 @@ -3041,14 +3042,14 @@ Note that many default values are used. */ /* Normal video */ - gc_values.font = FRAME_FONT (f)->fid; + //gc_values.font = FRAME_FONT (f)->fid; gc_values.foreground = f->output_data.x->foreground_pixel; gc_values.background = f->output_data.x->background_pixel; gc_values.line_width = 0; /* Means 1 using fast algorithm. */ f->output_data.x->normal_gc = XCreateGC (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), - GCLineWidth | GCFont | GCForeground | GCBackground, + GCLineWidth | /* GCFont | */ GCForeground | GCBackground, &gc_values); /* Reverse video style. */ @@ -3057,7 +3058,7 @@ f->output_data.x->reverse_gc = XCreateGC (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), - GCFont | GCForeground | GCBackground | GCLineWidth, + /*GCFont |*/ GCForeground | GCBackground | GCLineWidth, &gc_values); /* Cursor has cursor-color background, background-color foreground. */ @@ -3070,7 +3071,7 @@ cursor_bits, 16, 16); f->output_data.x->cursor_gc = XCreateGC (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), - (GCFont | GCForeground | GCBackground + (/*GCFont | */GCForeground | GCBackground | GCFillStyle /* | GCStipple */ | GCLineWidth), &gc_values); @@ -3483,7 +3484,7 @@ "autoLower", "AutoRaiseLower", RES_TYPE_BOOLEAN); x_default_parameter (f, parms, Qcursor_type, Qbox, "cursorType", "CursorType", RES_TYPE_SYMBOL); - x_default_parameter (f, parms, Qscroll_bar_width, Qnil, + x_default_parameter (f, parms, Qscroll_bar_width, make_number(0), "scrollBarWidth", "ScrollBarWidth", RES_TYPE_NUMBER); @@ -3492,6 +3493,7 @@ FRAME_LINES (f). */ width = FRAME_COLS (f); height = FRAME_LINES (f); + height = 40; SET_FRAME_COLS (f, 0); FRAME_LINES (f) = 0; @@ -4221,7 +4223,8 @@ for (i = 0; i < dpyinfo->n_fonts; i++) if (dpyinfo->font_table[i].name) { - XFreeFont (dpyinfo->display, dpyinfo->font_table[i].font); + // FIXME: should free -- cmg + //XFreeFont (dpyinfo->display, dpyinfo->font_table[i].font); } x_destroy_all_bitmaps (dpyinfo); diff -u --recursive xft-base/src/xmenu.c xft/src.xft/xmenu.c diff -u --recursive xft-base/src/xterm.c xft/src.xft/xterm.c --- xft-base/src/xterm.c 2005-03-10 18:22:58.385282453 -0500 +++ xft/src.xft/xterm.c 2005-03-10 18:18:05.390346462 -0500 @@ -184,6 +184,10 @@ int x_use_underline_position_properties; +/* Non-zero means use Xft for anti-aliased fonts */ + +int x_use_xft; + /* This is a chain of structures for all the X displays currently in use. */ @@ -287,7 +291,7 @@ extern Lisp_Object Vx_no_window_manager; -extern Lisp_Object Qeql; +extern Lisp_Object Qface, Qmouse_face, Qeql; extern int errno; @@ -326,7 +330,7 @@ void x_wm_set_window_state P_ ((struct frame *, int)); void x_wm_set_icon_pixmap P_ ((struct frame *, int)); void x_initialize P_ ((void)); -static void x_font_min_bounds P_ ((XFontStruct *, int *, int *)); +static void x_font_min_bounds P_ ((XftFont *, int *, int *)); static int x_compute_min_glyph_bounds P_ ((struct frame *)); static void x_update_end P_ ((struct frame *)); static void XTframe_up_to_date P_ ((struct frame *)); @@ -788,13 +778,31 @@ static XCharStruct * x_per_char_metric (font, char2b, font_type) - XFontStruct *font; + XftFont *font; XChar2b *char2b; int font_type; /* unused on X */ { /* The result metric information. */ - XCharStruct *pcm = NULL; + static XCharStruct pcm; + XGlyphInfo extents; + Display *dpy; + XftChar16 ch; + if (NILP(x_display_name_list)) return NULL; + dpy = x_display_info_for_name(XCAR(XCAR(x_display_name_list)))->display; + + ch = (char2b->byte1 << 8) | char2b->byte2; + BLOCK_INPUT; + XftTextExtents16 (dpy, font, (XftChar16 *) &ch, 1, &extents); + UNBLOCK_INPUT; + pcm.ascent = font->ascent; + pcm.descent = font->descent; + pcm.lbearing = 0; + pcm.rbearing = 0; + pcm.width = extents.xOff; + //XCloseDisplay(dpy); + return &pcm; +#if 0 xassert (font && char2b); if (font->per_char != NULL) @@ -852,6 +860,7 @@ return ((pcm == NULL || (pcm->width == 0 && (pcm->rbearing - pcm->lbearing) == 0)) ? NULL : pcm); +#endif } @@ -866,7 +875,9 @@ int *two_byte_p; { int charset = CHAR_CHARSET (c); - XFontStruct *font = font_info->font; + return 0; +#if 0 + XftFont *font = font_info->font; /* FONT_INFO may define a scheme by which to encode byte1 and byte2. This may be either a program in a special encoder language or a @@ -913,9 +924,10 @@ } if (two_byte_p) - *two_byte_p = ((XFontStruct *) (font_info->font))->max_byte1 > 0; + *two_byte_p = ((XftFont *) (font_info->font))->max_byte1 > 0; return FONT_TYPE_UNKNOWN; +#endif } @@ -955,7 +967,7 @@ int, int, int, XRectangle *)); #if GLYPH_DEBUG -static void x_check_font P_ ((struct frame *, XFontStruct *)); +static void x_check_font P_ ((struct frame *, XftFont *)); #endif @@ -966,7 +978,10 @@ x_set_cursor_gc (s) struct glyph_string *s; { - if (s->font == FRAME_FONT (s->f) + //s->face = FACE_FROM_ID(s->f, CURSOR_FACE_ID); + s->gc = s->f->output_data.x->cursor_gc; + return; + if (s->xftfont == FRAME_FONT (s->f) && s->face->background == FRAME_BACKGROUND_PIXEL (s->f) && s->face->foreground == FRAME_FOREGROUND_PIXEL (s->f) && !s->cmp) @@ -997,9 +1012,9 @@ } IF_DEBUG (x_check_font (s->f, s->font)); - xgcv.font = s->font->fid; + //xgcv.font = s->font->fid; xgcv.graphics_exposures = False; - mask = GCForeground | GCBackground | GCFont | GCGraphicsExposures; + mask = GCForeground | GCBackground | /*GCFont |*/ GCGraphicsExposures; if (FRAME_X_DISPLAY_INFO (s->f)->scratch_cursor_gc) XChangeGC (s->display, FRAME_X_DISPLAY_INFO (s->f)->scratch_cursor_gc, @@ -1090,6 +1105,7 @@ if (s->hl == DRAW_NORMAL_TEXT) { + s->face->reverse_color = 0; s->gc = s->face->gc; s->stippled_p = s->face->stipple != 0; } @@ -1100,6 +1116,7 @@ } else if (s->hl == DRAW_CURSOR) { + s->face->reverse_color = 1; x_set_cursor_gc (s); s->stippled_p = 0; } @@ -1202,7 +1219,7 @@ XSetFillStyle (s->display, s->gc, FillSolid); s->background_filled_p = 1; } - else if (FONT_HEIGHT (s->font) < s->height - 2 * box_line_width + else if (FONT_HEIGHT (s->xftfont) < s->height - 2 * box_line_width || s->font_not_found_p || s->extends_to_end_of_line_p || force_p) @@ -1216,6 +1233,61 @@ } +#ifdef HAVE_XFT + +/* Get the colors from the graphics context so that + we can render the xft colors correctly (without changing + too much old code). + + FIXME: pretty much unnecessary if we are only going to be + using Xft. + */ + +static void +x_get_colors_from_gc (s, fgcolor, bgcolor) + struct glyph_string *s; + XftColor *fgcolor; + XftColor *bgcolor; +{ + GC gc = s->gc; + Drawable d = FRAME_X_WINDOW(s->f); + XGCValues vals; + XWindowAttributes info; + + XGetWindowAttributes(FRAME_X_DISPLAY(s->f), (Window) d, &info); + XGetGCValues(FRAME_X_DISPLAY(s->f), gc, GCBackground | GCForeground, &vals); + + if (fgcolor) + { + XColor newcolor; + fgcolor->pixel = vals.foreground; + newcolor.pixel = vals.foreground; + XQueryColor(FRAME_X_DISPLAY(s->f), info.colormap, &newcolor); + fgcolor->color.red = newcolor.red; + fgcolor->color.green = newcolor.green; + fgcolor->color.blue = newcolor.blue; + fgcolor->color.alpha = 0xffff; + } + if (bgcolor) + { + XColor newcolor; +#ifdef DEBUG_XFT_HEIGHTS + bgcolor->pixel = 0xff00; + newcolor.pixel = 0xff00; +#else + bgcolor->pixel = vals.background; + newcolor.pixel = vals.background; +#endif + XQueryColor(FRAME_X_DISPLAY(s->f), info.colormap, &newcolor); + bgcolor->color.red = newcolor.red; + bgcolor->color.blue = newcolor.blue; + bgcolor->color.green = newcolor.green; + bgcolor->color.alpha = 0xffff; + } +} + +#endif + /* Draw the foreground of glyph string S. */ static void @@ -1266,28 +1338,93 @@ if (s->for_overlaps_p || (s->background_filled_p && s->hl != DRAW_CURSOR)) { - /* Draw characters with 16-bit or 8-bit functions. */ - if (s->two_byte_p) - XDrawString16 (s->display, s->window, s->gc, x, - s->ybase - boff, s->char2b, s->nchars); - else - XDrawString (s->display, s->window, s->gc, x, - s->ybase - boff, char1b, s->nchars); +#ifndef HAVE_XFT +#define HAVE_XFT_VAL 0 +#else +#define HAVE_XFT_VAL 1 +#endif + if (!x_use_xft || !(HAVE_XFT_VAL)) + { + /* Draw characters with 16-bit or 8-bit functions. */ + if (s->two_byte_p) + XDrawString16 (s->display, s->window, s->gc, x, + s->ybase - boff, s->char2b, s->nchars); + else + XDrawString (s->display, s->window, s->gc, x, + s->ybase - boff, char1b, s->nchars); + } + else + { +#ifdef HAVE_XFT + XftColor *foreground; + + //x_get_colors_from_gc (s, &foreground, NULL); + foreground = &(s->face->xftforeground); + if (s->two_byte_p) + XftDrawString16 (s->face->draw, foreground, s->face->xftfont, x, s->ybase, (unsigned short *) s->char2b, s->nchars); + else + XftDrawString8 (s->face->draw, foreground, s->face->xftfont, x, s->ybase, char1b, s->nchars); +#endif + } } else { - if (s->two_byte_p) - XDrawImageString16 (s->display, s->window, s->gc, x, - s->ybase - boff, s->char2b, s->nchars); + if (!x_use_xft || !(HAVE_XFT_VAL)) + { + if (s->two_byte_p) + XDrawImageString16 (s->display, s->window, s->gc, x, + s->ybase - boff, s->char2b, s->nchars); + else + XDrawImageString (s->display, s->window, s->gc, x, + s->ybase - boff, char1b, s->nchars); + } else - XDrawImageString (s->display, s->window, s->gc, x, - s->ybase - boff, char1b, s->nchars); + { +#ifdef HAVE_XFT + XftColor *foreground, *background; + + //x_get_colors_from_gc (s, &foreground, &background); + if (!s->face->reverse_color) { + foreground = &(s->face->xftforeground); + background = &(s->face->xftbackground); + } else { + foreground = &(s->face->xftbackground); + background = &(s->face->xftforeground); + } + if (s->two_byte_p) + { + int width, height; + XGlyphInfo extents; + XftTextExtents16 (s->display, s->face->xftfont, (unsigned short *) s->char2b, s->nchars, &extents); + width = extents.xOff; + height = s->face->xftfont->ascent + s->face->xftfont->descent; + + XftDrawRect (s->face->draw, background, x, s->ybase - s->face->xftfont->ascent, width, height); + XftDrawString16 (s->face->draw, foreground, s->face->xftfont, x, s->ybase, (unsigned short *) s->char2b, s->nchars); + } + else + { + int width, height; + int a, d; + XGlyphInfo extents; + XftTextExtents8 (s->display, s->face->xftfont, char1b, s->nchars, &extents); + width = extents.xOff; + height = s->face->xftfont->ascent + s->face->xftfont->descent; + a = s->face->xftfont->ascent; + d = s->face->xftfont->descent; + + XftDrawRect (s->face->draw, background, x, s->ybase - a, width, height); + XftDrawString8 (s->face->draw, foreground, s->face->xftfont, x, s->ybase, char1b, s->nchars); + } +#endif + } } - if (s->face->overstrike) + if (0 && s->face->overstrike) { /* For overstriking (to simulate bold-face), draw the characters again shifted to the right by one pixel. */ + printf("overstrike\n"); if (s->two_byte_p) XDrawString16 (s->display, s->window, s->gc, x + 1, s->ybase - boff, s->char2b, s->nchars); @@ -2615,8 +2752,9 @@ unsigned long tem, h; int y; + // FIXME -- cmg /* Get the underline thickness. Default is 1 pixel. */ - if (!XGetFontProperty (s->font, XA_UNDERLINE_THICKNESS, &h)) + //if (!XGetFontProperty (s->font, XA_UNDERLINE_THICKNESS, &h)) h = 1; /* Get the underline position. This is the recommended @@ -2627,12 +2765,15 @@ ROUND ((maximum descent) / 2), with ROUND(x) = floor (x + 0.5) */ + /* FIXME -- cmg + if (x_use_underline_position_properties && XGetFontProperty (s->font, XA_UNDERLINE_POSITION, &tem)) y = s->ybase + (long) tem; else if (s->face->font) y = s->ybase + (s->face->font->max_bounds.descent + 1) / 2; else + */ y = s->y + s->height - h; if (s->face->underline_defaulted_p) @@ -4772,7 +4913,7 @@ left + VERTICAL_SCROLL_BAR_WIDTH_TRIM, top, width - VERTICAL_SCROLL_BAR_WIDTH_TRIM * 2, - height, + 1, /* Border width, depth, class, and visual. */ 0, CopyFromParent, @@ -4993,6 +5134,9 @@ width = WINDOW_CONFIG_SCROLL_BAR_COLS (w) * FRAME_COLUMN_WIDTH (f); height = window_height; + // FIXME -- cmg + width = 2 * FRAME_COLUMN_WIDTH (f); + /* Compute the left edge of the scroll bar area. */ left = WINDOW_SCROLL_BAR_AREA_X (w); @@ -5026,8 +5170,11 @@ left, top, width, height, False); UNBLOCK_INPUT; } - - bar = x_scroll_bar_create (w, top, sb_left, sb_width, height); + // FIXME -- cmg + //bar = x_scroll_bar_create (w, top, sb_left, 10 /*sb_width*/, height); + BLOCK_INPUT; + bar = x_scroll_bar_create (w, top, sb_left, 10, height); + UNBLOCK_INPUT; } else { @@ -5118,6 +5265,11 @@ wc.y = top; wc.width = sb_width - VERTICAL_SCROLL_BAR_WIDTH_TRIM * 2; wc.height = height; + + wc.x = 10; + wc.y = 1; + wc.height = 10; + wc.width = 10; XConfigureWindow (FRAME_X_DISPLAY (f), SCROLL_BAR_X_WINDOW (bar), mask, &wc); } @@ -7939,52 +8073,27 @@ struct frame *f; register char *fontname; { - struct font_info *fontp - = FS_LOAD_FONT (f, 0, fontname, -1); - - if (!fontp) - return Qnil; - - FRAME_FONT (f) = (XFontStruct *) (fontp->font); - FRAME_BASELINE_OFFSET (f) = fontp->baseline_offset; + //FRAME_FONT(f) = XftFontOpenXlfd (FRAME_X_DISPLAY (f), DefaultScreen (FRAME_X_DISPLAY (f)), fontname); + char *foo = "-adobe-helvetica-medium-r-narrow--*-*-*-*-*-0-iso8859-1"; + FcPattern *pat; + XftFont *fon; + + //pat = XftXlfdParse (foo, 1, 0); + //if(!pat) return Qnil; + fon = XftFontOpenXlfd (FRAME_X_DISPLAY (f), DefaultScreen (FRAME_X_DISPLAY (f)), fontname); + //fon = XftFontOpenPattern (FRAME_X_DISPLAY (f), pat); + if(!fon) return Qnil; + FRAME_FONT(f) = fon; + //free(pat); + FRAME_BASELINE_OFFSET (f) = 0; FRAME_FONTSET (f) = -1; - FRAME_COLUMN_WIDTH (f) = FONT_WIDTH (FRAME_FONT (f)); + FRAME_COLUMN_WIDTH (f) = FONT_WIDTH (FRAME_FONT (f)) + 2; FRAME_LINE_HEIGHT (f) = FONT_HEIGHT (FRAME_FONT (f)); - - compute_fringe_widths (f, 1); - - /* Compute the scroll bar width in character columns. */ - if (FRAME_CONFIG_SCROLL_BAR_WIDTH (f) > 0) - { - int wid = FRAME_COLUMN_WIDTH (f); - FRAME_CONFIG_SCROLL_BAR_COLS (f) - = (FRAME_CONFIG_SCROLL_BAR_WIDTH (f) + wid-1) / wid; - } - else - { - int wid = FRAME_COLUMN_WIDTH (f); - FRAME_CONFIG_SCROLL_BAR_COLS (f) = (14 + wid - 1) / wid; - } - - /* Now make the frame display the given font. */ - if (FRAME_X_WINDOW (f) != 0) - { - XSetFont (FRAME_X_DISPLAY (f), f->output_data.x->normal_gc, - FRAME_FONT (f)->fid); - XSetFont (FRAME_X_DISPLAY (f), f->output_data.x->reverse_gc, - FRAME_FONT (f)->fid); - XSetFont (FRAME_X_DISPLAY (f), f->output_data.x->cursor_gc, - FRAME_FONT (f)->fid); - - /* Don't change the size of a tip frame; there's no point in - doing it because it's done in Fx_show_tip, and it leads to - problems because the tip frame has no widget. */ - if (NILP (tip_frame) || XFRAME (tip_frame) != f) - x_set_window_size (f, 0, FRAME_COLS (f), FRAME_LINES (f)); - } - - return build_string (fontp->full_name); + FRAME_BASELINE_OFFSET (f) = 0; + if (FRAME_X_WINDOW (f) != 0) + x_set_window_size (f, 0, FRAME_COLS (f), FRAME_LINES (f)); + return FRAME_FONT (f) ? build_string (fontname) : Qnil; } /* Give frame F the fontset named FONTSETNAME as its default font, and @@ -9496,288 +9604,14 @@ int size; int maxnames; { - Lisp_Object list = Qnil, patterns, newlist = Qnil, key = Qnil; - Lisp_Object tem, second_best; - struct x_display_info *dpyinfo - = f ? FRAME_X_DISPLAY_INFO (f) : x_display_list; - Display *dpy = dpyinfo->display; - int try_XLoadQueryFont = 0; - int count; - int allow_auto_scaled_font = 0; - - if (size < 0) - { - allow_auto_scaled_font = 1; - size = 0; - } - - patterns = Fassoc (pattern, Valternate_fontname_alist); - if (NILP (patterns)) - patterns = Fcons (pattern, Qnil); - - if (maxnames == 1 && !size) - /* We can return any single font matching PATTERN. */ - try_XLoadQueryFont = 1; - - for (; CONSP (patterns); patterns = XCDR (patterns)) - { - int num_fonts; - char **names = NULL; - - pattern = XCAR (patterns); - /* See if we cached the result for this particular query. - The cache is an alist of the form: - ((((PATTERN . MAXNAMES) . SCALABLE) (FONTNAME . WIDTH) ...) ...) */ - tem = XCDR (dpyinfo->name_list_element); - key = Fcons (Fcons (pattern, make_number (maxnames)), - allow_auto_scaled_font ? Qt : Qnil); - list = Fassoc (key, tem); - if (!NILP (list)) - { - list = Fcdr_safe (list); - /* We have a cashed list. Don't have to get the list again. */ - goto label_cached; - } - - /* At first, put PATTERN in the cache. */ - - BLOCK_INPUT; - count = x_catch_errors (dpy); - - if (try_XLoadQueryFont) - { - XFontStruct *font; - unsigned long value; - - font = XLoadQueryFont (dpy, SDATA (pattern)); - if (x_had_errors_p (dpy)) - { - /* This error is perhaps due to insufficient memory on X - server. Let's just ignore it. */ - font = NULL; - x_clear_errors (dpy); - } - - if (font - && XGetFontProperty (font, XA_FONT, &value)) - { - char *name = (char *) XGetAtomName (dpy, (Atom) value); - int len = strlen (name); - char *tmp; - - /* If DXPC (a Differential X Protocol Compressor) - Ver.3.7 is running, XGetAtomName will return null - string. We must avoid such a name. */ - if (len == 0) - try_XLoadQueryFont = 0; - else - { - num_fonts = 1; - names = (char **) alloca (sizeof (char *)); - /* Some systems only allow alloca assigned to a - simple var. */ - tmp = (char *) alloca (len + 1); names[0] = tmp; - bcopy (name, names[0], len + 1); - XFree (name); - } - } - else - try_XLoadQueryFont = 0; - - if (font) - XFreeFont (dpy, font); - } - - if (!try_XLoadQueryFont) - { - /* We try at least 10 fonts because XListFonts will return - auto-scaled fonts at the head. */ - if (maxnames < 0) - { - int limit; - - for (limit = 500;;) - { - names = XListFonts (dpy, SDATA (pattern), limit, &num_fonts); - if (num_fonts == limit) - { - BLOCK_INPUT; - XFreeFontNames (names); - UNBLOCK_INPUT; - limit *= 2; - } - else - break; - } - } - else - names = XListFonts (dpy, SDATA (pattern), max (maxnames, 10), - &num_fonts); - - if (x_had_errors_p (dpy)) - { - /* This error is perhaps due to insufficient memory on X - server. Let's just ignore it. */ - names = NULL; - x_clear_errors (dpy); - } - } - - x_uncatch_errors (dpy, count); - UNBLOCK_INPUT; - - if (names) - { - int i; - - /* Make a list of all the fonts we got back. - Store that in the font cache for the display. */ - for (i = 0; i < num_fonts; i++) - { - int width = 0; - char *p = names[i]; - int average_width = -1, resx = 0, dashes = 0; - - /* Count the number of dashes in NAMES[I]. If there are - 14 dashes, the field value following 9th dash - (RESOLUTION_X) is nonzero, and the field value - following 12th dash (AVERAGE_WIDTH) is 0, this is a - auto-scaled font which is usually too ugly to be used - for editing. Let's ignore it. */ - while (*p) - if (*p++ == '-') - { - dashes++; - if (dashes == 7) /* PIXEL_SIZE field */ - width = atoi (p); - else if (dashes == 9) - resx = atoi (p); - else if (dashes == 12) /* AVERAGE_WIDTH field */ - average_width = atoi (p); - } - - if (allow_auto_scaled_font - || dashes < 14 || average_width != 0 || resx == 0) - { - tem = build_string (names[i]); - if (NILP (Fassoc (tem, list))) - { - if (STRINGP (Vx_pixel_size_width_font_regexp) - && ((fast_c_string_match_ignore_case - (Vx_pixel_size_width_font_regexp, names[i])) - >= 0)) - /* We can set the value of PIXEL_SIZE to the - width of this font. */ - list = Fcons (Fcons (tem, make_number (width)), list); - else - /* For the moment, width is not known. */ - list = Fcons (Fcons (tem, Qnil), list); - } - } - } - - if (!try_XLoadQueryFont) - { - BLOCK_INPUT; - XFreeFontNames (names); - UNBLOCK_INPUT; - } - } - - /* Now store the result in the cache. */ - XSETCDR (dpyinfo->name_list_element, - Fcons (Fcons (key, list), XCDR (dpyinfo->name_list_element))); - - label_cached: - if (NILP (list)) continue; /* Try the remaining alternatives. */ - - newlist = second_best = Qnil; - /* Make a list of the fonts that have the right width. */ - for (; CONSP (list); list = XCDR (list)) - { - int found_size; - - tem = XCAR (list); - - if (!CONSP (tem) || NILP (XCAR (tem))) - continue; - if (!size) - { - newlist = Fcons (XCAR (tem), newlist); - continue; - } - - if (!INTEGERP (XCDR (tem))) - { - /* Since we have not yet known the size of this font, we - must try slow function call XLoadQueryFont. */ - XFontStruct *thisinfo; - - BLOCK_INPUT; - count = x_catch_errors (dpy); - thisinfo = XLoadQueryFont (dpy, - SDATA (XCAR (tem))); - if (x_had_errors_p (dpy)) - { - /* This error is perhaps due to insufficient memory on X - server. Let's just ignore it. */ - thisinfo = NULL; - x_clear_errors (dpy); - } - x_uncatch_errors (dpy, count); - UNBLOCK_INPUT; - - if (thisinfo) - { - XSETCDR (tem, - (thisinfo->min_bounds.width == 0 - ? make_number (0) - : make_number (thisinfo->max_bounds.width))); - BLOCK_INPUT; - XFreeFont (dpy, thisinfo); - UNBLOCK_INPUT; - } - else - /* For unknown reason, the previous call of XListFont had - returned a font which can't be opened. Record the size - as 0 not to try to open it again. */ - XSETCDR (tem, make_number (0)); - } - - found_size = XINT (XCDR (tem)); - if (found_size == size) - newlist = Fcons (XCAR (tem), newlist); - else if (found_size > 0) - { - if (NILP (second_best)) - second_best = tem; - else if (found_size < size) - { - if (XINT (XCDR (second_best)) > size - || XINT (XCDR (second_best)) < found_size) - second_best = tem; - } - else - { - if (XINT (XCDR (second_best)) > size - && XINT (XCDR (second_best)) > found_size) - second_best = tem; - } - } - } - if (!NILP (newlist)) - break; - else if (!NILP (second_best)) - { - newlist = Fcons (XCAR (second_best), Qnil); - break; - } - } - - return newlist; + Lisp_Object list; + Lisp_Object str; + str = build_string("-adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso8859-1"); + list = Fcons(str, Qnil); + list = Fcons(build_string("fixed"), list); + return list; } - #if GLYPH_DEBUG /* Check that FONT is valid on frame F. It is if it can be found in F's @@ -9786,7 +9620,7 @@ static void x_check_font (f, font) struct frame *f; - XFontStruct *font; + XftFont *font; { int i; struct x_display_info *dpyinfo = FRAME_X_DISPLAY_INFO (f); @@ -9804,24 +9638,27 @@ #endif /* GLYPH_DEBUG != 0 */ /* Set *W to the minimum width, *H to the minimum font height of FONT. - Note: There are (broken) X fonts out there with invalid XFontStruct + Note: There are (broken) X fonts out there with invalid XftFont min_bounds contents. For example, handa@etl.go.jp reports that "-adobe-courier-medium-r-normal--*-180-*-*-m-*-iso8859-1" fonts have font->min_bounds.width == 0. */ static INLINE void x_font_min_bounds (font, w, h) - XFontStruct *font; + XftFont *font; int *w, *h; { *h = FONT_HEIGHT (font); - *w = font->min_bounds.width; + //*w = font->min_bounds.width; + *w = font->max_advance_width; /* Try to handle the case where FONT->min_bounds has invalid contents. Since the only font known to have invalid min_bounds is fixed-width, use max_bounds if min_bounds seems to be invalid. */ +#if 0 if (*w <= 0) *w = font->max_bounds.width; +#endif } @@ -9837,7 +9674,7 @@ { int i; struct x_display_info *dpyinfo = FRAME_X_DISPLAY_INFO (f); - XFontStruct *font; + XftFont *font; int old_width = dpyinfo->smallest_char_width; int old_height = dpyinfo->smallest_font_height; @@ -9850,8 +9687,8 @@ struct font_info *fontp = dpyinfo->font_table + i; int w, h; - font = (XFontStruct *) fontp->font; - xassert (font != (XFontStruct *) ~0); + font = (XftFont *) fontp->font; + xassert (font != (XftFont *) ~0); x_font_min_bounds (font, &w, &h); dpyinfo->smallest_font_height = min (dpyinfo->smallest_font_height, h); @@ -9882,6 +9719,7 @@ Lisp_Object font_names; int count; +#if 0 /* Get a list of all the fonts that match this name. Once we have a list of matching fonts, we compare them against the fonts we already have by comparing names. */ @@ -9901,11 +9739,11 @@ SDATA (XCAR (tail))))) return (dpyinfo->font_table + i); } - +#endif /* Load the font and add it to the table. */ { char *full_name; - XFontStruct *font; + XftFont *font; struct font_info *fontp; unsigned long value; int i; @@ -9920,7 +9758,8 @@ BLOCK_INPUT; count = x_catch_errors (FRAME_X_DISPLAY (f)); - font = (XFontStruct *) XLoadQueryFont (FRAME_X_DISPLAY (f), fontname); + //font = (XftFont *) XLoadQueryFont (FRAME_X_DISPLAY (f), fontname); + font = XftFontOpenXlfd (FRAME_X_DISPLAY (f), DefaultScreen(FRAME_X_DISPLAY(f)), fontname); if (x_had_errors_p (FRAME_X_DISPLAY (f))) { /* This error is perhaps due to insufficient memory on X @@ -9961,6 +9800,7 @@ fontp->name = (char *) xmalloc (strlen (fontname) + 1); bcopy (fontname, fontp->name, strlen (fontname) + 1); +#if 0 /* Try to get the full name of FONT. Put it in FULL_NAME. */ full_name = 0; if (XGetFontProperty (font, XA_FONT, &value)) @@ -9994,8 +9834,12 @@ fontp->full_name = full_name; else fontp->full_name = fontp->name; +#else + fontp->full_name = fontp->name; +#endif - fontp->size = font->max_bounds.width; + //fontp->size = font->max_bounds.width; + fontp->size = font->max_advance_width; fontp->height = FONT_HEIGHT (font); if (NILP (font_names)) @@ -10035,6 +9879,7 @@ uses this font. So, we set information in fontp->encoding[1] which is never used by any charset. If mapping can't be decided, set FONT_ENCODING_NOT_DECIDED. */ +#if 0 fontp->encoding[1] = (font->max_byte1 == 0 /* 1-byte font */ @@ -10067,6 +9912,12 @@ fontp->default_ascent = (XGetFontProperty (font, dpyinfo->Xatom_MULE_DEFAULT_ASCENT, &value) ? (long) value : 0); +#else + fontp->encoding[1] = FONT_ENCODING_NOT_DECIDED; + fontp->baseline_offset = 0; + fontp->relative_compose = 0; + fontp->default_ascent = font->ascent; +#endif /* Set global flag fonts_changed_p to non-zero if the font loaded has a character with a smaller width than any other character @@ -10978,6 +10829,10 @@ to 4.1, set this to nil. */); x_use_underline_position_properties = 1; + DEFVAR_BOOL ("x-use-xft", &x_use_xft, + doc: /* *Non-nil means to use Xft for anti-aliasing */); + x_use_xft = 1; + DEFVAR_LISP ("x-toolkit-scroll-bars", &Vx_toolkit_scroll_bars, doc: /* What X toolkit scroll bars Emacs uses. A value of nil means Emacs doesn't use X toolkit scroll bars. diff -u --recursive xft-base/src/xterm.h xft/src.xft/xterm.h --- xft-base/src/xterm.h 2005-03-10 18:22:58.409283431 -0500 +++ xft/src.xft/xterm.h 2005-03-10 18:18:05.413347398 -0500 @@ -26,6 +26,8 @@ #include <X11/Xatom.h> #include <X11/Xresource.h> +#include <X11/Xft/Xft.h> + #ifdef USE_X_TOOLKIT #include <X11/StringDefs.h> #include <X11/IntrinsicP.h> /* CoreP.h needs this */ @@ -99,7 +101,8 @@ #define WHITE_PIX_DEFAULT(f) WhitePixel (FRAME_X_DISPLAY (f), \ XScreenNumberOfScreen (FRAME_X_SCREEN (f))) -#define FONT_WIDTH(f) ((f)->max_bounds.width) +// FIXME -- cmg +#define FONT_WIDTH(f) ((f)->max_advance_width) #define FONT_HEIGHT(f) ((f)->ascent + (f)->descent) #define FONT_BASE(f) ((f)->ascent) #define FONT_DESCENT(f) ((f)->descent) @@ -503,7 +506,7 @@ int icon_bitmap; /* Default ASCII font of this frame. */ - XFontStruct *font; + XftFont *font; /* The baseline offset of the default ASCII font. */ int baseline_offset; @@ -730,6 +733,7 @@ /* Value is the smallest width of any character in any font on frame F. */ +#if 0 #define FRAME_SMALLEST_CHAR_WIDTH(F) \ FRAME_X_DISPLAY_INFO(F)->smallest_char_width @@ -737,6 +741,10 @@ #define FRAME_SMALLEST_FONT_HEIGHT(F) \ FRAME_X_DISPLAY_INFO(F)->smallest_font_height +#else +#define FRAME_SMALLEST_CHAR_WIDTH(F) 4 +#define FRAME_SMALLEST_FONT_HEIGHT(f) 3 +#endif /* Return a pointer to the image cache of frame F. */ [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-19 16:31 ` Stefan Monnier @ 2005-03-19 16:53 ` Han Boetes 2005-03-20 11:51 ` Jan D. 2005-03-19 21:41 ` Miles Bader ` (2 subsequent siblings) 3 siblings, 1 reply; 44+ messages in thread From: Han Boetes @ 2005-03-19 16:53 UTC (permalink / raw) > - if (s-> font == NULL) > + if (0 && s-> font == NULL) I suppose this is a mistake. # Han ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-19 16:53 ` Han Boetes @ 2005-03-20 11:51 ` Jan D. 0 siblings, 0 replies; 44+ messages in thread From: Jan D. @ 2005-03-20 11:51 UTC (permalink / raw) Cc: emacs-devel Han Boetes wrote: >>- if (s-> font == NULL) >>+ if (0 && s-> font == NULL) >> >> > >I suppose this is a mistake. > As the font is hardcoded it should always be found. It may be that in the case of Xft s->font is NULL always. I agree it looks strange, but I also use this device sometimes to "comment out" if/while/for statements. Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-19 16:31 ` Stefan Monnier 2005-03-19 16:53 ` Han Boetes @ 2005-03-19 21:41 ` Miles Bader 2005-03-20 13:15 ` Jan D. 2005-03-20 22:51 ` Jan D. 3 siblings, 0 replies; 44+ messages in thread From: Miles Bader @ 2005-03-19 21:41 UTC (permalink / raw) Cc: Jan D., emacs-devel, Ali Ijaz Sheikh, miles On Sat, 19 Mar 2005 11:31:35 -0500, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > I have started on Xft support, but it is really something for the release > > after the next, so I don't spend much time on it yet. I can confirm your > > reasoning, the Emacs font-selection machinery is indeed the most tricky > > part, I have not done that fully, so I can't change font yet. But part of > > the problem is that the Xft font selection is entirely new compared to the > > old X font selection. > > Feel free to put it on an Arch branch somewhere, or a branch in the CVS ;-) That would be nice... I'm particularly interested to about see whether it conflicts with my background-image hacks (though I was similarly nervous about your GTK port, and there ended up being very little problem in that instance). -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-19 16:31 ` Stefan Monnier 2005-03-19 16:53 ` Han Boetes 2005-03-19 21:41 ` Miles Bader @ 2005-03-20 13:15 ` Jan D. 2005-03-20 22:51 ` Jan D. 3 siblings, 0 replies; 44+ messages in thread From: Jan D. @ 2005-03-20 13:15 UTC (permalink / raw) Cc: emacs-devel Stefan Monnier wrote: > I don't think you wasted your time, but in case you're interested, I've > >appended a patch I extracted from that xft branch at some point. I had some >trouble extracting the patch, so there might be some missing bits and some >unrelated extra bits. It surely doesn't compile. > > > Thank you. Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-19 16:31 ` Stefan Monnier ` (2 preceding siblings ...) 2005-03-20 13:15 ` Jan D. @ 2005-03-20 22:51 ` Jan D. 2005-03-22 23:44 ` Miles Bader 3 siblings, 1 reply; 44+ messages in thread From: Jan D. @ 2005-03-20 22:51 UTC (permalink / raw) Cc: miles, snogglethorpe, Ali Ijaz Sheikh, emacs-devel Stefan Monnier wrote: >>I have started on Xft support, but it is really something for the release >>after the next, so I don't spend much time on it yet. I can confirm your >>reasoning, the Emacs font-selection machinery is indeed the most tricky >>part, I have not done that fully, so I can't change font yet. But part of >>the problem is that the Xft font selection is entirely new compared to the >>old X font selection. >> >> > >Feel free to put it on an Arch branch somewhere, or a branch in the CVS ;-) > > Okay, I've made a branch in CVS, tag is XFT_JHD_BRANCH (jhd is my initials). I hope I didn't breake anything in CVS :-). The font selection is incomplete, so you have to specify a font on the command line, like so: % emacs -fn monospace-12 (or any other font you prefer). Since the font selection is incomplete, the font choosen when no font is given is helvetica (a proportional font). I'm sure there are drawing errors (I've sen some myself) and other errors. Feel free to drop a me a mail about bugs you see, but I don't expect to spend any time on this until the current release is out of the door. Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-20 22:51 ` Jan D. @ 2005-03-22 23:44 ` Miles Bader 2005-03-23 2:30 ` Miles Bader 2005-03-23 17:50 ` Jan D. 0 siblings, 2 replies; 44+ messages in thread From: Miles Bader @ 2005-03-22 23:44 UTC (permalink / raw) Cc: miles, Stefan Monnier, Ali Ijaz Sheikh, emacs-devel On Sun, 20 Mar 2005 23:51:37 +0100, Jan D. <jan.h.d@swipnet.se> wrote: > Okay, I've made a branch in CVS, tag is XFT_JHD_BRANCH (jhd is my > initials). I hope I didn't breake anything in CVS :-) BTW, any time you make a branch tag, it's also good to make a corresponding non-branch `base' tag which is the trunk version the branch is relative too. This info is deducible (though tiresome to do) from the branch versions _until_ you decide to merge updates from the trunk, at which point it's not... [whereas if you have base tag, you update the base tag when you do the merge] You can see this in many other Emacs branches, e.g., `emacs-unicode-2' (the branch tag), and `emacs-unicode-2-base' (the corresponding non-branch base tag). [I don't have one for `lexbind', but that's because I'm lazy and do merging via other means.] -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-22 23:44 ` Miles Bader @ 2005-03-23 2:30 ` Miles Bader 2005-03-23 17:50 ` Jan D. 1 sibling, 0 replies; 44+ messages in thread From: Miles Bader @ 2005-03-23 2:30 UTC (permalink / raw) Cc: Ali Ijaz Sheikh, miles FWIW, I've added Jan's branch to my arch archive as "emacs--xft-jhd--0". -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-22 23:44 ` Miles Bader 2005-03-23 2:30 ` Miles Bader @ 2005-03-23 17:50 ` Jan D. 2005-03-25 21:40 ` Miles Bader 1 sibling, 1 reply; 44+ messages in thread From: Jan D. @ 2005-03-23 17:50 UTC (permalink / raw) Cc: Emacs-Devel Devel > BTW, any time you make a branch tag, it's also good to make a > corresponding non-branch `base' tag which is the trunk version the > branch is relative too. This info is deducible (though tiresome to > do) from the branch versions _until_ you decide to merge updates from > the trunk, at which point it's not... [whereas if you have base tag, > you update the base tag when you do the merge] Thanks for the tip. Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-23 17:50 ` Jan D. @ 2005-03-25 21:40 ` Miles Bader 2005-03-26 8:13 ` Jan D. 0 siblings, 1 reply; 44+ messages in thread From: Miles Bader @ 2005-03-25 21:40 UTC (permalink / raw) Cc: Emacs-Devel Devel, Miles Bader On Wed, 23 Mar 2005 18:50:53 +0100, Jan D. <jan.h.d@swipnet.se> wrote: > > BTW, any time you make a branch tag, it's also good to make a > > corresponding non-branch `base' tag which is the trunk version the > > branch is relative too. > > Thanks for the tip. I notice you've done this, but it seems a bit odd -- For files that you've modified it looks correct, e.g. "src/xdisp.c": XFT_JHD_BRANCH_base: 1.992 XFT_JHD_BRANCH: 1.992.0.2 But for files that you _haven't _ changed, it seems wrong, e.g., "src/editfns.c": XFT_JHD_BRANCH_base: 1.389.0.4 XFT_JHD_BRANCH: 1.389.0.2 The "..._base" tag is branch tag when it shouldn't be. Thanks, -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-25 21:40 ` Miles Bader @ 2005-03-26 8:13 ` Jan D. 2005-03-29 10:52 ` Geoffrey J. Teale 0 siblings, 1 reply; 44+ messages in thread From: Jan D. @ 2005-03-26 8:13 UTC (permalink / raw) Cc: Emacs-Devel Devel > I notice you've done this, but it seems a bit odd -- > > For files that you've modified it looks correct, e.g. "src/xdisp.c": > > XFT_JHD_BRANCH_base: 1.992 > XFT_JHD_BRANCH: 1.992.0.2 > > But for files that you _haven't _ changed, it seems wrong, e.g., > "src/editfns.c": > > XFT_JHD_BRANCH_base: 1.389.0.4 > XFT_JHD_BRANCH: 1.389.0.2 > > The "..._base" tag is branch tag when it shouldn't be. Thanks for checking this. I only confirmed that the tag was on the correct version, I didn't know about these CVS special versions. I've fixed it now (and read some more about CVS branching in general :-). Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-26 8:13 ` Jan D. @ 2005-03-29 10:52 ` Geoffrey J. Teale 2005-03-29 11:28 ` Miles Bader 2005-03-29 19:28 ` Jan D. 0 siblings, 2 replies; 44+ messages in thread From: Geoffrey J. Teale @ 2005-03-29 10:52 UTC (permalink / raw) Cc: Emacs-Devel Devel, Miles Bader Hi, I've just checked out and built this branch a couple of times (once with Gtk once with LUCID). In both cases I noticed that there were a lot of artifacts being left around, in fact it seams that buffers and mini-buffer are only being redrawn when I resize the emacs window. If I don't resize the window everything quickly becomes unreadable. I assume this is just a result of the current, early state of development, but just in case I'm the only one experiencing this problem I though I'd mention it -- Geoff Teale CMed Technology - gteale@cmedresearch.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-29 10:52 ` Geoffrey J. Teale @ 2005-03-29 11:28 ` Miles Bader 2005-03-29 12:24 ` Geoffrey J. Teale 2005-03-29 18:24 ` Henrik Enberg 2005-03-29 19:28 ` Jan D. 1 sibling, 2 replies; 44+ messages in thread From: Miles Bader @ 2005-03-29 11:28 UTC (permalink / raw) Cc: Jan D., Emacs-Devel Devel, Miles Bader On Tue, 29 Mar 2005 11:52:07 +0100, Geoffrey J. Teale <gteale@cmedltd.com> wrote: > I assume this is just a result of the current, early state of > development, but just in case I'm the only one experiencing this > problem I though I'd mention it I saw it too -- it doesn't seem to ever clear to background color before drawing. [There are some other odd effects like color fringing that make me wonder if it's assuming a white background.] -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-29 11:28 ` Miles Bader @ 2005-03-29 12:24 ` Geoffrey J. Teale 2005-03-29 18:24 ` Henrik Enberg 1 sibling, 0 replies; 44+ messages in thread From: Geoffrey J. Teale @ 2005-03-29 12:24 UTC (permalink / raw) Cc: Jan D., Emacs-Devel Devel, miles Miles Bader <snogglethorpe@gmail.com> writes: > I saw it too -- it doesn't seem to ever clear to background color > before drawing. > > [There are some other odd effects like color fringing that make me > wonder if it's assuming a white background.] I notice that, rather randomly, if I drag another window across some text (folder names in GNUS) the characters get thicker when I go anti-clockwise and thinner when I go clockwise. That's some kind of weird. -- Geoff Teale CMed Technology - gteale@cmedresearch.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-29 11:28 ` Miles Bader 2005-03-29 12:24 ` Geoffrey J. Teale @ 2005-03-29 18:24 ` Henrik Enberg 2005-03-29 22:50 ` Miles Bader 1 sibling, 1 reply; 44+ messages in thread From: Henrik Enberg @ 2005-03-29 18:24 UTC (permalink / raw) Cc: Emacs-Devel Devel, Jan D., Geoffrey J. Teale, miles Miles Bader <snogglethorpe@gmail.com> writes: [...] > [There are some other odd effects like color fringing that make me > wonder if it's assuming a white background.] that might be your setup. fontconfig has options for how colors should be blended, and in my experience it's basically impossible to get a good setup for both dark text/light background and vice versa. -- Vaya Con Satan ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-29 18:24 ` Henrik Enberg @ 2005-03-29 22:50 ` Miles Bader 2005-03-31 2:42 ` James Cloos 0 siblings, 1 reply; 44+ messages in thread From: Miles Bader @ 2005-03-29 22:50 UTC (permalink / raw) Cc: Emacs-Devel Devel, Jan D., Geoffrey J. Teale, miles On Tue, 29 Mar 2005 20:24:34 +0200, Henrik Enberg <henrik.enberg@telia.com> wrote: > > [There are some other odd effects like color fringing that make me > > wonder if it's assuming a white background.] > > that might be your setup. fontconfig has options for how colors should > be blended, and in my experience it's basically impossible to get a good > setup for both dark text/light background and vice versa. Er, well all my _other_ fontconfig/freetype/xft using windows (with black or black-ish backgrounds) look absolutely fabulous, so I'd point the finger at Emacs... [I didn't change anything in the fontconfig setup so it seems the default settings -- which are presumably aimed at white backgrounds -- deals pretty well with black backgrounds too.] -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-29 22:50 ` Miles Bader @ 2005-03-31 2:42 ` James Cloos 2005-03-31 4:22 ` Miles Bader 0 siblings, 1 reply; 44+ messages in thread From: James Cloos @ 2005-03-31 2:42 UTC (permalink / raw) Cc: miles >>>>> "Miles" == Miles Bader <snogglethorpe@gmail.com> writes: Miles> [I didn't change anything in the fontconfig setup so it seems Miles> the default settings -- which are presumably aimed at white Miles> backgrounds -- deals pretty well with black backgrounds too.] It does depend on the font and whether you are using the byte code interpreter. The well-instructed fonts tend to use single-pixel wide stems up to circa 16–18 ppem. The auto-fitter, however, tends to result in wider stems. Xft’s rgba filter is tuned for light backgrounds; single-pixel stems tend to drop out when it is used with dark backgrounds. So, if you are using sub-pixel rendering, the BCI and a well instructed font you will see *much* better text with a light background than with a dark. But if you are using fonts w/o quality instructions — whether poorly-instructed fonts, non- ttf fonts, or freetype compiled w/o the interpreter — and/or greyscale rather than sub-pixel then light on dark should be almost as good as dark on light text. Or at least that is what I saw back when I tested it. -JimC -- James H. Cloos, Jr. <cloos@jhcloos.com> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-31 2:42 ` James Cloos @ 2005-03-31 4:22 ` Miles Bader 0 siblings, 0 replies; 44+ messages in thread From: Miles Bader @ 2005-03-31 4:22 UTC (permalink / raw) Cc: miles, Emacs Devel On Mar 31, 2005 11:42 AM, James Cloos <cloos@jhcloos.com> wrote: > So, if you are using sub-pixel rendering, the BCI and a well > instructed font you will see *much* better text with a light > background than with a dark. But if you are using fonts w/o > quality instructions — whether poorly-instructed fonts, non- > ttf fonts, or freetype compiled w/o the interpreter — and/or > greyscale rather than sub-pixel then light on dark should be > almost as good as dark on light text. > > Or at least that is what I saw back when I tested it. Well, freetype has certainly improved _dramatically_ in recent times. I use sub-pixel rendering on an LCD, and both hinted fonts (e.g., microsoft's stuff, the vera fonts) and non-hinted latin fonts look quite spectacularly good -- almost every line you'd want to be 1-pixel wide is almost exactly that, with no obvious fringing, fuzziness, or non-uniformity, and there's no over-lightness or dropouts at all on a black background. While writing this message I tried comparing the same text in the same font (using a few fonts), and the apparent weight looks pretty much exactly the same on a black or a white background. [Whereas I've noticed that MS's font-rendering actually does look fairly crappy on a black background.] For many fonts, much of this goodness seems to be due to the auto-hinter (which is unfortunately turned off by default). Basically freetype seems to the point these days where it seems as good or better than the (much crowed about) font rendering in windows or OSX. Certainly there are always details to make better, but ... it's really, really, good. -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-29 10:52 ` Geoffrey J. Teale 2005-03-29 11:28 ` Miles Bader @ 2005-03-29 19:28 ` Jan D. 2005-04-01 8:15 ` Miles Bader 1 sibling, 1 reply; 44+ messages in thread From: Jan D. @ 2005-03-29 19:28 UTC (permalink / raw) Cc: Miles Bader, Emacs-Devel Devel Geoffrey J. Teale wrote: >Hi, > >I've just checked out and built this branch a couple of times (once >with Gtk once with LUCID). In both cases I noticed that there were a >lot of artifacts being left around, in fact it seams that buffers and >mini-buffer are only being redrawn when I resize the emacs window. If >I don't resize the window everything quickly becomes unreadable. > >I assume this is just a result of the current, early state of >development, but just in case I'm the only one experiencing this >problem I though I'd mention it > > I don't see that (but other minor redrawing errors). I suspect your version of fontconfig and/or Xrender is different from mine. I'll test this further on older X versions when Emacs has been released. You can try to modify xterm.c here: #ifdef HAVE_XFT if (! (s->for_overlaps_p || (s->background_filled_p && s->hl != DRAW_CURSOR))) XftDrawRect (s->face->xft_draw, s->hl == DRAW_CURSOR ? &s->face->xft_fg : &s->face->xft_bg, s->x, s->y, s->width + s->right_overhang, s->height); Remove the if-statement so the XftDrawRect is always done. That should improve things, but also slow drawing down somewhat. Thanks for pointing this out, Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-29 19:28 ` Jan D. @ 2005-04-01 8:15 ` Miles Bader 2005-04-01 16:09 ` Jan D. 0 siblings, 1 reply; 44+ messages in thread From: Miles Bader @ 2005-04-01 8:15 UTC (permalink / raw) Cc: Geoffrey J. Teale, Emacs-Devel Devel BTW Jan, would you accept patches for your xft branch, or do you want to work solo on this for a while? [If patches are OK, would it be better to send you patch files or just commit changes directly to the branch (well the latter obviously only for straight-forward changes)?] Thanks, -Miles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-04-01 8:15 ` Miles Bader @ 2005-04-01 16:09 ` Jan D. 0 siblings, 0 replies; 44+ messages in thread From: Jan D. @ 2005-04-01 16:09 UTC (permalink / raw) Cc: Geoffrey J. Teale, Emacs-Devel Devel > BTW Jan, would you accept patches for your xft branch, or do you want > to > work solo on this for a while? > > [If patches are OK, would it be better to send you patch files or just > commit changes directly to the branch (well the latter obviously only > for straight-forward changes)?] Just commit them to the branch so they don't get forgotten. I'll review them from there when I resume that work. Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-19 6:27 ` Jan D. 2005-03-19 7:39 ` Miles Bader 2005-03-19 16:31 ` Stefan Monnier @ 2005-03-22 12:45 ` Oliver Scholz 2005-03-22 14:21 ` Stefan 2 siblings, 1 reply; 44+ messages in thread From: Oliver Scholz @ 2005-03-22 12:45 UTC (permalink / raw) "Jan D." <jan.h.d@swipnet.se> writes: [...] > I have started on Xft support, Just one issue that might come up later. I would be grateful if you'd also think about ways to customize AA per font and/or face along the way; provided that this is feasible at all. AA may look good, but it also makes the characters look blurry which can be a source of headaches for some people who are sensitive to this. OTOH, some free scalable m17n fonts lack hinting, so they are basically unusable on a computer screen withouth AA. Being able to enable AA partially per font or face would get us the best of both worlds. Oliver -- 2 Germinal an 213 de la Révolution Liberté, Egalité, Fraternité! ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-22 12:45 ` Oliver Scholz @ 2005-03-22 14:21 ` Stefan 2005-03-22 14:29 ` Oliver Scholz 0 siblings, 1 reply; 44+ messages in thread From: Stefan @ 2005-03-22 14:21 UTC (permalink / raw) Cc: emacs-devel > Just one issue that might come up later. I would be grateful if you'd > also think about ways to customize AA per font and/or face along the > way; provided that this is feasible at all. AFAIK this can be controlled globally (for all Xft apps) with the config file (whose name escapes me just now, fonts.conf or somesuch). Stefan ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-22 14:21 ` Stefan @ 2005-03-22 14:29 ` Oliver Scholz 2005-03-22 15:17 ` David Kastrup 0 siblings, 1 reply; 44+ messages in thread From: Oliver Scholz @ 2005-03-22 14:29 UTC (permalink / raw) Cc: emacs-devel Stefan <monnier@iro.umontreal.ca> writes: >> Just one issue that might come up later. I would be grateful if you'd >> also think about ways to customize AA per font and/or face along the >> way; provided that this is feasible at all. > > AFAIK this can be controlled globally (for all Xft apps) with the config > file (whose name escapes me just now, fonts.conf or somesuch). Ah, that could solve the issue with the aforementioned m17n fonts. Still, if it is feasible, I'd prefer a face attribute like :anti-aliased or somesuch. It allows for greater flexibility when customizing the appearance of Emacs. Another issue is that the headache argument applies only to large chunks of body text. It would be nice to have e.g. the Info header faces anti-aliased, but not the body text. Oliver -- Oliver Scholz 2 Germinal an 213 de la Révolution Ostendstr. 61 Liberté, Egalité, Fraternité! 60314 Frankfurt a. M. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-22 14:29 ` Oliver Scholz @ 2005-03-22 15:17 ` David Kastrup 0 siblings, 0 replies; 44+ messages in thread From: David Kastrup @ 2005-03-22 15:17 UTC (permalink / raw) Cc: Stefan, emacs-devel Oliver Scholz <alkibiades@gmx.de> writes: > Stefan <monnier@iro.umontreal.ca> writes: > >>> Just one issue that might come up later. I would be grateful if >>> you'd also think about ways to customize AA per font and/or face >>> along the way; provided that this is feasible at all. >> >> AFAIK this can be controlled globally (for all Xft apps) with the >> config file (whose name escapes me just now, fonts.conf or >> somesuch). > > Ah, that could solve the issue with the aforementioned m17n fonts. > Still, if it is feasible, I'd prefer a face attribute like > :anti-aliased or somesuch. It allows for greater flexibility when > customizing the appearance of Emacs. It is completely contraproductive to demand exceptions and details before an implementation is even started. And it is the wrong point of time for the discussion, anyway, since it detracts from the release. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-10 22:25 ` Stefan Monnier 2005-03-10 23:15 ` Han Boetes @ 2005-03-10 23:19 ` James Cloos 2005-03-11 9:20 ` Geoffrey J. Teale 1 sibling, 1 reply; 44+ messages in thread From: James Cloos @ 2005-03-10 23:19 UTC (permalink / raw) Cc: emacs-devel >>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes: Stefan> A Cairo port will probably make sense at some point, but I Stefan> think that anti-aliasing support for X11 (using xft) is more Stefan> urgent. I suspect that the amount of work to get fontconfig/xft support on top of the current x11 gui is comparable to a cairo gui (using the x11 gui as a design reference). Of course I could be wrong on that count.... -JimC -- James H. Cloos, Jr. <cloos@jhcloos.com> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-10 23:19 ` James Cloos @ 2005-03-11 9:20 ` Geoffrey J. Teale 2005-03-11 15:13 ` Jan D. 0 siblings, 1 reply; 44+ messages in thread From: Geoffrey J. Teale @ 2005-03-11 9:20 UTC (permalink / raw) I'll stick my hand in the air here and say that I would favour people putting effort into Cairo support rather than Xft. Isn't Cairo being used in Gtk now? Could we get Cairo for free by porting the buffer to Gtk? -- Geoff Teale CMed Technology - gteale@cmedltd.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Antialiased text on X11 2005-03-11 9:20 ` Geoffrey J. Teale @ 2005-03-11 15:13 ` Jan D. 0 siblings, 0 replies; 44+ messages in thread From: Jan D. @ 2005-03-11 15:13 UTC (permalink / raw) Cc: emacs-devel > > I'll stick my hand in the air here and say that I would favour people > putting effort into Cairo support rather than Xft. > > Isn't Cairo being used in Gtk now? Could we get Cairo for free by > porting the buffer to Gtk? GTK 2.6 does not use Cairo, the development version might. As for "porting the buffer", I assume you mean that we should leave all redisplay to Gtk, by using for example the text widget? Unfortunately the redisplay in that widget is crude and simple, and is only suitable for the most simple text editing tasks. Getting Emacs to use Xft for all X ports is much more realistic. Cairo is a moving target, and from what I have seen, we still need font metrics and the like to be able to handle redisplay. Cairo only gives simple drawing primitives, this is not good enough. I haven't seen the latest Cairo sources, so this might have changed. But if we get font metrics from Cairo or Xft does not matter much, the porting work is roughly the same, so Xft is a much better target. The drawing stuff is trivial in both cases. Jan D. ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2005-04-01 16:09 UTC | newest] Thread overview: 44+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-03-10 21:45 Antialiased text on X11 James Cloos 2005-03-10 22:25 ` Stefan Monnier 2005-03-10 23:15 ` Han Boetes 2005-03-11 4:58 ` Jan D. 2005-03-18 21:21 ` Ali Ijaz Sheikh 2005-03-18 22:39 ` Drew Adams 2005-03-19 22:45 ` The WHY of Xft [was: Re: Antialiased text on X11] James Cloos 2005-03-19 23:47 ` Miles Bader 2005-03-20 16:49 ` The WHY of Xft James Cloos 2005-03-20 22:30 ` Miles Bader 2005-03-21 14:24 ` David Hansen 2005-03-21 16:12 ` James Cloos 2005-03-21 0:32 ` Kenichi Handa 2005-03-19 0:59 ` Antialiased text on X11 Miles Bader 2005-03-19 6:27 ` Jan D. 2005-03-19 7:39 ` Miles Bader 2005-03-19 16:31 ` Stefan Monnier 2005-03-19 16:53 ` Han Boetes 2005-03-20 11:51 ` Jan D. 2005-03-19 21:41 ` Miles Bader 2005-03-20 13:15 ` Jan D. 2005-03-20 22:51 ` Jan D. 2005-03-22 23:44 ` Miles Bader 2005-03-23 2:30 ` Miles Bader 2005-03-23 17:50 ` Jan D. 2005-03-25 21:40 ` Miles Bader 2005-03-26 8:13 ` Jan D. 2005-03-29 10:52 ` Geoffrey J. Teale 2005-03-29 11:28 ` Miles Bader 2005-03-29 12:24 ` Geoffrey J. Teale 2005-03-29 18:24 ` Henrik Enberg 2005-03-29 22:50 ` Miles Bader 2005-03-31 2:42 ` James Cloos 2005-03-31 4:22 ` Miles Bader 2005-03-29 19:28 ` Jan D. 2005-04-01 8:15 ` Miles Bader 2005-04-01 16:09 ` Jan D. 2005-03-22 12:45 ` Oliver Scholz 2005-03-22 14:21 ` Stefan 2005-03-22 14:29 ` Oliver Scholz 2005-03-22 15:17 ` David Kastrup 2005-03-10 23:19 ` James Cloos 2005-03-11 9:20 ` Geoffrey J. Teale 2005-03-11 15:13 ` Jan D.
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).