bug#597: marked as done (23.0.60; Corrupted display.)

[don@donarmstrong.com (Emacs bug Tracking System)]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]


Your message dated Sun, 23 Nov 2008 23:22:27 +0800
with message-id <49297533.3040505@f2s.com>
and subject line Re: bug#642: 23.0.60;garbled text (wrong font?) in About GNU Emacs screen
has caused the Emacs bug report #642,
regarding 23.0.60; Corrupted display.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
642: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=642
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3474 bytes --]

From: ofv@wanadoo.es
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; Corrupted display.
Date: Wed, 23 Jul 2008 01:34:36 +0200
Message-ID: <ej5l1oj7.fsf@telefonica.net>

After some use, Emacs display shows garbage characters instead of
normal text. Only those characters that are shown with the normal face
are replaced by garbage. Text shown as italics, bold, etc, remains
correct. I have no recipe to reproduce this. It usually happens while
reading news with Gnus, but I was unable to reproduce the problem by
duplicating the Gnus session (in particular, displaying again the
article that I was reading when the display got corrupted).


In GNU Emacs 23.0.60.1 (i386-mingw-nt5.0.2195)
 of 2008-07-18 on K7
Windowing system distributor `Microsoft Corp.', version 5.0.2195
configured using `configure --with-gcc (4.2) --cflags -It:/emacscvs/include --ldflags -Lt:/emacscvs/lib'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: en
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ESN
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  show-paren-mode: t
  iswitchb-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-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:
M-h <up> <down> C-g <f10> <menu-bar> <help-menu> <
send-emacs-bug-report>

Recent messages:
ergo-keys
Loading comint...done
Loading d:/lp0/utils/lp0-mode.el (source)...done
Loading `~/.emacs': old-style backquotes detected!
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit

;; -- 
;; =d3scar



[-- Attachment #3: Type: message/rfc822, Size: 3841 bytes --]

From: Jason Rumney <jasonr@f2s.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: 642-done@emacsbugs.donarmstrong.com
Subject: Re: bug#642: 23.0.60;garbled text (wrong font?) in About GNU Emacs screen
Date: Sun, 23 Nov 2008 23:22:27 +0800
Message-ID: <49297533.3040505@f2s.com>

Drew Adams wrote:
> Here is some more info about this.
>   

> The display shows problems with font families Times and Helvetica. I use the
> standard Times and Helvetica Type1 fonts on Windows XP. E.g., the Times Roman
> font file is named TIR_____.PFM; the Helvetica file is HV_____.PFM.
>   


Thanks for your extra information.  I think this is related to the fact 
that the Uniscribe font backend can only use opentype and truetype 
fonts, but Windows by default defines font substitutions for Helvetica 
and Times to map to the Truetype fonts "Arial" and "Times New Roman". So 
the uniscribe backend picks these substitutes up, but somehow things get 
confused so the Type-1 fonts end up being loaded. I've added some code 
to specifically reject these substitutes, which are detected by 
comparing the font's "full name" with the name used to load it. 
Unfortunately this also catches many legitimate fonts, so I've had to 
pick out these two specific problematic substitutions. If there are any 
other specific fonts that cause this problem, then we will need to add 
rules for them too.