font-backend branch

font-backend branch

[Kenichi Handa]

I've just committed new codes in font-backend branch.  Those
who have reported font-backend-related bugs, please test
that branch.

The change log files are not yet ready.  I committed partial
one in src/ChangeLog.fb.

As for Windows port:

I tried to compile it on Windows in cygwin environment.  By,
"make bootstrap", it seems that src/oo-spd/i386/emacs.exe is
created, but the make failed at the target finder-data of
lisp/makefile.  And, when I run src/oo-spd/i386/emacs, it
starts up without an error, but, non-ASCII characters are
not correctly displayed by garbage glyphs.  Perhaps, there's
something wrong in my changes on src/w32*.[ch].  I'm now
trying to find what is wrong, but, Jason, could you please
investigate it too?

As for Mac port:

I didn't touch any mac-specific files.  So, it can't be
compiled.  Mac-port maintainers, please adjust codes for the
new font.h and font.c by checking what I've done for the
other font-backend codes (and xterm.c and xfns.c).

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Stefan Monnier]

> I've just committed new codes in font-backend branch.  Those
> who have reported font-backend-related bugs, please test
> that branch.

It doesn't compile with -DUSE_LISP_UNION_TYPE.


        Stefan

Re: font-backend branch

[Kenichi Handa]

In article <jwvk5if3mpp.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > I've just committed new codes in font-backend branch.  Those
> > who have reported font-backend-related bugs, please test
> > that branch.

> It doesn't compile with -DUSE_LISP_UNION_TYPE.

Oops, I've just installed fixes.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Juanma Barranquero]

On Wed, Apr 30, 2008 at 6:24 AM, Kenichi Handa <handa@m17n.org> wrote:

> I've just committed new codes in font-backend branch.  Those
>  who have reported font-backend-related bugs, please test
>  that branch.

I can bootstrap it on Windows (MinGW, not Cygwin) and it seems to
work, but M-x view-hello-file crashes it with the following backtrace.

 Juanma


Program received signal SIGSEGV, Segmentation fault.
0x77c17631 in msvcrt!memset () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0  0x77c17631 in msvcrt!memset () from C:\WINDOWS\system32\msvcrt.dll
#1  0x00000001 in ?? ()
#2  0x01203f63 in clear_cached_metrics (w32_font=0x1c84d00) at w32font.c:1878
#3  0x01208508 in w32font_text_extents (font=0x1c84d00, code=0x82e7f0,
nglyphs=11, metrics=0x82e842) at w32font.c:1866
#4  0x011e5adb in w32_compute_glyph_string_overhangs (s=0x82e990) at
w32term.c:1759
#5  0x0104e0cd in draw_glyphs (w=0x1aa3e00, x=0, row=0x1b31390,
area=TEXT_AREA, start=0, end=38, hl=DRAW_NORMAL_TEXT,
    overlaps=0) at xdisp.c:19943
#6  0x01052633 in x_write_glyphs (start=0x1bed000, len=38) at xdisp.c:21385
#7  0x0115b274 in update_window_line (w=0x1aa3e00, vpos=6,
mouse_face_overwritten_p=0x82f118) at dispnew.c:4454
#8  0x0115bdd4 in update_window (w=0x1aa3e00, force_p=0) at dispnew.c:4310
#9  0x0115e606 in update_window_tree (w=0x1aa3e00, force_p=0) at dispnew.c:4003
#10 0x0115fd34 in update_frame (f=0x1aa3a00, force_p=0,
inhibit_hairy_id_p=0) at dispnew.c:3931
#11 0x01045d21 in redisplay_internal (preserve_echo_area=0) at xdisp.c:11622
#12 0x0108d12f in read_char (commandflag=1, nmaps=3, maps=0x82fba0,
prev_event=25860097, used_mouse_menu=0x82fc44,
    end_time=0x0) at keyboard.c:2687
#13 0x0109164c in read_key_sequence (keybuf=0x82fce4, bufsize=30,
prompt=25860097, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9441
#14 0x01094679 in command_loop_1 () at keyboard.c:1653
#15 0x0101a1b7 in internal_condition_case (bfun=0x1094414
<command_loop_1>, handlers=25923777,
    hfun=0x108b8f6 <cmd_error>) at eval.c:1501
#16 0x0108ac00 in command_loop_2 () at keyboard.c:1369
#17 0x0101a252 in internal_catch (tag=25919849, func=0x108abdd
<command_loop_2>, arg=25860097) at eval.c:1237
#18 0x0108b729 in command_loop () at keyboard.c:1348
#19 0x0108ba82 in recursive_edit_1 () at keyboard.c:957
#20 0x0108bbed in Frecursive_edit () at keyboard.c:1019
#21 0x01002aec in main (argc=8585136, argv=0xa94228) at emacs.c:1778

Re: font-backend branch

[Kenichi Handa]

In article <f7ccd24b0804300438l7c393296le3ae8f7e4b213635@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes:

> On Wed, Apr 30, 2008 at 6:24 AM, Kenichi Handa <handa@m17n.org> wrote:
> > I've just committed new codes in font-backend branch.  Those
> >  who have reported font-backend-related bugs, please test
> >  that branch.

> I can bootstrap it on Windows (MinGW, not Cygwin) and it seems to
> work, but M-x view-hello-file crashes it with the following backtrace.

I think testing the font-backend branch on Windows is a
waste of time for a while unless you can debug the code on
Windows.  I myself have not yet understood Windows port
fully.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Juanma Barranquero]

On Wed, Apr 30, 2008 at 3:12 PM, Kenichi Handa <handa@m17n.org> wrote:

>  I think testing the font-backend branch on Windows is a
>  waste of time for a while unless you can debug the code on
>  Windows.

Well, I cannot invest time on it, but bootstrapping and running it
just to see whether it works is easily done.

 Juanma

Re: font-backend branch

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Wed, 30 Apr 2008 13:24:00 +0900
> 
> As for Windows port:
> 
> I tried to compile it on Windows in cygwin environment.  By,
> "make bootstrap", it seems that src/oo-spd/i386/emacs.exe is
> created, but the make failed at the target finder-data of
> lisp/makefile.

I don't recommend using Cygwin.  Instead, use native Windows ports
available from Gnuwin32 and MinGW sites.  There isn't a decent port of
Bash there, but you don't need Bash to build Emacs, it will build even
without a Unixy shell.

Re: font-backend branch

[Glenn Morris]

Kenichi Handa wrote:

> I've just committed new codes in font-backend branch. Those who have
> reported font-backend-related bugs, please test that branch.

On a RHEL5.1 x86_64 system, I did:

./configure --with-x --with-x-toolkit=athena --without-toolkit-scroll-bars
make bootstrap

and received this build error:

xfaces.c: In function 'x_update_menu_appearance':
xfaces.c:3768: error: expected ',' or ';' before 'const'
xfaces.c:3785: error: 'suffix' undeclared (first use in this function)
xfaces.c:3785: error: (Each undeclared identifier is reported only once
xfaces.c:3785: error: for each function it appears in.)
xfaces.c:3791: warning: comparison of distinct pointer types lacks a cast
make[2]: *** [xfaces.o] Error 1

Re: font-backend branch

[Glenn Morris]

Glenn Morris wrote:

> xfaces.c: In function 'x_update_menu_appearance':
> xfaces.c:3768: error: expected ',' or ';' before 'const'

Just a missing `;' at the end of line 3761.

Re: font-backend branch

[Glenn Morris]

Glenn Morris wrote:

> Just a missing `;' at the end of line 3761.

