HELLO confuses Emacs with new font backend

HELLO confuses Emacs with new font backend

[Juanma Barranquero]

[-- 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 --]

Re: HELLO confuses Emacs with new font backend

[Juanma Barranquero]

[-- 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 --]

Re: HELLO confuses Emacs with new font backend

[Jason Rumney]

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]

Re: HELLO confuses Emacs with new font backend

[Juanma Barranquero]

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

Re: HELLO confuses Emacs with new font backend

[Juanma Barranquero]

>  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

Re: HELLO confuses Emacs with new font backend

[Jason Rumney]

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).

Re: HELLO confuses Emacs with new font backend

[Juanma Barranquero]

> 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