[Xquartz-dev] XQuartz 2.6.1_rc1
Peter Dyballa
Peter_Dyballa at Web.DE
Tue Mar 22 15:19:29 PDT 2011
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.
More information about the Xquartz-dev
mailing list