The same line is missing the `F' from Ffont_xlfd_name.

Re: font-backend branch

[Jason Rumney]

Kenichi Handa wrote:
> As for Windows port:
>
> I tried to compile it on Windows in cygwin environment.  By,
> "make bootstrap", it seems that src/oo-spd/i386/emacs.exe is
> created, but the make failed at the target finder-data of
> lisp/makefile.
This is because Cygwin make passes invalid paths to Emacs.

>   And, when I run src/oo-spd/i386/emacs, it
> starts up without an error, but, non-ASCII characters are
> not correctly displayed by garbage glyphs.

The new code seems to be making a poor choice of font for Latin-1 
characters, it is choosing a symbol font which does not contain the 
characters for me. This was triggering a bug that is also present in the 
trunk which caused the crash that Juanma experienced. The choice of font 
for other Latin characters is also not optimal, as the font used for 
ASCII contains most of these characters, but in the font-backend branch 
other fonts are chosen.

In addition to the bug mentioned above, I got another crash while 
displaying etc/HELLO which was caused by using s->face->font in 
w32font_draw. Changing it to use s->font works, but I have no idea what 
the difference is between these two, and why s->face->font would be NULL 
while s->font points to a valid font.

Re: font-backend branch

[Jason Rumney]

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

Jason Rumney wrote:
> The new code seems to be making a poor choice of font for Latin-1 
> characters, it is choosing a symbol font which does not contain the 
> characters for me. This was triggering a bug that is also present in 
> the trunk which caused the crash that Juanma experienced. The choice 
> of font for other Latin characters is also not optimal, as the font 
> used for ASCII contains most of these characters, but in the 
> font-backend branch other fonts are chosen.

Here is an example of how display in the font-backend branch differs 
from the trunk. I have highlighted some areas in the two images that 
look interesting for figuring out what might be going wrong:



[-- Attachment #2: emacs-font-backend.png --]
[-- Type: image/png, Size: 26752 bytes --]

[-- Attachment #3: emacs-trunk.png --]
[-- Type: image/png, Size: 32037 bytes --]

Re: font-backend branch

[Kenichi Handa]

In article <w1bq3rxfah.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:

> On a RHEL5.1 x86_64 system, I did:

> ./configure --with-x --with-x-toolkit=athena --without-toolkit-scroll-bars
> make bootstrap

> and received this build error:

> xfaces.c: In function 'x_update_menu_appearance':
> xfaces.c:3768: error: expected ',' or ';' before 'const'
> xfaces.c:3785: error: 'suffix' undeclared (first use in this function)
> xfaces.c:3785: error: (Each undeclared identifier is reported only once
> xfaces.c:3785: error: for each function it appears in.)
> xfaces.c:3791: warning: comparison of distinct pointer types lacks a cast
> make[2]: *** [xfaces.o] Error 1

Ah, I've never tried --with-x-toolkit=athena.

> Just a missing `;' at the end of line 3761.
[...]
> The same line is missing the `F' from Ffont_xlfd_name.

Thank you for finding the error.  I've just comitted a fix.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Glenn Morris]

Kenichi Handa wrote:

> I've just committed new codes in font-backend branch.  Those
> who have reported font-backend-related bugs, please test
> that branch.

Of the problems I've reported, your branch fixes these two:

font-lock faces use different font with font-backend
http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00651.html

font height problems with font-backend
http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00620.html


This issue is still present:

Xresource pane.menubar.*font no longer takes effect
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00314.html
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01683.html


Also, I have a new issue now, in that Emacs starts with the right
font, but in the wrong size. I have in ~/.Xdefaults:

Emacs.font: -misc-fixed-medium-r-normal-*-14-*-100-100-*-*-iso8859-1

But Emacs starts with a bigger font (misc fixed 9x15 it seems).
If I select 7x13 or 7x14 from the shift-mouse-1 "Misc" menu, I get the
font I want.

Re: font-backend branch

[Kenichi Handa]

In article <33y76u7k75.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:

> Of the problems I've reported, your branch fixes these two:

> font-lock faces use different font with font-backend
> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00651.html

> font height problems with font-backend
> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00620.html

Thank you for confirming them.

> This issue is still present:

> Xresource pane.menubar.*font no longer takes effect
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00314.html
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01683.html

Ok, I'm now investigating it.

> Also, I have a new issue now, in that Emacs starts with the right
> font, but in the wrong size. I have in ~/.Xdefaults:

> Emacs.font: -misc-fixed-medium-r-normal-*-14-*-100-100-*-*-iso8859-1

> But Emacs starts with a bigger font (misc fixed 9x15 it seems).
> If I select 7x13 or 7x14 from the shift-mouse-1 "Misc" menu, I get the
> font I want.

I've just installed a fix.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Glenn Morris]

Kenichi Handa wrote:

>> Of the problems I've reported, your branch fixes these two:
>
>> font-lock faces use different font with font-backend
>> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00651.html

Whoops, I just noticed that faces with a bold attribute are still
using a slightly different font.

>> Also, I have a new issue now, in that Emacs starts with the right
>> font, but in the wrong size.
[...]
> I've just installed a fix.

Works for me. Thanks!

Re: font-backend branch

[Kenichi Handa]

In article <o7fxt2tscf.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:
> Kenichi Handa wrote:
>>> Of the problems I've reported, your branch fixes these two:
> >
>>> font-lock faces use different font with font-backend
>>> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00651.html

> Whoops, I just noticed that faces with a bold attribute are still
> using a slightly different font.

Please show the results of C-u C-x = on the character of
default face and on the questionable characters.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Glenn Morris]

Kenichi Handa wrote:

> Please show the results of C-u C-x = on the character of
> default face and on the questionable characters.

Default face:

        character: l (108, #o154, #x6c)
preferred charset: ascii (ASCII (ISO646 IRV))
       code point: 0x6C
           syntax: w    which means: word
         category: a:ASCII graphic characters 32-126 (ISO646
         IRV:1983[4/0])
               l:Latin r:Japanese roman
      buffer code: #x6C
        file code: not encodable by coding system iso-latin-1-unix
          display: by this font (glyph code)
     -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1 (#x6C)

Bold face:

        character: p (112, #o160, #x70)
preferred charset: ascii (ASCII (ISO646 IRV))
       code point: 0x70
           syntax: w    which means: word
         category: a:ASCII graphic characters 32-126 (ISO646
         IRV:1983[4/0])
               l:Latin r:Japanese roman
      buffer code: #x70
        file code: not encodable by coding system iso-latin-1-unix
          display: by this font (glyph code)
     -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1 (#x70)


In Emacs 22, the default face has:

 display: by this font (glyph code)
     -Misc-Fixed-Medium-R-Normal--14-130-75-75-C-70-ISO8859-1 (#x65)

and the bold face has:

    display: by this font (glyph code)
     -Misc-Fixed-Bold-R-Normal--14-130-75-75-C-70-ISO8859-1 (#x6D)

Re: font-backend branch

[Kenichi Handa]

In article <E1JrSGO-0002cO-J3@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:

> > This issue is still present:

> > Xresource pane.menubar.*font no longer takes effect
> > http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00314.html
> > http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01683.html

> Ok, I'm now investigating it.

I've just installed a fix.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Kenichi Handa]

In article <29ve1y4h6i.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:

> Default face:
[...]
>      -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1 (#x6C)

> Bold face:
[...]
>      -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1 (#x70)

Ah, I see.  You wrote that you have this font setting.

Emacs.font: -misc-fixed-medium-r-normal-*-14-*-100-100-*-*-iso8859-1

When I run the command
  % xlsfonts -fn -misc-fixed-*-*-*-*-14-*-100-100-*-iso8859-1
I got this result:
  -misc-fixed-medium-r-normal--14-110-100-100-c-70-iso8859-1

So, Emacs preferred to use it for bold by making it
artificially bold (by overstriking).

But, actually that font is an alias of
  -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1.
and that font has this bold version:
  -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-1

Very complicated...

I've just installed a better but a little bit slower font
selection code.  Please try again.  I'll think about the
tuning for speed later.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Glenn Morris]

Kenichi Handa wrote:

> I've just installed a better but a little bit slower font selection
> code. Please try again. I'll think about the tuning for speed later.

Thank you - everything seems to work now. I have no more complaints! :)

Re: font-backend branch

[Kenichi Handa]

In article <ekiqxxnc7a.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:

> Kenichi Handa wrote:
> > I've just installed a better but a little bit slower font selection
> > code. Please try again. I'll think about the tuning for speed later.

> Thank you - everything seems to work now. I have no more complaints! :)

That's good.  Thank you for the help for fixing bugs.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[James Cloos]

Any chance of arranging commit mails for this branch?

Or do you expect it to be short-lived and quickly merged?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: font-backend branch

[Kenichi Handa]

In article <m3fxt1y0a7.fsf@lugabout.jhcloos.org>, James Cloos <cloos@jhcloos.com> writes:

> Any chance of arranging commit mails for this branch?
> Or do you expect it to be short-lived and quickly merged?

Yes.  As soon as Windows port code gets stable, I'll merge
it to the trunk.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Jason Rumney]

Kenichi Handa wrote:
> In article <m3fxt1y0a7.fsf@lugabout.jhcloos.org>, James Cloos <cloos@jhcloos.com> writes:
>
>   
>> Any chance of arranging commit mails for this branch?
>> Or do you expect it to be short-lived and quickly merged?
>>     
>
> Yes.  As soon as Windows port code gets stable, I'll merge
> it to the trunk.
>   

I don't know what has happened to break the Windows code. The ChangeLog 
does not appear to offer any clues.
 From what I can figure out, I think the default face is not being 
initialised properly. default_face->lface[LFACE_FAMILY_INDEX] is "*", 
likewise for other font related values, so any faces that inherit from 
the default face eventually end up calling font_open_entity with 
#<font-entity nil nil nil nil nil nil nil ...>.

Also (font-xlfd-name (font-at 1)) in *scratch* returns 
"-*-*-*-*-*-*-*-*-*-*-*-*-*-*", while (font-at 1) returns #<font-object 
"Courier New">

In trunk, these return "-outline-courier 
new-normal-normal-normal-mono-13-*-*-*-m-*-iso10646-1" and #<save_value 
ptr=0x01c66d00 int=4>
 respectively.

Re: font-backend branch

[Kenichi Handa]

In article <48190539.4010508@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> The new code seems to be making a poor choice of font for Latin-1 
> characters, it is choosing a symbol font which does not contain the 
> characters for me. This was triggering a bug that is also present in the 
> trunk which caused the crash that Juanma experienced. The choice of font 
> for other Latin characters is also not optimal, as the font used for 
> ASCII contains most of these characters, but in the font-backend branch 
> other fonts are chosen.

To understand why a correct font can't be used on Windows, I
must track the code of fontset by gdb, but at the moment, I
can't build Emacs correctly on Windows even with these gcc
and gmake:

C:\cygwin\home\handa\emacs-fb\nt>make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-pc-mingw32

C:\cygwin\home\handa\emacs-fb\nt>gcc --version
gcc (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

> In addition to the bug mentioned above, I got another crash while 
> displaying etc/HELLO which was caused by using s->face->font in 
> w32font_draw. Changing it to use s->font works, but I have no idea what 
> the difference is between these two, and why s->face->font would be NULL 
> while s->font points to a valid font.

I found that I made a silly mistake when I modified
w32term.c.  So, I've just installed the attached change.
But, anyway, w32font_draw should use s->font instead of
s->face->font because the latter may not be correct when a
text is shown with mouse-face.

---
Kenichi Handa
handa@ni.aist.go.jp

*** w32term.c.~1.285.2.1.~	2008-04-30 10:45:07.000000000 +0900
--- w32term.c	2008-05-02 17:09:25.000000000 +0900
***************
*** 1900,1906 ****
            x += g->pixel_width;
          }
      }
! 
      {
        int boff = s->font->baseline_offset;
        struct font *font = s->font;
--- 1900,1906 ----
            x += g->pixel_width;
          }
      }
!   else
      {
        int boff = s->font->baseline_offset;
        struct font *font = s->font;

Re: font-backend branch

[Jason Rumney]

Kenichi Handa wrote:
> To understand why a correct font can't be used on Windows, I
> must track the code of fontset by gdb, but at the moment, I
> can't build Emacs correctly on Windows even with these gcc
> and gmake:
>   

At which point is the build failing now? It might simplify things to 
copy your lisp directory from another plaform to avoid the need to 
bootstrap, as that is where most subtle problems with Windows build 
environments come up.

I think I have fixed the font selection problem, by adding code to copy 
the entries from font_entity to the new font_object in 
w32font_open_internal.

Now there is one remaining problem that I can see. When no font is found 
for some characters, display on that line is corrupted. The first time 
such a problem is encountered, all characters in the default face on 
that line are corrupted (I think this is caused by hitting a problem 
getting the glyph code, so code in w32font_encode_char decides to switch 
to using Unicode output for that font from that point on, so any glyphs 
that have already been encoded but not yet displayed are invalidated - 
the code was designed like this because for non-truetype fonts, and on 
older versions of Windows, it is not possible to get a glyph code, but I 
did not expect it to fail for a font where it had previously succeeded). 
After that, there is always a garbage character following the boxes that 
indicate a missing font. If the cursor is anywhere on the line, then the 
garbage character changes, at the same rate the cursor is blinking at.

Re: font-backend branch

[Jason Rumney]

Jason Rumney wrote:
> After that, there is always a garbage character following the boxes 
> that indicate a missing font. If the cursor is anywhere on the line, 
> then the garbage character changes, at the same rate the cursor is 
> blinking at.

This is fixed by your change to w32term.c. Now only the initial display 
corruption is a problem, so I will debug that and see if I can 
differentiate between errors that mean the font cannot use glyph codes, 
and other errors that only apply to specific characters, which we could 
indicate by treating that character as missing in the font.

Re: font-backend branch

[Kenichi Handa]

In article <481AFB40.1050205@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> At which point is the build failing now?

The same point as I wrote before.

> It might simplify things to 
> copy your lisp directory from another plaform to avoid the need to 
> bootstrap, as that is where most subtle problems with Windows build 
> environments come up.

Ah, that's a good idea.  I've just done it, and now I have
running Emacs on Windows.

> I think I have fixed the font selection problem, by adding code to copy 
> the entries from font_entity to the new font_object in 
> w32font_open_internal.

Ah, thank you for finding out that.  I have forgotten to do
that when I modified w32font.c.  :-(

[...]
> > After that, there is always a garbage character following the boxes 
> > that indicate a missing font. If the cursor is anywhere on the line, 
> > then the garbage character changes, at the same rate the cursor is 
> > blinking at.

> This is fixed by your change to w32term.c.

That's good.

> Now only the initial display 
> corruption is a problem, so I will debug that and see if I can 
> differentiate between errors that mean the font cannot use glyph codes, 
> and other errors that only apply to specific characters, which we could 
> indicate by treating that character as missing in the font.

Thank you.

By the way, could you make the `open' function of each
font-driver to set XLFD name in
font->props[FONT_NAME_INDEX].  Currently only the family
name is set there, but it seems that some people has a code
that expects XLFD name in the return value of
(frame-parameter nil 'font).

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Jason Rumney]

