* 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 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 ` (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 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 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-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-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
* 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-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 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-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 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 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 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-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-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
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.