Am 22.03.2011 um 17:28 schrieb Jeremy Huddleston:

So X11_Legacy shows your emacs issue still? If that's the case, then it definitely sounds like this is a client issue and not a server issue.

The same client, i.e., the same C and ELisp code, when linked with libraries from Fink and /usr/X11 *or* when linked with libraries from MacPorts shows the effect when *not* running in the MacPorts X server.

Anyway, I played with X resources, made comparisons with GNU Emacs 22.3 on one side and GNU Emacsen 23.3 and 23.0.50 on the other side. The newer ones use libfontconfig, can perform font anti-aliasing, and use internal structures like default-frame-alist and initial-frame- alist. In these one can set fonts or fontsets to be used in the frame (window in X terminology). When I comment these font or fontset settings it's OK!

Almost. One font problem is left. In old GNU Emacs 22.3 (which is launched with -fn <some XLFD>), when using a 10 pt bitmapped font, for example -B&H-LucidaTypewriter-Medium-R-Normal-Sans-10-100-75-75-M-60- ISO10646-1, the lower case l is 8 pixels high. When the newer Emacsen use the X resource setting

        Emacs.font:     Avant Garde Mono ITCTT-8

then the XLFD is "xft:-unknown-Avant Garde Mono ITCTT-normal-normal- normal-*-11-*-*-*-m-0-iso10646-1" and the lower case l is 8 pixels high. With

        Emacs.font:     Avant Garde Mono ITCTT-7

the XLFD is "xft:-unknown-Avant Garde Mono ITCTT-normal-normal-normal- *-9-*-*-*-m-0-iso10646-1" and the lower case l is 7 pixels high. (This looks agreeable on my 96 – or such – DPI LC display.) Is this "scaling" correct? Or is there some "correcting" factor 96 real DPI/ 72 standard DPI? I can think of two masks, one in proper scale, the other scaled by factor 1.333 (or 1/1.333?), put on top of each other. This can explain why only a few pixels are visible through this and the text cursor is still 10 pixels high, which sounds quite reasonable (normally it seems to be 12 pixels high).


Since last year some internals of the building of a fonts set to display UTF-8 encoded text has changed, was simplified. I did not have to adjust my old code, it still seems to work somehow. But one change is obvious: Commenting the specification now makes a difference (I tried this last summer already and no change was visible). This can explain my success at last. The fault seems to be with setting a complex fontset in which fonts to be used are declared for different character code ranges.

I think, I'll test this next week or weekend. Tomorrow I'll try to install a modern X11 package, make X11_Legacy display something more reasonable than "Xquartz 1.1.4.1 - (xorg-server 1.3.0-apple15)", reactivate MacPorts... Dock shows two X11_Legacy icons!

--
Greetings

  Pete

A child of five could understand this!  Fetch me a child of five.


_______________________________________________
Xquartz-dev mailing list
Xquartz-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

Reply via email to