Kenichi Handa wrote:

> By the way, could you make the `open' function of each
> font-driver to set XLFD name in
> font->props[FONT_NAME_INDEX].  Currently only the family
> name is set there, but it seems that some people has a code
> that expects XLFD name in the return value of
> (frame-parameter nil 'font).
>   

Is depending on the format of the font name returned by frame-parameter 
widespread? XLFD has always been a poor fit for Windows fonts, and I am 
reluctant to make a change like this that might cause users to beleive 
that XLFD is still the prefered format for font names in Emacs.

Re: font-backend branch

[Kenichi Handa]

In article <481B16BE.7010608@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Is depending on the format of the font name returned by frame-parameter 
> widespread?

I don't know, but I got at least one bug-report as attached.

> XLFD has always been a poor fit for Windows fonts, and I am 
> reluctant to make a change like this that might cause users to beleive 
> that XLFD is still the prefered format for font names in Emacs.

I understand your point.

I want to suggest people to move their font handling code
from font-name base to font-spec base (by using such
functions as `font-spec', `font-get', `font-put',
`copy-font-spec').  But, for that, we must at first change,
for instance, the return value of (frame-parameter nil
'font) from string to font-object, and check how that change
influence the other part.   That't the future plan

But, I think it itself is not that bad that a font-object
has an XLFD name propperty.  That is a different thing from
what frame-parameter returns.

---
Kenichi Handa
handa@ni.aist.go.jp


From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-pretest-bug@gnu.org>
Date: Fri, 11 Apr 2008 11:39:03 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Thread-Index: AcicA1CgIP8qo0HoS62ESsbiALonUA==
Cc: 
Subject: 23.0.60; modify-frame-parameters in Emacs 23 for fonts

> From: Stefan Monnier Sent: Friday, April 11, 2008 9:38 AM
> 
> Send it to the bug-tracker, please, if it's not there yet.
 
----
From: Drew Adams Sent: Saturday, April 05, 2008 7:18 PM
I'm using this: GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-04-04 on
LENNART-69DE564.
 
(frame-parameter nil 'font) ->
"-*-Lucida Console-normal-r-*-*-14-*-96-96-c-*-iso8859-1"
 
(modify-frame-parameters
 nil
 (list
  (cons
   'font
   "-*-Lucida Console-normal-r-*-*-15-*-96-96-c-*-iso8859-1")))
 
(frame-parameter nil 'font) ->
"-outline-lucida console-normal-roman-normal-mono-15-*-*-*-*-*-fontset-startup"
 
What's that about? In Emacs 20, 21, and 22, the result is just the font I
specified.
 
I have code that zooms frames (font size). I change just the point size in the
font spec, using `x-decompose-font-name' and `x-compose-font-name'. I check that
the result is a legitimate font using `x-list-fonts'. If not, I increase or
decrease the increment until I find the font that works with the closest size.
 
[Yes, I know there are other ways to adjust font size, but I've found that this
method is flexible for users and provides certain benefits.]
 
My code no longer works without change, because after one call to
`modify-frame-parameters' the font is no longer something recognized by
`x-list-fonts'. I can comment out the part that iterates until it finds a size
that works (recognized by `x-list-fonts'). That works, but I'm still curious
about this. (Is there perhaps a bug in `x-list-fonts' or in
`modify-frame-parameters'?)
 
I couldn't find anything that helps me understand this in the manuals. I haven't
tried to dig through any code. Can someone light my lantern about this?
 
I looked in NEWS also, and saw something about a font backend (I didn't follow
the threads here about that). But I couldn't find anything in the Elisp or Emacs
manuals about "backend" or "back?end", except for version-control back ends.
 
A NEWS entry also says this: "the configure option `--disable-font-backend'
(also available as a run-time option)." But I can't find any such option
(variable) with `backend' or `back-end' in its name (except for
`vc-handled-backends'). I see, in both NEWS and in my frames, a parameter named
`font-backend', but I have no idea what it is. For me, its value is
(font-backend uniscribe gdi), FWIW.
 
Finding the function `fontp' mentioned in NEWS (but not in the Elisp manual,
alas), I also tried that in place of `x-list-fonts'. But it too does not
indicate that "-outline-lucida
console-normal-roman-normal-mono-15-*-*-*-*-*-fontset-startup" is a legitimate
font.
 
I see font terms in NEWS that I don't see explained in the manual: font-entity
object, font-spec object, font property value. I also see functions mentioned,
such as `font-font', that my Emacs does not recognize. Are they perhaps only for
X?
 
This whole area is a murky one, for me. Do others feel that this stuff is
explained well enough - in either the manuals or NEWS? Am I the only dummy about
this? Is this is a hidden subject for some secret club? ;-) If not, how about
some explanation?
 
 
 
 
 
In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-04-04 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 

Re: font-backend branch

[Stefan Monnier]

>> Is depending on the format of the font name returned by frame-parameter 
>> widespread?

> I don't know, but I got at least one bug-report as attached.

The bug report doesn't necessarily point to the need to support XFLD,
but rather that (frame-parameter <foo> 'font) should return something
that is considered as a font so it can be passed to x-list-fonts and
things like that.

I.e. we can address the issue by adapting x-list-fonts to accept
whichever format is output by (frame-parameter <foo> 'font).


        Stefan

Re: font-backend branch

[Kenichi Handa]

In article <jwvbq3mubub.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Is depending on the format of the font name returned by frame-parameter 
>>> widespread?

> > I don't know, but I got at least one bug-report as attached.

> The bug report doesn't necessarily point to the need to support XFLD,
> but rather that (frame-parameter <foo> 'font) should return something
> that is considered as a font so it can be passed to x-list-fonts and
> things like that.
>
> I.e. we can address the issue by adapting x-list-fonts to accept
> whichever format is output by (frame-parameter <foo> 'font).

Yes.  But, modifying all of "x-list-fonts and things like
that" can't be done quickly, and as it is not that urgent
task, we can leave it until later.  On the other hand,
setting FONT_NAME_INDEX of font-vector to a font name of
XLFD format can be done easily and quickly.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Jason Rumney]

Kenichi Handa wrote:
> But, for that, we must at first change,
> for instance, the return value of (frame-parameter nil
> 'font) from string to font-object, and check how that change
> influence the other part.   That't the future plan
>   

I was going to suggest exactly that. Then if people depend on the format 
of the font names, and do not want to move to using font-put, font-get 
etc, then they can use font-xlfd-name to get it in the format they need.

Re: font-backend branch

[Jason Rumney]

Stefan Monnier wrote:
> The bug report doesn't necessarily point to the need to support XFLD,
> but rather that (frame-parameter <foo> 'font) should return something
> that is considered as a font so it can be passed to x-list-fonts and
> things like that.
>   

Right. In the current trunk, x-list-fonts is the old way of listing 
fonts, list-fonts is the new font backend's way (but with slightly 
different arguments).  This affects X more than Windows, because 
x-list-fonts will only list X core fonts there, whereas font-list will 
list all active backends' fonts.

Once the old font code is removed, we can make x-list-fonts a 
compatibility layer on top of list-fonts, and tweak it so that it works 
with any of the supported formats (xfld, fontconfig, 
font-spec/entity/object) on input.

Re: font-backend branch

[Jason Rumney]

Kenichi Handa wrote:

> Yes.  But, modifying all of "x-list-fonts and things like
> that" can't be done quickly, and as it is not that urgent
> task, we can leave it until later.  On the other hand,
> setting FONT_NAME_INDEX of font-vector to a font name of
> XLFD format can be done easily and quickly.
>   

OK, I understand now, it is a temporary measure to avoid inconveniencing 
users while this work is ongoing. I'll change the w32 font code for now 
then.

Re: font-backend branch

[Jason Rumney]

Kenichi Handa wrote:
> Yes.  As soon as Windows port code gets stable, I'll merge
> it to the trunk.
>   

I think it is ready to merge now.

Re: font-backend branch

[Stefan Monnier]

>> Yes.  But, modifying all of "x-list-fonts and things like
>> that" can't be done quickly, and as it is not that urgent
>> task, we can leave it until later.  On the other hand,
>> setting FONT_NAME_INDEX of font-vector to a font name of
>> XLFD format can be done easily and quickly.

> OK, I understand now, it is a temporary measure to avoid inconveniencing
> users while this work is ongoing. I'll change the w32 font code for
> now then.

Please make sure there's a comment explaining the reason behind
the code.


        Stefan

Re: font-backend branch

[Florian Beck]

Kenichi Handa <handa@m17n.org> writes:

> I've just committed new codes in font-backend branch.  Those
> who have reported font-backend-related bugs, please test
> that branch.

Checkout from this morning crashes (segmentation fault) with

emacs -Q -fn "Vera Bitstream Sans Mono"
C-h h

and on startup when no font is specified.

Note: Emacs does not segfault, when I remove my local font directory.
Maybe some defect font is the culprit. Emacs should probably not crash,
though. 

In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2008-05-05 on fb-laptop
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure  'CC=gcc' 'CFLAGS=-O0 -fno-crossjumping -g''
 
Backtrace:

#0  0x0826c16e in font_style_to_value (prop=FONT_WEIGHT_INDEX, val=1720, noerror=1) at font.c:297
	n = 210
	last_i = 20
	i = 22
	last_n = 210
	numeric = 215
	table = 144017852
	len = 23
	i = 141062593
#1  0x0827996d in ftfont_pattern_entity (p=0x88e8a58, registry=138858233) at ftfont.c:137
	entity = 149859508
	file = (FcChar8 *) 0x88e8bc0 "/home/fb/.fonts/GillSansMTPro-UltraBoldCond.otf"
	fontformat = (FcChar8 *) 0x87816e8 "CFF"
	charset = (FcCharSet *) 0xb6dbde18
	str = (FcChar8 *) 0x8842180 "Gill Sans MT Pro"
	numeric = 215
	dbl = 14
	b = 1
#2  0x0827ac79 in ftfont_list (frame=147972900, spec=138868956) at ftfont.c:659
	entity = 149858076
	n = -1079397608
	dbl = 4.9406564584124654e-324
	val = 148574813
	tmp = 138868952
	registry = 138858233
	family = 138624281
	family_list = 148379557
	i = 556
	pattern = (FcPattern *) 0x8cda368
	fontset = (FcFontSet *) 0x8eaeef0
	objset = (FcObjectSet *) 0x883c180
	pixel_size = 0
	weight = -1
	slant = -1
	width = -1
	dpi = -1
	spacing = -1
	scalable = -1
	otlayout = "\000!\b\354\240e\b\334\370F\b\000\000\000"
	otspec = (struct OpenTypeSpec *) 0x0
#3  0x0827e287 in xftfont_list (frame=147972900, spec=138868956) at xftfont.c:160
	list = 138624281
	tail = 138860553
	i = 138624281
#4  0x08271352 in font_list_entities (frame=147972900, spec=145680892) at font.c:2386
	copy = 141658468
	val = 138624281
	cache = 139156789
	tail = 138624281
	f = (FRAME_PTR) 0x8d1e320
	driver_list = (struct font_driver_list *) 0x8cdf508
	ftype = 138624281
	family = 138624281
	alternate_familes = 138624281
	vec = (Lisp_Object *) 0xbfa9b390
	size = 0
	need_filtering = 0
	n_family = 1
	i = 0
#5  0x08272439 in font_find_for_lface (f=0x8d1e320, attrs=0x8908498, spec=145680892, c=-1) at font.c:2767
	frame = 147972900
	entities = 138868908
	val = 138683788
	props = {135187860, 138978176, 12, -1079397160, 135416860}
	size = 138624281
	i = 138624281
	result = 138624281
#6  0x08125250 in fontset_find_font (fontset=138978156, c=289, face=0x8908458, id=11, fallback=0) at fontset.c:606
	font_def = 147768636
	font_def = -1079397048
	font_entity = 138624281
	font_object = 138624281
	base_fontset = 138895988
	elt = 138978540
	vec = 142881828
	i = 2
	from = 160
	to = 591
	f = (FRAME_PTR) 0x8d1e320
#7  0x0812542a in fontset_font (fontset=143206396, c=289, face=0x8908458, id=11) at fontset.c:696
	rfont_def = 138624281
	base_fontset = 147593908
#8  0x08125a9b in face_for_char (f=0x8d1e320, face=0x8908458, c=289, pos=140, object=138624281) at fontset.c:913
	fontset = 143206396
	rfont_def = 129
	face_id = 138
	id = 11
#9  0x0827391a in font_range (pos=140, limit=142, face=0x8908458, f=0x8d1e320, string=138624281) at font.c:3258
	face_id = 0
	multibyte = 1
	pos_byte = 150
	c = 289
	font = (struct font *) 0x86580e8
	first = 0
#10 0x08075cfb in handle_auto_composed_prop (it=0xbfa9b99c) at xdisp.c:4640
	count = 5
	args = {138853945, 140669700, -1079396644, 138689248, 138624281}
	val = 138624281
	pos = 129
	limit = 142
	handled = HANDLED_NORMALLY
#11 0x08072524 in handle_stop (it=0xbfa9b99c) at xdisp.c:3073
	handled = HANDLED_NORMALLY
	handle_overlay_change_p = 1
	p = (struct props *) 0x829bb70
#12 0x08079f0a in next_element_from_buffer (it=0xbfa9b99c) at xdisp.c:6467
	success_p = 1
#13 0x080783e0 in get_next_display_element (it=0xbfa9b99c) at xdisp.c:5725
	success_p = 138624281
#14 0x0808e957 in display_line (it=0xbfa9b99c) at xdisp.c:16255
	n_glyphs_before = 48
	hpos_before = 48
	x_before = 480
	phys_ascent = 0
	phys_descent = 0
	x = 480
	nglyphs = 1
	descent = 0
	i = 0
	ascent = 0
	row = (struct glyph_row *) 0x88dfa08
	overlay_arrow_string = 138624281
#15 0x08088c20 in try_window (window=139909124, pos={charpos = 1, bytepos = 1}, check_margins=1) at xdisp.c:13835
	w = (struct window *) 0x856d800
	it = {
  window = 139909124, 
  w = 0x856d800, 
  f = 0x8d1e320, 
  method = GET_FROM_BUFFER, 
  stop_charpos = 129, 
  end_charpos = 3180, 
  s = 0x0, 
  string_nchars = 0, 
  region_beg_charpos = -1, 
  region_end_charpos = -1, 
  redisplay_end_trigger_charpos = 0, 
  multibyte_p = 1, 
  header_line_p = 0, 
  string_from_display_prop_p = 0, 
  ellipsis_p = 0, 
  dp = 0x0, 
  dpvec = 0x0, 
  dpend = 0x0, 
  dpvec_char_len = 0, 
  dpvec_face_id = 0, 
  saved_face_id = 19, 
  ctl_chars = {0 <repeats 16 times>}, 
  start = {
    pos = {
      charpos = 80, 
      bytepos = 80
    }, 
    overlay_string_index = -1, 
    string_pos = {
      charpos = -1, 
      bytepos = -1
    }, 
    dpvec_index = -1
  }, 
  current = {
    pos = {
      charpos = 129, 
      bytepos = 138
    }, 
    overlay_string_index = -1, 
    string_pos = {
      charpos = -1, 
      bytepos = -1
    }, 
    dpvec_index = -1
  }, 
  n_overlay_strings = 0, 
  overlay_strings = {0 <repeats 16 times>}, 
  string_overlays = {0 <repeats 16 times>}, 
  string = 138624281, 
  from_overlay = 0, 
  stack = {{
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        comp = {
          object = 0, 
          c = 0, 
          len = 0, 
          cmp_id = 0, 
          cmp_len = 0
        }, 
        stretch = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      multibyte_p = 0, 
      string_from_display_prop_p = 0, 
      display_ellipsis_p = 0, 
      space_width = 0, 
      font_height = 0, 
      voffset = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        comp = {
          object = 0, 
          c = 0, 
          len = 0, 
          cmp_id = 0, 
          cmp_len = 0
        }, 
        stretch = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      multibyte_p = 0, 
      string_from_display_prop_p = 0, 
      display_ellipsis_p = 0, 
      space_width = 0, 
      font_height = 0, 
      voffset = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        comp = {
          object = 0, 
          c = 0, 
          len = 0, 
          cmp_id = 0, 
          cmp_len = 0
        }, 
        stretch = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      multibyte_p = 0, 
      string_from_display_prop_p = 0, 
      display_ellipsis_p = 0, 
      space_width = 0, 
      font_height = 0, 
      voffset = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        comp = {
          object = 0, 
          c = 0, 
          len = 0, 
          cmp_id = 0, 
          cmp_len = 0
        }, 
        stretch = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      multibyte_p = 0, 
      string_from_display_prop_p = 0, 
      display_ellipsis_p = 0, 
      space_width = 0, 
      font_height = 0, 
      voffset = 0
    }}, 
  sp = 0, 
  selective = 0, 
  what = IT_CHARACTER, 
  face_id = 0, 
  selective_display_ellipsis_p = 1, 
  ctl_arrow_p = 1, 
  truncate_lines_p = 0, 
  face_box_p = 0, 
  start_of_box_run_p = 0, 
  end_of_box_run_p = 0, 
  overlay_strings_at_end_processed_p = 0, 
  ignore_overlay_strings_at_pos_p = 0, 
  glyph_not_available_p = 0, 
  starts_in_middle_of_char_p = 0, 
  face_before_selective_p = 0, 
  constrain_row_ascent_descent_p = 0, 
  base_face_id = 0, 
  c = 245, 
  len = 2, 
  cmp_id = 0, 
  cmp_len = 0, 
  char_to_display = 245, 
  image_id = 0, 
  slice = {
    x = 138624281, 
    y = 138624281, 
    width = 138624281, 
    height = 138624281
  }, 
  space_width = 138624281, 
  voffset = 0, 
  font_height = 138624281, 
  object = 140669700, 
  position = {
    charpos = 128, 
    bytepos = 136
  }, 
  tab_width = 32, 
  truncation_pixel_width = 0, 
  continuation_pixel_width = 0, 
  first_visible_x = 0, 
  last_visible_x = 800, 
  last_visible_y = 323, 
  extra_line_spacing = 0, 
  max_extra_line_spacing = 0, 
  override_ascent = -1, 
  override_descent = 0, 
  override_boff = 0, 
  glyph_row = 0x88dfa08, 
  area = TEXT_AREA, 
  nglyphs = 1, 
  pixel_width = 10, 
  ascent = 15, 
  descent = 4, 
  max_ascent = 15, 
  max_descent = 4, 
  phys_ascent = 12, 
  phys_descent = 0, 
  max_phys_ascent = 12, 
  max_phys_descent = 3, 
  current_x = 490, 
  continuation_lines_width = 0, 
  current_y = 57, 
  first_vpos = 0, 
  vpos = 3, 
  hpos = 49, 
  left_user_fringe_bitmap = 0, 
  right_user_fringe_bitmap = 0, 
  left_user_fringe_face_id = 0, 
  right_user_fringe_face_id = 0
}
	last_text_row = (struct glyph_row *) 0x88df970
	f = (struct frame *) 0x8d1e320
#16 0x08087a76 in redisplay_window (window=139909124, just_this_one_p=0) at xdisp.c:13453
	w = (struct window *) 0x856d800
	f = (struct frame *) 0x8d1e320
	buffer = (struct buffer *) 0x8627300
	old = (struct buffer *) 0x8627300
	lpoint = {
  charpos = 1, 
  bytepos = 1
}
	opoint = {
  charpos = 1, 
  bytepos = 1
}
	startp = {
  charpos = 1, 
  bytepos = 1
}
	update_mode_line = 1
	tem = 0
	it = {
  window = 12, 
  w = 0xc, 
  f = 0xf, 
  method = 15, 
  stop_charpos = 0, 
  end_charpos = 0, 
  s = 0x1 <Address 0x1 out of bounds>, 
  string_nchars = 0, 
  region_beg_charpos = 138624329, 
  region_end_charpos = -16121856, 
  redisplay_end_trigger_charpos = 0, 
  multibyte_p = 0, 
  header_line_p = 0, 
  string_from_display_prop_p = 0, 
  ellipsis_p = 0, 
  dp = 0x0, 
  dpvec = 0xbfa9bf48, 
  dpend = 0x820a90d, 
  dpvec_char_len = 0, 
  dpvec_face_id = 0, 
  saved_face_id = 148339253, 
  ctl_chars = {147972900, 0, 0, -1079394600, 134684119, -1079394548, 147744280, 1, 1, 138768960, 0, 8, 148660634, 0, 148660632, 0}, 
  start = {
    pos = {
      charpos = 0, 
      bytepos = 0
    }, 
    overlay_string_index = 0, 
    string_pos = {
      charpos = 1, 
      bytepos = 1
    }, 
    dpvec_index = 550
  }, 
  current = {
    pos = {
      charpos = 550, 
      bytepos = 55
    }, 
    overlay_string_index = 55, 
    string_pos = {
      charpos = 138624281, 
      bytepos = 138768960
    }, 
    dpvec_index = -1079393576
  }, 
  n_overlay_strings = 134777888, 
  overlay_strings = {-1079394548, 147744280, 1, 1, 0, 57, 57, 0, 1, -1, -1, 147744284, 147744280, 147972896, 0, 57}, 
  string_overlays = {57, 0, 0, -1, -1, 0, 0, 0, 0, 0, 0, 0, -1, 0, 0, 0}, 
  string = 0, 
  from_overlay = 0, 
  stack = {{
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        comp = {
          object = 0, 
          c = 0, 
          len = 0, 
          cmp_id = 0, 
          cmp_len = 0
        }, 
        stretch = {
          object = 0
        }
      }, 
      position = {
        charpos = 57, 
        bytepos = 57
      }, 
      current = {
        pos = {
          charpos = -1, 
          bytepos = -1
        }, 
        overlay_string_index = -1, 
        string_pos = {
          charpos = -1, 
          bytepos = 57
        }, 
        dpvec_index = 57
      }, 
      from_overlay = -1, 
      area = 4294967295, 
      method = 4294967295, 
      multibyte_p = 1, 
      string_from_display_prop_p = 1, 
      display_ellipsis_p = 1, 
      space_width = 0, 
      font_height = 0, 
      voffset = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        comp = {
          object = 0, 
          c = 0, 
          len = 0, 
          cmp_id = 0, 
          cmp_len = 0
        }, 
        stretch = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      multibyte_p = 0, 
      string_from_display_prop_p = 0, 
      display_ellipsis_p = 0, 
      space_width = 0, 
      font_height = 0, 
      voffset = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      face_id = 138624281, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        comp = {
          object = 0, 
          c = 0, 
          len = 0, 
          cmp_id = 0, 
          cmp_len = 0
        }, 
        stretch = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      multibyte_p = 0, 
      string_from_display_prop_p = 0, 
      display_ellipsis_p = 0, 
      space_width = 0, 
      font_height = 0, 
      voffset = 0
    }, {
      string = 0, 
      string_nchars = 0, 
      end_charpos = 0, 
      stop_charpos = 0, 
      face_id = 0, 
      u = {
        image = {
          object = 0, 
          slice = {
            x = 0, 
            y = 0, 
            width = 0, 
            height = 0
          }, 
          image_id = 0
        }, 
        comp = {
          object = 0, 
          c = 0, 
          len = 0, 
          cmp_id = 0, 
          cmp_len = 0
        }, 
        stretch = {
          object = 0
        }
      }, 
      position = {
        charpos = 0, 
        bytepos = 0
      }, 
      current = {
        pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        overlay_string_index = 0, 
        string_pos = {
          charpos = 0, 
          bytepos = 0
        }, 
        dpvec_index = 0
      }, 
      from_overlay = 0, 
      area = LEFT_MARGIN_AREA, 
      method = GET_FROM_BUFFER, 
      multibyte_p = 0, 
      string_from_display_prop_p = 0, 
      display_ellipsis_p = 0, 
      space_width = 0, 
      font_height = 0, 
      voffset = 0
    }}, 
  sp = 0, 
  selective = 0, 
  what = IT_CHARACTER, 
  face_id = 0, 
  selective_display_ellipsis_p = 0, 
  ctl_arrow_p = 0, 
  truncate_lines_p = 0, 
  face_box_p = 0, 
  start_of_box_run_p = 0, 
  end_of_box_run_p = 0, 
  overlay_strings_at_end_processed_p = 0, 
  ignore_overlay_strings_at_pos_p = 0, 
  glyph_not_available_p = 0, 
  starts_in_middle_of_char_p = 0, 
  face_before_selective_p = 0, 
  constrain_row_ascent_descent_p = 0, 
  base_face_id = 0, 
  c = 0, 
  len = 0, 
  cmp_id = 0, 
  cmp_len = 0, 
  char_to_display = 0, 
  image_id = 0, 
  slice = {
    x = 0, 
    y = 0, 
    width = 0, 
    height = 0
  }, 
  space_width = 0, 
  voffset = 0, 
  font_height = 0, 
  object = 0, 
  position = {
    charpos = 0, 
    bytepos = 0
  }, 
  tab_width = 0, 
  truncation_pixel_width = 0, 
  continuation_pixel_width = 0, 
  first_visible_x = 0, 
  last_visible_x = 0, 
  last_visible_y = 0, 
  extra_line_spacing = 0, 
  max_extra_line_spacing = 0, 
  override_ascent = 0, 
  override_descent = 0, 
  override_boff = 0, 
  glyph_row = 0x0, 
  area = LEFT_MARGIN_AREA, 
  nglyphs = 2, 
  pixel_width = 0, 
  ascent = 0, 
  descent = 0, 
  max_ascent = 0, 
  max_descent = 0, 
  phys_ascent = 0, 
  phys_descent = 0, 
  max_phys_ascent = 0, 
  max_phys_descent = 0, 
  current_x = 0, 
  continuation_lines_width = 2, 
  current_y = 138624281, 
  first_vpos = 148598133, 
  vpos = -1079393816, 
  hpos = 136260151, 
  left_user_fringe_bitmap = 39649, 
  right_user_fringe_bitmap = 2117, 
  left_user_fringe_face_id = 370610, 
  right_user_fringe_face_id = 1797493
}
	current_matrix_up_to_date_p = 0
	used_current_matrix_p = 0
	buffer_unchanged_p = 0
	temp_scroll_step = 0
	count = 4
	rc = 138779361
	centering_position = -1
	last_line_misfit = 0
	beg_unchanged = -1
	end_unchanged = 0
#17 0x08083ebb in redisplay_window_0 (window=139909124) at xdisp.c:12044
No locals.
#18 0x0820981a in internal_condition_case_1 (bfun=0x8083e88 <redisplay_window_0>, arg=139909124, handlers=138610917, hfun=0x8083e67 <redisplay_window_error>) at eval.c:1549
	val = 0
	c = {
  tag = 138624281, 
  val = 138624281, 
  next = 0xbfa9d2f8, 
  gcpro = 0x0, 
  jmp = {{
      __jmpbuf = {64, 1, -1079390500, -1079393416, 1199906945, 1429172718}, 
      __mask_was_saved = 0, 
      __saved_mask = {
        __val = {138624281, 143205872, 3200000, 147744280, 138668690, 138668690, 138668690, 147744284, 138624281, 140073340, 134731693, 0, 0, 3215573848, 136366755, 138686265, 3200000, 140669696, 1, 147744284, 4406553, 3215573848, 134731359, 5, 138686265, 3200000, 0, 0, 64, 3215573848, 136243609, 5}
      }
    }}, 
  backlist = 0x0, 
  handlerlist = 0xbfa9d3c0, 
  lisp_eval_depth = 0, 
  pdlcount = 4, 
  poll_suppress_count = 1, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
	h = {
  handler = 138610917, 
  var = 138624281, 
  chosen_clause = 134732646, 
  tag = 0xbfa9c298, 
  next = 0xbfa9d3c0
}
#19 0x08083e4e in redisplay_windows (window=139909124) at xdisp.c:12023
	w = (struct window *) 0x856d800
#20 0x08083e1a in redisplay_windows (window=147671508) at xdisp.c:12017
	w = (struct window *) 0x8cd49d0
#21 0x08083251 in redisplay_internal (preserve_echo_area=0) at xdisp.c:11589
	f = (struct frame *) 0x8d1e320
	tail = 139207181
	frame = 147972900
	w = (struct window *) 0x856d800
	f = (struct frame *) 0x8d1e320
	pause = 0
	must_finish = 1
	tlbufpos = {
  charpos = 704, 
  bytepos = 704
}
	tlendpos = {
  charpos = 1085, 
  bytepos = 1085
}
	number_of_visible_frames = 1
	count = 2
	count1 = 4
	sf = (struct frame *) 0x8d1e320
	polling_stopped_here = 0
	old_frame = 147972900
	consider_all_windows_p = 1
#22 0x08081674 in redisplay () at xdisp.c:10800
No locals.
#23 0x0818356a in read_char (commandflag=1, nmaps=3, maps=0xbfa9cee0, prev_event=138624281, used_mouse_menu=0xbfa9d0d0, end_time=0x0) at keyboard.c:2687
	echo_current = 0
	c = 138624281
	count = -1
	jmpcount = -1079390800
	local_getcjmp = {{
    __jmpbuf = {-1079390888, 136712306, 138624281, 138653617, 1, 89}, 
    __mask_was_saved = 0, 
    __saved_mask = {
      __val = {139968464, 3215576424, 136723146, 138624281, 3215576400, 3215576696, 136723867, 0, 0, 140669700, 0, 0, 0, 0, 1, 0, 144485481, 3215576728, 136292752, 138653617, 8, 140669700, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
    }
  }}
	save_jump = {{
    __jmpbuf = {1, 139968464, 0, 3179, 0, 0}, 
    __mask_was_saved = 0, 
    __saved_mask = {
      __val = {0, 0, 58657919, 147744284, 147744280, 1, 0, 0, 57, 0, 0, 140669700, 3215576344, 136719568, 139968464, 1, 139968464, 0, 139969592, 138624281, 4294967295, 0, 0, 1, 3215576376, 136712512, 138653617, 138624281, 138624281, 138624281, 138624281, 3215576352}
    }
  }}
	key_already_recorded = 0
	tem = 148355365
	save = 135885107
	previous_echo_area_message = 138624281
	also_record = 138624281
	reread = 0
	gcpro1 = {
  next = 0x0, 
  var = 0x0, 
  nvars = 0
}
	gcpro2 = {
  next = 0x0, 
  var = 0x0, 
  nvars = 0
}
	polling_stopped_here = 0
	orig_kboard = (struct kboard *) 0x89a7c08
#24 0x0818df87 in read_key_sequence (keybuf=0xbfa9d228, bufsize=30, prompt=138624281, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9441
	interrupted_kboard = (KBOARD *) 0x89a7c08
	interrupted_frame = (struct frame *) 0x8d1e320
	key = 138624281
	used_mouse_menu = 0
	echo_local_start = 0
	last_real_key_start = 0
	keys_local_start = 0
	local_first_binding = 0
	from_string = 138624281
	count = 2
	t = 0
	echo_start = 0
	keys_start = 0
	nmaps = 3
	nmaps_allocated = 3
	defs = (Lisp_Object * volatile) 0xbfa9cec0
	submaps = (Lisp_Object * volatile) 0xbfa9cee0
	orig_local_map = 138624281
	orig_keymap = 138624281
	localized_local_map = 0
	first_binding = 0
	first_unbound = 31
	mock_input = 0
	fkey = {
  parent = 148479517, 
  map = 148479517, 
  start = 0, 
  end = 0
}
	keytran = {
  parent = 138617725, 
  map = 138617725, 
  start = 0, 
  end = 0
}
	indec = {
  parent = 148479525, 
  map = 148479525, 
  start = 0, 
  end = 0
}
	shift_translated = 0
	delayed_switch_frame = 138624281
	original_uppercase = 2
	original_uppercase_position = -1
	dummyflag = 0
	starting_buffer = (struct buffer *) 0x8627300
	fake_prefixed_keys = 138624281
	gcpro1 = {
  next = 0x8453cc0, 
  var = 0x8dc6180, 
  nvars = -1079390104
}
#25 0x08180a87 in command_loop_1 () at keyboard.c:1653
	cmd = 144485481
	lose = 135791816
	nonundocount = 0
	keybuf = {64, 832, -1221022820, -1079443454, -1208855975, 134544895, -1219534244, -1208803340, -1079389552, -1225201656, -1079389500, -1208876967, 0, 0, 0, 0, -1208818244, 0, -1079389508, -1079389808, 0, -1221066752, -1221043968, 0, 0, 0, 0, 0, 1, 1006}
	i = 2
	prev_modiff = 300
	prev_buffer = (struct buffer *) 0x875be18
	already_adjusted = 0
#26 0x08209700 in internal_condition_case (bfun=0x818074d <command_loop_1>, handlers=138667425, hfun=0x818010c <cmd_error>) at eval.c:1501
	val = 138933997
	c = {
  tag = 138624281, 
  val = 138624281, 
  next = 0xbfa9d410, 
  gcpro = 0x0, 
  jmp = {{
      __jmpbuf = {-1219698700, -1208804128, 0, -1079389224, 1202053249, 1429031406}, 
      __mask_was_saved = 0, 
      __saved_mask = {
        __val = {3075433056, 3075433040, 3073960732, 3215523842, 3086111321, 134544895, 3075433052, 3086163956, 3215577648, 3069765640, 3215577700, 3086090329, 3075268596, 148700560, 147949288, 3215577636, 3086149052, 3215577648, 3215577904, 276967387, 61, 3073928380, 3215578320, 3086163168, 3073944476, 3075433144, 135912178, 4294967295, 3086163956, 134523816, 3086165608, 3215578080}
      }
    }}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 1, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
	h = {
  handler = 138667425, 
  var = 138624281, 
  chosen_clause = 136949092, 
  tag = 0xbfa9d2f8, 
  next = 0x0
}
#27 0x081804a3 in command_loop_2 () at keyboard.c:1369
	val = 144017848
#28 0x082091e6 in internal_catch (tag=138663401, func=0x8180480 <command_loop_2>, arg=138624281) at eval.c:1237
	c = {
  tag = 138663401, 
  val = 138624281, 
  next = 0x0, 
  gcpro = 0x0, 
  jmp = {{
      __jmpbuf = {-1219698700, -1208804128, 0, -1079388968, 1202192513, 1428402158}, 
      __mask_was_saved = 0, 
      __saved_mask = {
        __val = {134931835, 138754920, 0, 0, 0, 2, 0, 3074354577, 0, 0, 0, 0, 0, 0, 0, 3074354577, 0, 0, 3075273104, 3215578328, 136261659, 138853705, 138850418, 138624281, 138650128, 0, 3075273104, 0, 138624281, 138624281, 138850418, 138850418}
      }
    }}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 1, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
#29 0x08180459 in command_loop () at keyboard.c:1348
No locals.
#30 0x0817fd19 in recursive_edit_1 () at keyboard.c:957
	count = 1
	val = -1208804128
#31 0x0817fe87 in Frecursive_edit () at keyboard.c:1019
	count = 0
	buffer = 138624281
#32 0x0817e740 in main (argc=4, argv=0xbfa9d984) at emacs.c:1778
	dummy = -1079387912
	stack_bottom_variable = 8 '\b'
	do_initial_setlocale = 1
	skip_args = 0
	rlim = {
  rlim_cur = 8388608, 
  rlim_max = 18446744073709551615
}
	no_loadup = 0
	junk = 0x0



Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

>
> The change log files are not yet ready.  I committed partial
> one in src/ChangeLog.fb.
>
> As for Windows port:
>
> I tried to compile it on Windows in cygwin environment.  By,
> "make bootstrap", it seems that src/oo-spd/i386/emacs.exe is
> created, but the make failed at the target finder-data of
> lisp/makefile.  And, when I run src/oo-spd/i386/emacs, it
> starts up without an error, but, non-ASCII characters are
> not correctly displayed by garbage glyphs.  Perhaps, there's
> something wrong in my changes on src/w32*.[ch].  I'm now
> trying to find what is wrong, but, Jason, could you please
> investigate it too?
>
> As for Mac port:
>
> I didn't touch any mac-specific files.  So, it can't be
> compiled.  Mac-port maintainers, please adjust codes for the
> new font.h and font.c by checking what I've done for the
> other font-backend codes (and xterm.c and xfns.c).
>
> ---
> Kenichi Handa
> handa@ni.aist.go.jp

-- 
Florian Beck

Re: font-backend branch

[Kenichi Handa]

In article <481DCC48.4040700@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > Yes.  But, modifying all of "x-list-fonts and things like
> > that" can't be done quickly, and as it is not that urgent
> > task, we can leave it until later.  On the other hand,
> > setting FONT_NAME_INDEX of font-vector to a font name of
> > XLFD format can be done easily and quickly.
> >   

> OK, I understand now, it is a temporary measure to avoid inconveniencing 
> users while this work is ongoing. I'll change the w32 font code for now 
> then.

Thank you.

> Kenichi Handa wrote:
> > Yes.  As soon as Windows port code gets stable, I'll merge
> > it to the trunk.
> >   

> I think it is ready to merge now.

I have a trip from Tomorrow to join 2008 Text Layout Summit
held in conjunction with the Libre Graphics Meeting in
Wrocław, Poland (are there anyone else who join it?).  So, I
don't have a time to finish ChangeLogs now.  I'll work on
merging after I come back to Japan.  If you think the mering
should be done as soon as possible, please go ahead.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: font-backend branch

[Kenichi Handa]

In article <jwvlk2pr2i7.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > OK, I understand now, it is a temporary measure to avoid inconveniencing
> > users while this work is ongoing. I'll change the w32 font code for
> > now then.

> Please make sure there's a comment explaining the reason behind
> the code.

For that, I've just committed this change.

---
Kenichi Handa
handa@ni.aist.go.jp

*** frame.c.~1.370.2.1.~	2008-04-30 10:45:03.000000000 +0900
--- frame.c	2008-05-06 20:23:46.000000000 +0900
***************
*** 3371,3376 ****
--- 3371,3379 ----
    else if (FONT_OBJECT_P (arg))
      {
        font_object = arg;
+       /* This is store the XLFD font name in the frame parameter for
+ 	 backward compatiblity.  We should store the font-object
+ 	 itself in the future.  */
        arg = AREF (font_object, FONT_NAME_INDEX);
      }
    else

Re: font-backend branch

[Stefan Monnier]

> For that, I've just committed this change.

> ---
> Kenichi Handa
> handa@ni.aist.go.jp

> *** frame.c.~1.370.2.1.~	2008-04-30 10:45:03.000000000 +0900
> --- frame.c	2008-05-06 20:23:46.000000000 +0900
> ***************
> *** 3371,3376 ****
> --- 3371,3379 ----
>     else if (FONT_OBJECT_P (arg))
>       {
>         font_object = arg;
> +       /* This is store the XLFD font name in the frame parameter for
> + 	 backward compatiblity.  We should store the font-object
> + 	 itself in the future.  */
>         arg = AREF (font_object, FONT_NAME_INDEX);
>       }
>     else

Hmm... that doesn't say why we do it.  The crucial info is that we
want to return an object that can be passed to x-list-fonts.


        Stefan

Font not found

[Robert J. Chassell]

Although mouse-set-font finds 15, 18, and 24 point fixed fonts in
lisp/mouse.el in x-fixed-font-alist

     ("9x15" "-misc-fixed-medium-r-normal--15-*-*-*-c-90-iso8859-1" "9x15")
     ("11x18" "-misc-fixed-medium-r-normal--18-*-*-*-c-110-iso8859-1" "11x18")
     ("12x24" "-misc-fixed-medium-r-normal--24-*-*-*-c-120-iso8859-1" "12x24")

it says `Font not found' for the 20 point font, as has happened
before, even though x-fixed-font-alist in lisp/mouse.el says

     ("10x20" "-misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1" "10x20")

Today's GNU Emacs CVS snapshot, Wed, 2008 May 14  10:03 UTC
GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9)

built

       make maintainer-clean && \
       time autoconf && time ./configure \
         --disable-font-backend \
         --with-x --with-type1 --with-x-toolkit=gtk && \
        time make bootstrap

and started with

    emacs -Q -D

(I disable the font backend because of other problems I have reported
before.  In yesterday's CVS snapshot, built with the same configuration,
the "-misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1" font was
found.)

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Font not found

[Kenichi Handa]

In article <m1JwH4R-002K4UC@rattlesnake.com>, "Robert J. Chassell" <bob@rattlesnake.com> writes:

> Although mouse-set-font finds 15, 18, and 24 point fixed fonts in
> lisp/mouse.el in x-fixed-font-alist

>      ("9x15" "-misc-fixed-medium-r-normal--15-*-*-*-c-90-iso8859-1" "9x15")
>      ("11x18" "-misc-fixed-medium-r-normal--18-*-*-*-c-110-iso8859-1" "11x18")
>      ("12x24" "-misc-fixed-medium-r-normal--24-*-*-*-c-120-iso8859-1" "12x24")

> it says `Font not found' for the 20 point font, as has happened
> before, even though x-fixed-font-alist in lisp/mouse.el says

>      ("10x20" "-misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1" "10x20")

I can't reproduce that problem.  When I select 10x20, Emacs
uses the font
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1
which is the same one opened by:
% xfd -fn -misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1

In your environment, which font the above command opens, and
what is the result of this command?
% xlsfonts -fn -misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1

---
Kenichi Handa
handa@ni.aist.go.jp

Re: Font not found

[Robert J. Chassell]

    I can't reproduce that problem.  When I select 10x20, Emacs
    uses the font
    -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1
    which is the same one opened by:
    % xfd -fn -misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1

I still cannot see the 10x20 font in Emacs.

    In your environment, which font the above command opens,

  xfd -fn -misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1

That command opens an X windows box with

  -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO8859-1

in it.

    what is the result of this command?
    % xlsfonts -fn -misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1


  $  xlsfonts -fn -misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-140-100-100-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-145-100-100-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-145-100-100-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-145-100-100-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-145-100-100-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-145-100-100-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-145-100-100-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1
  -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1


In other words, the results were the same as before:

    Although mouse-set-font finds 15, 18, and 24 point fixed fonts in
    lisp/mouse.el in x-fixed-font-alist

       ("9x15" "-misc-fixed-medium-r-normal--15-*-*-*-c-90-iso8859-1" "9x15")
       ("11x18" "-misc-fixed-medium-r-normal--18-*-*-*-c-110-iso8859-1" "11x18")
       ("12x24" "-misc-fixed-medium-r-normal--24-*-*-*-c-120-iso8859-1" "12x24")

    it says `Font not found' for the 20 point font, as has happened
    before, even though x-fixed-font-alist in lisp/mouse.el says

       ("10x20" "-misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1" "10x20")

However, in today's GNU Emacs CVS snapshot, Thu, 2008 May 15 11:10 UTC
GNU Emacs 23.0.60.4 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
built with        make
in Debian (rebooted with yesterday's testing distribution)
with kernel 2.6.22

with the same configuration as before
  ./configure --disable-font-backend --with-x --with-type1 --with-x-toolkit=gtk

and started with

    emacs -Q -D --eval '(setq debug-on-error t)'

The failure reported for the 10x20 font was

    Debugger entered--Lisp error: (error "Font not found")
      ad-Orig-signal(error ("Font not found"))
      signal(error ("Font not found"))
      ad-Orig-error("Font not found")
      apply(ad-Orig-error "Font not found")
      error("Font not found")
      mouse-set-font("-misc-fixed-medium-r-normal--20-*-*-*-c-100-iso8859-1" "10x20")
      call-interactively(mouse-set-font nil nil)

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc