* font-backend branch
@ 2008-04-30 4:24 Kenichi Handa
2008-04-30 6:04 ` Stefan Monnier
` (6 more replies)
0 siblings, 7 replies; 45+ messages in thread
From: Kenichi Handa @ 2008-04-30 4:24 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 4:24 font-backend branch Kenichi Handa
@ 2008-04-30 6:04 ` Stefan Monnier
2008-04-30 7:39 ` Kenichi Handa
2008-04-30 11:38 ` Juanma Barranquero
` (5 subsequent siblings)
6 siblings, 1 reply; 45+ messages in thread
From: Stefan Monnier @ 2008-04-30 6:04 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 6:04 ` Stefan Monnier
@ 2008-04-30 7:39 ` Kenichi Handa
0 siblings, 0 replies; 45+ messages in thread
From: Kenichi Handa @ 2008-04-30 7:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 4:24 font-backend branch Kenichi Handa
2008-04-30 6:04 ` Stefan Monnier
@ 2008-04-30 11:38 ` Juanma Barranquero
2008-04-30 13:12 ` Kenichi Handa
2008-04-30 16:38 ` Eli Zaretskii
` (4 subsequent siblings)
6 siblings, 1 reply; 45+ messages in thread
From: Juanma Barranquero @ 2008-04-30 11:38 UTC (permalink / raw)
To: Kenichi Handa; +Cc: Jason Rumney, emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 11:38 ` Juanma Barranquero
@ 2008-04-30 13:12 ` Kenichi Handa
2008-04-30 13:47 ` Juanma Barranquero
0 siblings, 1 reply; 45+ messages in thread
From: Kenichi Handa @ 2008-04-30 13:12 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: emacs-devel, jasonr
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 13:12 ` Kenichi Handa
@ 2008-04-30 13:47 ` Juanma Barranquero
0 siblings, 0 replies; 45+ messages in thread
From: Juanma Barranquero @ 2008-04-30 13:47 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel, jasonr
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 4:24 font-backend branch Kenichi Handa
2008-04-30 6:04 ` Stefan Monnier
2008-04-30 11:38 ` Juanma Barranquero
@ 2008-04-30 16:38 ` Eli Zaretskii
2008-04-30 20:23 ` Glenn Morris
` (3 subsequent siblings)
6 siblings, 0 replies; 45+ messages in thread
From: Eli Zaretskii @ 2008-04-30 16:38 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 4:24 font-backend branch Kenichi Handa
` (2 preceding siblings ...)
2008-04-30 16:38 ` Eli Zaretskii
@ 2008-04-30 20:23 ` Glenn Morris
2008-04-30 21:11 ` Glenn Morris
2008-05-01 1:01 ` Kenichi Handa
2008-04-30 23:48 ` Jason Rumney
` (2 subsequent siblings)
6 siblings, 2 replies; 45+ messages in thread
From: Glenn Morris @ 2008-04-30 20:23 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 20:23 ` Glenn Morris
@ 2008-04-30 21:11 ` Glenn Morris
2008-04-30 21:28 ` Glenn Morris
2008-05-01 1:01 ` Kenichi Handa
1 sibling, 1 reply; 45+ messages in thread
From: Glenn Morris @ 2008-04-30 21:11 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 21:11 ` Glenn Morris
@ 2008-04-30 21:28 ` Glenn Morris
0 siblings, 0 replies; 45+ messages in thread
From: Glenn Morris @ 2008-04-30 21:28 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
Glenn Morris wrote:
> Just a missing `;' at the end of line 3761.
The same line is missing the `F' from Ffont_xlfd_name.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 4:24 font-backend branch Kenichi Handa
` (3 preceding siblings ...)
2008-04-30 20:23 ` Glenn Morris
@ 2008-04-30 23:48 ` Jason Rumney
2008-05-01 0:24 ` Jason Rumney
2008-05-02 10:55 ` Kenichi Handa
2008-05-01 3:54 ` Glenn Morris
2008-05-05 10:14 ` Florian Beck
6 siblings, 2 replies; 45+ messages in thread
From: Jason Rumney @ 2008-04-30 23:48 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 23:48 ` Jason Rumney
@ 2008-05-01 0:24 ` Jason Rumney
2008-05-02 10:55 ` Kenichi Handa
1 sibling, 0 replies; 45+ messages in thread
From: Jason Rumney @ 2008-05-01 0:24 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 20:23 ` Glenn Morris
2008-04-30 21:11 ` Glenn Morris
@ 2008-05-01 1:01 ` Kenichi Handa
1 sibling, 0 replies; 45+ messages in thread
From: Kenichi Handa @ 2008-05-01 1:01 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 4:24 font-backend branch Kenichi Handa
` (4 preceding siblings ...)
2008-04-30 23:48 ` Jason Rumney
@ 2008-05-01 3:54 ` Glenn Morris
2008-05-01 6:27 ` Kenichi Handa
2008-05-05 10:14 ` Florian Beck
6 siblings, 1 reply; 45+ messages in thread
From: Glenn Morris @ 2008-05-01 3:54 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-01 3:54 ` Glenn Morris
@ 2008-05-01 6:27 ` Kenichi Handa
2008-05-01 7:07 ` Glenn Morris
2008-05-01 8:00 ` Kenichi Handa
0 siblings, 2 replies; 45+ messages in thread
From: Kenichi Handa @ 2008-05-01 6:27 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-01 6:27 ` Kenichi Handa
@ 2008-05-01 7:07 ` Glenn Morris
2008-05-01 7:21 ` Kenichi Handa
2008-05-01 8:00 ` Kenichi Handa
1 sibling, 1 reply; 45+ messages in thread
From: Glenn Morris @ 2008-05-01 7:07 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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!
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-01 7:07 ` Glenn Morris
@ 2008-05-01 7:21 ` Kenichi Handa
2008-05-01 7:28 ` Glenn Morris
0 siblings, 1 reply; 45+ messages in thread
From: Kenichi Handa @ 2008-05-01 7:21 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-01 7:21 ` Kenichi Handa
@ 2008-05-01 7:28 ` Glenn Morris
2008-05-01 15:20 ` Kenichi Handa
0 siblings, 1 reply; 45+ messages in thread
From: Glenn Morris @ 2008-05-01 7:28 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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)
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-01 6:27 ` Kenichi Handa
2008-05-01 7:07 ` Glenn Morris
@ 2008-05-01 8:00 ` Kenichi Handa
2008-05-02 1:14 ` James Cloos
1 sibling, 1 reply; 45+ messages in thread
From: Kenichi Handa @ 2008-05-01 8:00 UTC (permalink / raw)
To: Kenichi Handa; +Cc: rgm, emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-01 7:28 ` Glenn Morris
@ 2008-05-01 15:20 ` Kenichi Handa
2008-05-01 17:52 ` Glenn Morris
0 siblings, 1 reply; 45+ messages in thread
From: Kenichi Handa @ 2008-05-01 15:20 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-01 15:20 ` Kenichi Handa
@ 2008-05-01 17:52 ` Glenn Morris
2008-05-02 0:22 ` Kenichi Handa
0 siblings, 1 reply; 45+ messages in thread
From: Glenn Morris @ 2008-05-01 17:52 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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! :)
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-01 17:52 ` Glenn Morris
@ 2008-05-02 0:22 ` Kenichi Handa
0 siblings, 0 replies; 45+ messages in thread
From: Kenichi Handa @ 2008-05-02 0:22 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-01 8:00 ` Kenichi Handa
@ 2008-05-02 1:14 ` James Cloos
2008-05-02 2:15 ` Kenichi Handa
0 siblings, 1 reply; 45+ messages in thread
From: James Cloos @ 2008-05-02 1:14 UTC (permalink / raw)
To: emacs-devel; +Cc: Kenichi Handa
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-02 1:14 ` James Cloos
@ 2008-05-02 2:15 ` Kenichi Handa
2008-05-02 8:16 ` Jason Rumney
2008-05-04 22:00 ` Jason Rumney
0 siblings, 2 replies; 45+ messages in thread
From: Kenichi Handa @ 2008-05-02 2:15 UTC (permalink / raw)
To: James Cloos; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-02 2:15 ` Kenichi Handa
@ 2008-05-02 8:16 ` Jason Rumney
2008-05-04 22:00 ` Jason Rumney
1 sibling, 0 replies; 45+ messages in thread
From: Jason Rumney @ 2008-05-02 8:16 UTC (permalink / raw)
To: Kenichi Handa; +Cc: James Cloos, emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 23:48 ` Jason Rumney
2008-05-01 0:24 ` Jason Rumney
@ 2008-05-02 10:55 ` Kenichi Handa
2008-05-02 11:30 ` Jason Rumney
1 sibling, 1 reply; 45+ messages in thread
From: Kenichi Handa @ 2008-05-02 10:55 UTC (permalink / raw)
To: Jason Rumney; +Cc: emacs-devel
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;
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-02 10:55 ` Kenichi Handa
@ 2008-05-02 11:30 ` Jason Rumney
2008-05-02 11:42 ` Jason Rumney
2008-05-02 12:16 ` Kenichi Handa
0 siblings, 2 replies; 45+ messages in thread
From: Jason Rumney @ 2008-05-02 11:30 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-02 11:30 ` Jason Rumney
@ 2008-05-02 11:42 ` Jason Rumney
2008-05-02 12:16 ` Kenichi Handa
1 sibling, 0 replies; 45+ messages in thread
From: Jason Rumney @ 2008-05-02 11:42 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-02 11:30 ` Jason Rumney
2008-05-02 11:42 ` Jason Rumney
@ 2008-05-02 12:16 ` Kenichi Handa
2008-05-02 13:27 ` Jason Rumney
1 sibling, 1 reply; 45+ messages in thread
From: Kenichi Handa @ 2008-05-02 12:16 UTC (permalink / raw)
To: Jason Rumney; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-02 12:16 ` Kenichi Handa
@ 2008-05-02 13:27 ` Jason Rumney
2008-05-04 0:05 ` Kenichi Handa
0 siblings, 1 reply; 45+ messages in thread
From: Jason Rumney @ 2008-05-02 13:27 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-02 13:27 ` Jason Rumney
@ 2008-05-04 0:05 ` Kenichi Handa
2008-05-04 0:57 ` Stefan Monnier
2008-05-04 14:08 ` Jason Rumney
0 siblings, 2 replies; 45+ messages in thread
From: Kenichi Handa @ 2008-05-04 0:05 UTC (permalink / raw)
To: Jason Rumney; +Cc: emacs-devel
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'
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-04 0:05 ` Kenichi Handa
@ 2008-05-04 0:57 ` Stefan Monnier
2008-05-04 11:52 ` Kenichi Handa
2008-05-04 14:14 ` Jason Rumney
2008-05-04 14:08 ` Jason Rumney
1 sibling, 2 replies; 45+ messages in thread
From: Stefan Monnier @ 2008-05-04 0:57 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel, Jason Rumney
>> 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-04 0:57 ` Stefan Monnier
@ 2008-05-04 11:52 ` Kenichi Handa
2008-05-04 14:46 ` Jason Rumney
2008-05-04 14:14 ` Jason Rumney
1 sibling, 1 reply; 45+ messages in thread
From: Kenichi Handa @ 2008-05-04 11:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: jasonr, emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-04 0:05 ` Kenichi Handa
2008-05-04 0:57 ` Stefan Monnier
@ 2008-05-04 14:08 ` Jason Rumney
1 sibling, 0 replies; 45+ messages in thread
From: Jason Rumney @ 2008-05-04 14:08 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-04 0:57 ` Stefan Monnier
2008-05-04 11:52 ` Kenichi Handa
@ 2008-05-04 14:14 ` Jason Rumney
1 sibling, 0 replies; 45+ messages in thread
From: Jason Rumney @ 2008-05-04 14:14 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, Kenichi Handa
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-04 11:52 ` Kenichi Handa
@ 2008-05-04 14:46 ` Jason Rumney
2008-05-05 0:58 ` Stefan Monnier
2008-05-06 11:16 ` font-backend branch Kenichi Handa
0 siblings, 2 replies; 45+ messages in thread
From: Jason Rumney @ 2008-05-04 14:46 UTC (permalink / raw)
To: Kenichi Handa; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-02 2:15 ` Kenichi Handa
2008-05-02 8:16 ` Jason Rumney
@ 2008-05-04 22:00 ` Jason Rumney
1 sibling, 0 replies; 45+ messages in thread
From: Jason Rumney @ 2008-05-04 22:00 UTC (permalink / raw)
To: Kenichi Handa; +Cc: James Cloos, emacs-devel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-04 14:46 ` Jason Rumney
@ 2008-05-05 0:58 ` Stefan Monnier
2008-05-06 11:25 ` Kenichi Handa
2008-05-06 11:16 ` font-backend branch Kenichi Handa
1 sibling, 1 reply; 45+ messages in thread
From: Stefan Monnier @ 2008-05-05 0:58 UTC (permalink / raw)
To: Jason Rumney; +Cc: emacs-devel, Kenichi Handa
>> 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-04-30 4:24 font-backend branch Kenichi Handa
` (5 preceding siblings ...)
2008-05-01 3:54 ` Glenn Morris
@ 2008-05-05 10:14 ` Florian Beck
6 siblings, 0 replies; 45+ messages in thread
From: Florian Beck @ 2008-05-05 10:14 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-04 14:46 ` Jason Rumney
2008-05-05 0:58 ` Stefan Monnier
@ 2008-05-06 11:16 ` Kenichi Handa
1 sibling, 0 replies; 45+ messages in thread
From: Kenichi Handa @ 2008-05-06 11:16 UTC (permalink / raw)
To: Jason Rumney; +Cc: monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-05 0:58 ` Stefan Monnier
@ 2008-05-06 11:25 ` Kenichi Handa
2008-05-07 1:53 ` Stefan Monnier
2008-05-14 13:31 ` Font not found Robert J. Chassell
0 siblings, 2 replies; 45+ messages in thread
From: Kenichi Handa @ 2008-05-06 11:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, jasonr
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: font-backend branch
2008-05-06 11:25 ` Kenichi Handa
@ 2008-05-07 1:53 ` Stefan Monnier
2008-05-14 13:31 ` Font not found Robert J. Chassell
1 sibling, 0 replies; 45+ messages in thread
From: Stefan Monnier @ 2008-05-07 1:53 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel, jasonr
> 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Font not found
2008-05-06 11:25 ` Kenichi Handa
2008-05-07 1:53 ` Stefan Monnier
@ 2008-05-14 13:31 ` Robert J. Chassell
2008-05-15 3:39 ` Kenichi Handa
1 sibling, 1 reply; 45+ messages in thread
From: Robert J. Chassell @ 2008-05-14 13:31 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Font not found
2008-05-14 13:31 ` Font not found Robert J. Chassell
@ 2008-05-15 3:39 ` Kenichi Handa
2008-05-15 12:27 ` Robert J. Chassell
0 siblings, 1 reply; 45+ messages in thread
From: Kenichi Handa @ 2008-05-15 3:39 UTC (permalink / raw)
To: bob; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Font not found
2008-05-15 3:39 ` Kenichi Handa
@ 2008-05-15 12:27 ` Robert J. Chassell
0 siblings, 0 replies; 45+ messages in thread
From: Robert J. Chassell @ 2008-05-15 12:27 UTC (permalink / raw)
To: Kenichi Handa; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2008-05-15 12:27 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-30 4:24 font-backend branch Kenichi Handa
2008-04-30 6:04 ` Stefan Monnier
2008-04-30 7:39 ` Kenichi Handa
2008-04-30 11:38 ` Juanma Barranquero
2008-04-30 13:12 ` Kenichi Handa
2008-04-30 13:47 ` Juanma Barranquero
2008-04-30 16:38 ` Eli Zaretskii
2008-04-30 20:23 ` Glenn Morris
2008-04-30 21:11 ` Glenn Morris
2008-04-30 21:28 ` Glenn Morris
2008-05-01 1:01 ` Kenichi Handa
2008-04-30 23:48 ` Jason Rumney
2008-05-01 0:24 ` Jason Rumney
2008-05-02 10:55 ` Kenichi Handa
2008-05-02 11:30 ` Jason Rumney
2008-05-02 11:42 ` Jason Rumney
2008-05-02 12:16 ` Kenichi Handa
2008-05-02 13:27 ` Jason Rumney
2008-05-04 0:05 ` Kenichi Handa
2008-05-04 0:57 ` Stefan Monnier
2008-05-04 11:52 ` Kenichi Handa
2008-05-04 14:46 ` Jason Rumney
2008-05-05 0:58 ` Stefan Monnier
2008-05-06 11:25 ` Kenichi Handa
2008-05-07 1:53 ` Stefan Monnier
2008-05-14 13:31 ` Font not found Robert J. Chassell
2008-05-15 3:39 ` Kenichi Handa
2008-05-15 12:27 ` Robert J. Chassell
2008-05-06 11:16 ` font-backend branch Kenichi Handa
2008-05-04 14:14 ` Jason Rumney
2008-05-04 14:08 ` Jason Rumney
2008-05-01 3:54 ` Glenn Morris
2008-05-01 6:27 ` Kenichi Handa
2008-05-01 7:07 ` Glenn Morris
2008-05-01 7:21 ` Kenichi Handa
2008-05-01 7:28 ` Glenn Morris
2008-05-01 15:20 ` Kenichi Handa
2008-05-01 17:52 ` Glenn Morris
2008-05-02 0:22 ` Kenichi Handa
2008-05-01 8:00 ` Kenichi Handa
2008-05-02 1:14 ` James Cloos
2008-05-02 2:15 ` Kenichi Handa
2008-05-02 8:16 ` Jason Rumney
2008-05-04 22:00 ` Jason Rumney
2008-05-05 10:14 ` Florian Beck
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.