bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Emacs bug Tracking System
Subject: bug#597: marked as done (23.0.60; Corrupted display.)
Date: Sun, 23 Nov 2008 07:30:05 -0800

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
--- Begin Message --- Subject: 23.0.60; Corrupted display. Date: Wed, 23 Jul 2008 01:34:36 +0200
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



--- End Message ---
--- Begin Message --- 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 User-agent: Thunderbird 2.0.0.18 (Windows/20081105)
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.





--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]