bug#7956: 24.0.50; xft:-B&H-LucidaTypewriter-normal-normal-normal-Sans-10-*-*-*-m-60-iso10646-1 rendered to presumingly 1 pt

[Peter Dyballa <Peter_Dyballa@Freenet.DE>]

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?


In GNU Emacs 24.0.50.7 (powerpc-apple-darwin9.8.0, X toolkit, Xaw3d  
scroll bars)
  of 2011-02-01 on localhost
configured using `configure  '--without-sound' '--without-dbus' '-- 
without-pop' '--without-gconf' '--with-x-toolkit=athena' '--x- 
libraries=/opt/local/lib' '--x-includes=/opt/local/include' '--enable- 
locallisppath=/Library/Application Support/Emacs/calendar24:/Library/ 
Application Support/Emacs' 'CFLAGS=-g -H -pipe -fPIC -fno-common - 
mcpu=7450 -mtune=7450 -faltivec -O0' 'LDFLAGS=-Wl,-dead_strip_dylibs - 
Wl,-bind_at_load -Wl,-t' 'CC=gcc-4.2' 'CPP=cpp-4.2' 'PKG_CONFIG_PATH=/ 
opt/local/lib/pkgconfig:/opt/local/share/pkgconfig:/usr/lib/pkgconfig:/ 
usr/X11/lib/pkgconfig:/usr/X11/share/pkgconfig''


--
Greetings

   Pete

Perl—the only language that looks the same before and after RSA  
encryption.
				- Keith Bostic