GNU bug report logs - #6357
24.0.50; initial text encoding disaster with NS variant Emacs.app on Mac OS X 10.5.8

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6357 in the body.
You can then email your comments to 6357 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50;
	initial text encoding disaster with NS variant Emacs.app on Mac OS X
	10.5.8
Date: Sat, 5 Jun 2010 17:21:39 +0200

[Message part 1 (text/plain, inline)]

Hello!

After 'make install' by super-user I launch as mortal user

	nextstep/Emacs.app/Contents/MacOS/Emacs -Q

This is fine. I save site-start.el under a different name and launch

	nextstep/Emacs.app/Contents/MacOS/Emacs -q

What I get looks quite like this:

[Emacs.app xyz.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

(This buffer's contents looks almost right, the frame's title is  
correct, but *Messages* or *Buffer List* are a mess.) When I launch  
Emacs.app without parameter or by double-clicking on it or by using  
the open command, Emacs.app shows for long time these weird texts.  
Particularly error messages or warning (unsafe local variables,  
desktop file in use, etc.) cannot be understood. This state ends when  
the first frame is rebuilt to follow initial-frame-alist. From now on  
all texts are sane/OK.

This behaviour started already with GNU Emacs 23.1.50 – at least such  
an old version (powerpc-apple-darwin8.11.0, NS apple-appkit-824.48,  
2009-11-14, Windowing system distributor `Apple', version 10.3.949),  
built under Tiger, Mac OS X 10.4.11, shows this behaviour in Leopard,  
Mac OS X 10.5.8. I do seem to remember that I saw this scrambling in  
GNU Emacs 23.1.90 on Tiger. The X clients do not show this effect.  
Processor is PowerPC "G4" 7447A, i.e., big endian (intel/AMD are  
little endian).


In GNU Emacs 24.0.50.1 (powerpc-apple-darwin9.8.0, NS apple- 
appkit-949.54)
 of 2010-06-05 on Latsche.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--without-sound' '--without-dbus' '-- 
without-pop' '--without-gconf' '--with-ns' '--disable-ns-self- 
contained' '--x-libraries=/usr/X11/lib' '--x-includes=/usr/X11/ 
include' '--enable-locallisppath=/Library/Application Support/Emacs/ 
calendar24:/Library/Application Support/Emacs' 'CFLAGS=-g -H -Wno- 
pointer-sign -pipe -fPIC -fno-common -mcpu=7450 -mtune=7450 -faltivec - 
fast' 'CPPFLAGS=' 'LDFLAGS=' 'CC=gcc-4.2' 'CPP=cpp-4.2'  
'PKG_CONFIG_PATH=/sw/lib/pango-ft219/lib/pkgconfig:/sw/lib/xft2/lib/ 
pkgconfig:/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/freetype219/lib/ 
pkgconfig:/sw/lib/pkgconfig:/sw/share/pkgconfig:/usr/lib/pkgconfig:/ 
usr/X11/lib/pkgconfig:/usr/X11/share/pkgconfig''

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

Major mode: Dired by name

Minor modes in effect:
  TeX-PDF-mode: t
  auto-revert-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  show-paren-mode: t
  display-time-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<menu-bar> <help-menu> <send-emacs-bug-report>


--
Greetings

  Pete

Got Mole problems?
Call Avogadro 6.02 x 10^23

Message #8 received at 6357 <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: 6357 <at> debbugs.gnu.org
Subject: Re: bug#6357: Acknowledgement (24.0.50;
	initial text encoding disaster with NS variant Emacs.app on Mac OS X
	10.5.8)
Date: Sun, 8 Aug 2010 23:13:43 +0200

Hello!

This effect is gone. None of the saved installations shows this  
effect. It could be the last reboot, it could be the installation of  
Safari 5.0.1 before this...

--
Greetings

  Pete

There are very few jobs that actually require a penis or vagina. All  
other jobs should be open to everybody.
				– Florynce Kennedy

Message #13 received at 6357 <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: 6357 <at> debbugs.gnu.org
Subject: Re: bug#6357 acknowledged by developer (close 6357)
Date: Mon, 9 Aug 2010 14:21:36 +0200

Sorry! I was too fast!

Actually it's not the Safari update and reboot, but the font I used!  
Or the fonts management system in Mac OS X – see below!

Since I can't really work with NS Emacs.app because copy&paste does  
not work at all, I decided to try to find all available mono-spaced  
fonts and see how they look (the look is independent from whether I  
can read or not). For this I did not try the "original" font again,  
but a new one as first test instance. Since I then walked through all  
the fonts I came again to

	-apple-Latin_Modern_Mono_Light-medium-normal-normal-*-9-*-*-*-m-0- 
iso10646-1

(It has an accompanying condensed variant in another font family, - 
apple-Latin_Modern_Mono_Light_Cond-medium-normal-condensed-*-9-*-*-*- 
m-0-iso10646-1, which works well – besides the fact that it's not  
useful as an Emacs font. Its regular variant -apple-Latin_Modern_Mono- 
medium-normal-normal-*-9-*-*-*-*-*-iso10646-1, again in a different  
font family, works well as well, despite the fact that Font Book marks  
faultily one member as a duplicate.) Linotype FontExplorer X (version  
1.2.3) and Apple's Font Book (version 2.1) characterise this "faulty"  
font as:

	PostScript name	LMMonoLt10-Regular
	Full name	LMMonoLt10-Regular
	Family		Latin Modern Mono Light
	Style		10 Regular
	Kind		OpenType PostScript
	Language	Albanian, Basque, Catalan, Cornish, Croatian, Czech, Danish,  
Dutch, English, Esperanto, Estonian, Faroese, Finnish, French,  
Galician, German, Hungarian, Icelandic, Indonesian, Irish, Italian,  
Latvian, Lithuanian, Malay, Maltese, Manx, Norwegian Bokmål, Norwegian  
Nynorsk, Oromo, Polish, Portuguese, Romanian, Slovak, Slovenian,  
Somali, Spanish, Swahili, Swedish, Turkish, Vietnamese, Welsh
	Version	Version 2.004;PS 2.004;hotconv 1.0.49;makeotf.lib2.0.14853
	Location	/usr/local/texlive/2010/texmf-dist/fonts/opentype/public/lm/ 
lmmonolt10-regular.otf
	Unique name	2.004;UKWN;LMMonoLt10-Regular
	Copyright	Copyright 2003, 2009 B. Jackowski and J. M. Nowacki (on  
behalf of TeX users groups). This work is released under the GUST Font  
License --  see http://tug.org/fonts/licenses/GUST-FONT-LICENSE.txt  
for details.

	784 glyphs

Apple's Font Book annotates *faultily* the Oblique variant as being a  
duplicate. This circumstance does cause errors in XeTeX typesetting,  
one stage using font properties from one member, the other stage using  
font properties from another member. Cleaning the dirty font caches  
involves a reboot following. I'd like to wait for this action a few  
weeks, until the end of month or arrival of a new security update...

--
Greetings

  Pete

Cabbage, n. A familiar kitchen-garden vegetable about as large and  
wise as a man's head.

Message #16 received at 6357 <at> debbugs.gnu.org (full text, mbox):

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: 6357 <at> debbugs.gnu.org
Subject: Re: bug#6357 acknowledged by developer (close 6357)
Date: Thu, 26 Aug 2010 00:27:55 +0200

Am 09.08.2010 um 14:21 schrieb Peter Dyballa:

> I'd like to wait for this action a few weeks, until the end of month  
> or arrival of a new security update...


A power failure was faster: Because I cleaned the fonts caches and  
removed all "duplicate fonts" in the Font Book application, -apple- 
Latin_Modern_Mono_Light-medium-normal-normal-*-9-*-*-*-m-0-iso10646-1  
now works again without fault! So it was either a failure in the fonts  
caches or a failure in Font Book which marked the font as having a  
duplicate (without explaining why and by what this flag is raised).

--
Greetings

  Pete

Make it simple, as simple as possible but no simpler.
				– Albert Einstein

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.