bug#2690: 23.0.91; line spacing with X servers

Peter Dyballa <[email protected]>
Newsgroups gmane.emacs.bugs,gmane.emacs.pretest.bugs
Message-ID <[email protected]>
Hello!

In Mac OS X 10.4.11 (Tiger) I have as default from Apple an X11R6.6  
based XFree86 4.4.0 X server. With this one everything is OK in terms  
of line spacing. From the MacPorts project (installed in /opt tree) I  
can compile, install, and run X.org Release 7.3 for Tiger (XQuartz  
2.3.3 (xorg-server 1.4.2-apple35)). It does not offer much I am  
missing (transparency), but it is the same X server that is  
distributed with Mac OS X 10.5 (Leopard). This X server shows in GNU  
Emacsen 23.0.x a reduced line spacing, independent from the X toolkit  
Xaw3d or GTK. The descenders of g, p, q, ... penetrate the next line  
(particularly visible by flashing effects of the horizontal "bar" of  
g's descender for example when a shell command or a compile process  
produce output outside, below, my stable viewport, or when scroll-up  
or scroll-finishes and the view stabilises, and from time to time  
when only the cursor is blinking – anti-aliasing?).

GNU Emacsen 22.x do not show this effect. Today I made two tests: I  
first compiled GNU Emacs 22.3 with the X11R7.3 software – no effect  
on line spacing, in neither X servers, everything's OK. And I  
compiled GNU Emacs 23.0.91, updated today, with Apple's X11R6.6 and  
some "auxiliary" software (GTK, libs TIFF, JPEG, GIF, PNG, RSVG, XPM)  
from X11R6.6 based Fink project (installed in /sw tree). It shows the  
too tight line spacing effect in X11R7.3. All use libfontconfig 1 or  
2 and libfreetype. Libotf is not used. The X11R6.6 version does not  
use libXft, for which I can't check the cause because the  
configure.log file is just a few 100 bytes long.

I did not check with lsof that the Emacs binaries are really using  
those shared libraries they are linked to (I rely on the output of  
otool, Apple's ldd command), but I can check upon request. Do you  
have an explanation for the X server's behaviour? And also a cure?

There is another effect in *shell* buffer: just pressing RET on an  
empty line positions the cursor in the next line in column 0, at the  
beginning of the prompt (%n ! /\  in tcsh) which is customised and  
not manipulated by ANSI.


In GNU Emacs 23.0.91.1 (powerpc-apple-darwin8.11.0, GTK+ Version 2.14.7)
  of 2009-03-16 on localhost
Windowing system distributor `The X.Org Foundation', version  
11.0.10402000
configured using `configure  '--without-sound' '--without-pop' '-- 
with-dbus' '--with-libotf' '--x-includes=/usr/X11R6/include' '--x- 
libraries=/usr/X11R6/lib' '--enable-locallisppath=/Library/ 
Application Support/Emacs/calendar23:/Library/Application Support/ 
Emacs' 'PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig:/usr/local/lib/ 
pkgconfig:/usr/lib/pkgconfig' 'CFLAGS=-Wno-pointer-sign -H -pipe - 
fPIC -mcpu=7450 -mtune=7450 -fast -mpim-altivec -ftree-vectorize - 
foptimize-register-move -freorder-blocks -freorder-blocks-and- 
partition -fthread-jumps -fpeephole -fno-crossjumping' 'LDFLAGS=- 
dead_strip -multiply_defined suppress -L/usr/X11R6/lib' 'CPPFLAGS=-no- 
cpp-precomp -I/usr/include/openssl -I/sw/include/pango-1.0 -I/sw/lib/ 
fontconfig2/include -I/usr/local/include -I/sw/include''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: de_DE.UTF-8
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: de_DE.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default-enable-multibyte-characters: t

--
Greetings

   Pete

There's no place like ~
		– (UNIX Guru)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.