* HELLO confuses Emacs with new font backend
@ 2008-05-15 8:53 Juanma Barranquero
2008-05-15 12:36 ` Juanma Barranquero
0 siblings, 1 reply; 7+ messages in thread
From: Juanma Barranquero @ 2008-05-15 8:53 UTC (permalink / raw
To: Emacs Devel
[-- Attachment #1: Type: text/plain, Size: 238 bytes --]
This is on Windows XP, with an Emacs built from CVS five minutes ago.
With the new font backend, C-h H screws up the font selection of Emacs
(see attached partial image of the HELLO buffer) and does not recover
until restarted.
Juanma
[-- Attachment #2: hello.png --]
[-- Type: image/png, Size: 36545 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: HELLO confuses Emacs with new font backend
2008-05-15 8:53 HELLO confuses Emacs with new font backend Juanma Barranquero
@ 2008-05-15 12:36 ` Juanma Barranquero
2008-05-15 14:04 ` Jason Rumney
0 siblings, 1 reply; 7+ messages in thread
From: Juanma Barranquero @ 2008-05-15 12:36 UTC (permalink / raw
To: Emacs Devel
[-- Attachment #1: Type: text/plain, Size: 143 bytes --]
Another problem:
After emacs -q --no-site-file (and no registry entries for Emacs),
part of the startup screen message is garbled.
Juanma
[-- Attachment #2: startup.png --]
[-- Type: image/png, Size: 3018 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: HELLO confuses Emacs with new font backend
2008-05-15 12:36 ` Juanma Barranquero
@ 2008-05-15 14:04 ` Jason Rumney
2008-05-15 14:22 ` Juanma Barranquero
0 siblings, 1 reply; 7+ messages in thread
From: Jason Rumney @ 2008-05-15 14:04 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Emacs Devel
Juanma Barranquero wrote:
> Another problem:
>
> After emacs -q --no-site-file (and no registry entries for Emacs),
> part of the startup screen message is garbled.
>
What does C-u C-x = say for the first garbled character?
For me, the message displays normally and I get
character: M (77, #o115, #x4d)
preferred charset: ascii (ASCII (ISO646 IRV))
code point: 0x4D
syntax: w which means: word
category: a:ASCII graphic characters 32-126 (ISO646 IRV:1983[4/0])
l:Latin r:Japanese roman
buffer code: #x4D
file code: not encodable by coding system iso-latin-1-dos
display: by this font (glyph code)
-raster-Courier-normal-normal-normal-mono-13-*-*-*-m-*-iso8859-1 (#x4D)
Character code properties are not shown: customize what to show
There are text properties here:
face (fixed-pitch :foreground "red")
help-echo [Show]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: HELLO confuses Emacs with new font backend
2008-05-15 14:04 ` Jason Rumney
@ 2008-05-15 14:22 ` Juanma Barranquero
2008-05-15 14:32 ` Juanma Barranquero
2008-05-15 15:24 ` Jason Rumney
0 siblings, 2 replies; 7+ messages in thread
From: Juanma Barranquero @ 2008-05-15 14:22 UTC (permalink / raw
To: Jason Rumney; +Cc: Emacs Devel
On Thu, May 15, 2008 at 4:04 PM, Jason Rumney <jasonr@gnu.org> wrote:
> What does C-u C-x = say for the first garbled character?
The first garbled characters is the M of "M-x" etc. I see it like 'l'
(or 'I', I'm not sure), and C-u C-x = says:
----------------------------------------------------------------------------------------------------
character: M (77, #o115, #x4d)
preferred charset: ascii (ASCII (ISO646 IRV))
code point: 0x4D
syntax: w which means: word
category: a:ASCII graphic characters 32-126 (ISO646 IRV:1983[4/0])
l:Latin r:Japanese roman
buffer code: #x4D
file code: not encodable by coding system iso-latin-1-dos
display: by this font (glyph code)
-outline-Courier-normal-normal-normal-mono-13-*-*-*-m-*-iso8859-1 (#x4D)
Character code properties are not shown: customize what to show
There are text properties here:
face (fixed-pitch :foreground "red")
help-echo [Show]
----------------------------------------------------------------------------------------------------
except that I see
character: l (77, #o115, #x4d)
but it is obviously describing the `M'.
If I start Emacs with
emacs.exe -q --no-site-file -fn "-*-DejaVu Sans
Mono-normal-r-normal-*-13-*-*-*-c-*-iso10646-1"
the problem does not hapen.
Juanma
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: HELLO confuses Emacs with new font backend
2008-05-15 14:22 ` Juanma Barranquero
@ 2008-05-15 14:32 ` Juanma Barranquero
2008-05-15 15:24 ` Jason Rumney
1 sibling, 0 replies; 7+ messages in thread
From: Juanma Barranquero @ 2008-05-15 14:32 UTC (permalink / raw
To: Jason Rumney; +Cc: Emacs Devel
> emacs.exe -q --no-site-file -fn "-*-DejaVu Sans
> Mono-normal-r-normal-*-13-*-*-*-c-*-iso10646-1"
BTW, an incomplete face/fontset spec in the command line is causing crashes:
emacs -q --no-site-file -fn -*-D
Program received signal SIGSEGV, Segmentation fault.
Fdisplay_supports_face_attributes_p (attributes=26315813,
display=26251780) at xfaces.c:5006
5006 if (! EQ (face->font->props[i], def_face->font->props[i]))
(gdb) bt
#0 Fdisplay_supports_face_attributes_p (attributes=26315813,
display=26251780) at xfaces.c:5006
#1 0x0101b4a0 in Ffuncall (nargs=3, args=0x82ef00) at eval.c:3033
#2 0x011425b4 in Fbyte_code (bytestr=19198819, vector=19198956,
maxdepth=40) at bytecode.c:678
#3 0x0101d9f6 in funcall_lambda (fun=19198772, nargs=2,
arg_vector=0x82f044) at eval.c:3217
#4 0x0101b0ce in Ffuncall (nargs=3, args=0x82f040) at eval.c:3076
#5 0x011425b4 in Fbyte_code (bytestr=19199195, vector=19199276,
maxdepth=32) at bytecode.c:678
#6 0x0101d9f6 in funcall_lambda (fun=19199140, nargs=2,
arg_vector=0x82f174) at eval.c:3217
#7 0x0101b0ce in Ffuncall (nargs=3, args=0x82f170) at eval.c:3076
#8 0x011425b4 in Fbyte_code (bytestr=19200123, vector=19200228,
maxdepth=48) at bytecode.c:678
#9 0x0101d9f6 in funcall_lambda (fun=19200068, nargs=3,
arg_vector=0x82f2b4) at eval.c:3217
#10 0x0101b0ce in Ffuncall (nargs=4, args=0x82f2b0) at eval.c:3076
#11 0x011425b4 in Fbyte_code (bytestr=19199891, vector=19199988,
maxdepth=48) at bytecode.c:678
#12 0x0101d9f6 in funcall_lambda (fun=19199844, nargs=2,
arg_vector=0x82f3f4) at eval.c:3217
#13 0x0101b0ce in Ffuncall (nargs=3, args=0x82f3f0) at eval.c:3076
#14 0x011425b4 in Fbyte_code (bytestr=19206203, vector=19206268,
maxdepth=24) at bytecode.c:678
#15 0x0101d394 in Feval (form=19206189) at eval.c:2367
#16 0x0101e273 in internal_lisp_condition_case (var=25692161,
bodyform=19206189, handlers=19206341) at eval.c:1444
#17 0x01142e42 in Fbyte_code (bytestr=19205675, vector=19205828,
maxdepth=72) at bytecode.c:868
#18 0x0101d9f6 in funcall_lambda (fun=19205636, nargs=1,
arg_vector=0x82f6e4) at eval.c:3217
#19 0x0101b0ce in Ffuncall (nargs=2, args=0x82f6e0) at eval.c:3076
#20 0x011425b4 in Fbyte_code (bytestr=19205267, vector=19205364,
maxdepth=32) at bytecode.c:678
#21 0x0101d9f6 in funcall_lambda (fun=19205220, nargs=1,
arg_vector=0x82f814) at eval.c:3217
#22 0x0101b0ce in Ffuncall (nargs=2, args=0x82f810) at eval.c:3076
#23 0x011425b4 in Fbyte_code (bytestr=19519275, vector=19519420,
maxdepth=48) at bytecode.c:678
#24 0x0101d9f6 in funcall_lambda (fun=19519228, nargs=1,
arg_vector=0x82f954) at eval.c:3217
#25 0x0101b0ce in Ffuncall (nargs=2, args=0x82f950) at eval.c:3076
#26 0x011425b4 in Fbyte_code (bytestr=19515371, vector=19515492,
maxdepth=48) at bytecode.c:678
#27 0x0101d9f6 in funcall_lambda (fun=19515340, nargs=0,
arg_vector=0x82fa94) at eval.c:3217
#28 0x0101b0ce in Ffuncall (nargs=1, args=0x82fa90) at eval.c:3076
#29 0x011425b4 in Fbyte_code (bytestr=19243315, vector=19244212,
maxdepth=56) at bytecode.c:678
#30 0x0101d9f6 in funcall_lambda (fun=19243292, nargs=0,
arg_vector=0x82fbd4) at eval.c:3217
#31 0x0101b0ce in Ffuncall (nargs=1, args=0x82fbd0) at eval.c:3076
#32 0x011425b4 in Fbyte_code (bytestr=19239123, vector=19239340,
maxdepth=48) at bytecode.c:678
#33 0x0101d9f6 in funcall_lambda (fun=19239100, nargs=0,
arg_vector=0x82fca0) at eval.c:3217
#34 0x0101dc7c in apply_lambda (fun=19239100, args=25692161,
eval_flag=1) at eval.c:3141
#35 0x0101cf2e in Feval (form=26334053) at eval.c:2403
#36 0x01083c3a in top_level_2 () at keyboard.c:1376
#37 0x0101a826 in internal_condition_case (bfun=0x1083c27
<top_level_2>, handlers=25755841,
hfun=0x1088716 <cmd_error>) at eval.c:1499
#38 0x010884b3 in top_level_1 () at keyboard.c:1384
#39 0x0101a8d0 in internal_catch (tag=25751913, func=0x1088468
<top_level_1>, arg=25692161) at eval.c:1235
#40 0x0108853d in command_loop () at keyboard.c:1339
#41 0x010888af in recursive_edit_1 () at keyboard.c:955
#42 0x01088a1a in Frecursive_edit () at keyboard.c:1017
#43 0x01002c41 in main (argc=8585136, argv=0xa94510) at emacs.c:1771
Lisp Backtrace:
"display-supports-face-attributes-p" (0x82ef04)
"face-spec-set-match-display" (0x82f044)
"face-spec-choose" (0x82f174)
"face-spec-set-2" (0x82f2b4)
"face-spec-recalc" (0x82f3f4)
"byte-code" (0x82f490)
"face-set-after-frame-default" (0x82f6e4)
"x-create-frame-with-faces" (0x82f814)
"make-frame" (0x82f954)
"frame-initialize" (0x82fa94)
"command-line" (0x82fbd4)
"normal-top-level" (0x82fca0)
(gdb)
Juanma
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: HELLO confuses Emacs with new font backend
2008-05-15 14:22 ` Juanma Barranquero
2008-05-15 14:32 ` Juanma Barranquero
@ 2008-05-15 15:24 ` Jason Rumney
2008-05-15 15:42 ` Juanma Barranquero
1 sibling, 1 reply; 7+ messages in thread
From: Jason Rumney @ 2008-05-15 15:24 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Emacs Devel
Juanma Barranquero wrote:
> display: by this font (glyph code)
> -outline-Courier-normal-normal-normal-mono-13-*-*-*-m-*-iso8859-1 (#x4D)
>
Do you have a "Courier" truetype font on your system? Normally the
Windows font "Courier" is a raster font. If you have both, the problems
may be being caused by the two fonts getting confused.
The fact that Emacs has chosen glyph code #x4D to represent character
code #x4D suggests that it is falling back on using the character code
throughout, which is required for raster fonts and Windows 9x/ME, but
when outputting it still seems to be expecting glyph codes for some
reason (normally the font is marked as not supporting glyph codes, which
should cause the display code to DTRT,albiet slower than if the glyph
codes were already available).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: HELLO confuses Emacs with new font backend
2008-05-15 15:24 ` Jason Rumney
@ 2008-05-15 15:42 ` Juanma Barranquero
0 siblings, 0 replies; 7+ messages in thread
From: Juanma Barranquero @ 2008-05-15 15:42 UTC (permalink / raw
To: Jason Rumney; +Cc: Emacs Devel
> Do you have a "Courier" truetype font on your system?
I have a PostScript ATM font "Courier", an OpenType "Courier New" font
and a TrueType "CourierPS" font (plus bold/italic variants).
> Normally the Windows
> font "Courier" is a raster font. If you have both, the problems may be being
> caused by the two fonts getting confused.
Is there something more I can test?
Juanma
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-05-15 15:42 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-15 8:53 HELLO confuses Emacs with new font backend Juanma Barranquero
2008-05-15 12:36 ` Juanma Barranquero
2008-05-15 14:04 ` Jason Rumney
2008-05-15 14:22 ` Juanma Barranquero
2008-05-15 14:32 ` Juanma Barranquero
2008-05-15 15:24 ` Jason Rumney
2008-05-15 15:42 ` Juanma Barranquero
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.