Hello!
In Mac OS X 10.5.8 (Leopard, without Snow) I have two X servers, which
identify themselves as "XQuartz 2.6.0 (xorg-server 1.9.3)". One comes from the
MacPorts project and is compiled and installed on my PowerBook G4 (PPC 7447A
CPU). The other is compiled, maybe, at Apple, based on, presumingly, the same
sources and distributed as a package to install with the usual Mac OS X
installer as a replacement for the original very old X11, built by folks who
also work in the MacPorts project, who are most likely Apple employees. It's
advertised here (http://xquartz.macosforge.org/trac/wiki/X112.6.0) as:
* the main highlight are the transition to libxcb as a backend for libX11
* freetype 2.4.4 to address some font rendering issues in 2.5.2
* pixman 0.20.0 should have some better fast paths with SSE2
* fontconfig 2.8.0
* cairo 1.10.0
* libX11 1.4.0
* xorg-server 1.9.3 which includes RandR and a ton of stability fixes
The MacPorts variant does not inherit my login environment, so AUCTeX cannot
find tex. The ready-made X server does inherit and pass it to its clients –
but GNU Emacsen come up in the usual geometry size (96x56+25+125,
100x55+696+145), the fonts in GTK-2 based menubar and their menus are OK, the
font in the title is OK, only the font in the windows and the modelines are
very, very small, maybe 1 pt. I can C-x u = on some character and copy the
whole *Help* buffer's quite invisible contents and paste it into the NS
variant's *scratch* buffer. It shows as font used to display the checked
character the line:
xft:-B&H-LucidaTypewriter-normal-normal-normal-Sans-10-*-*-*-m-60-iso10646-1
which is the same as in the MacPorts variant. When I change the X resource
Xft.dpi: 96
to, say 960, hoping that would increase the font size to readable, it only
works in the GTK-2 based widgets: giant text in menubar and menus! (And as
well in GKrellM.) Screenshots available.
This happened with Xaw3d and GTK-2 X clients (since some days the Xaw3d
clients do not launch, only the GTK-2 ones) of many different GNU Emacs stable
and development versions. Can this happen due to a bug in GNU Emacs?