From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: image file with Chinese file names Date: Wed, 29 Mar 2006 10:21:56 +0900 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1143595337 8786 80.91.229.2 (29 Mar 2006 01:22:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Mar 2006 01:22:17 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 29 03:22:15 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FOPO1-0007h4-PJ for ged-emacs-devel@m.gmane.org; Wed, 29 Mar 2006 03:22:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FOPO1-0005cs-6K for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2006 20:22:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FOPNp-0005ba-8T for emacs-devel@gnu.org; Tue, 28 Mar 2006 20:22:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FOPNo-0005aD-CQ for emacs-devel@gnu.org; Tue, 28 Mar 2006 20:22:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FOPNo-0005Zy-8X for emacs-devel@gnu.org; Tue, 28 Mar 2006 20:22:00 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FOPPe-0006UT-4E for emacs-devel@gnu.org; Tue, 28 Mar 2006 20:23:54 -0500 Original-Received: from nfs.m17n.org (nfs.m17n.org [192.47.44.7]) by tsukuba.m17n.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k2T1LuiS001274; Wed, 29 Mar 2006 10:21:56 +0900 Original-Received: from etlken (etlken.m17n.org [192.47.44.125]) by nfs.m17n.org (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k2T1LuLU008817; Wed, 29 Mar 2006 10:21:56 +0900 Original-Received: from handa by etlken with local (Exim 3.36 #1 (Debian)) id 1FOPNk-0002pb-00; Wed, 29 Mar 2006 10:21:56 +0900 Original-To: MJ Chan In-reply-to: (message from MJ Chan on Sat, 18 Mar 2006 17:07:28 -0500) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:52175 Archived-At: In article , MJ Chan writes: > [ this was originally posted to help-emacs-windows@gnu.org. ] > I'm seeing something that I'm not sure is necessary. When I use > create-image with file with chinese name like this, image-size always > return (30 . 30) as its size: (30 is the default size when image > cannot be loaded according to emacs C source code).=20 > (image-size (create-image image-file-name) t) > if I do this: > (image-size (create-image (encode-coding-string image-file-name 'big5)) t) > It returns correct size.=20 > I'm wondering if encode-coding-string is necessary here. My > file-name-coding-system is already set to big5. > Please note that in both cases, the image file itself can be displayed > properly. It's just the image-size seems to have problem. I found that image.c (and image.el) doesn't pay attention to filename encoding. For instance, when I visit a file "=C0.png", Emacs crashes in png_load() as this: Program received signal SIGSEGV, Segmentation fault. 0x40346777 in fclose () from /lib/libc.so.6 (gdb) bt 10 #0 0x40346777 in fclose () from /lib/libc.so.6 #1 0x080e6e91 in png_load (f=3D0x862c2f8, img=3D0x8598ab0) at image.c:6136 #2 0x080e2fb3 in lookup_image (f=3D0x862c2f8, spec=3D139477389) at image.c= :1830 #3 0x080659c1 in handle_single_display_spec (it=3D0xbfffe1c0, spec=3D1, ob= ject=3D140136732, position=3D0xbfffe260, display_replaced_before_p=3D0) at = xdisp.c:4187 This bug is because of this code: /* Open the image file. */ fp =3D fopen (SDATA (file), "rb"); if (!fp) { image_error ("Cannot open image file `%s'", file, Qnil); UNGCPRO; fclose (fp); return 0; } i.e. calling fclose() with NULL. But the reason why this part of code runs is that x_find_image_file() returns not-yet-encoded file name, thus the above fopen fails. As an image file name is passed from function to function, I don't understand where we should put the interface between decoded filename and encoded filename. Could someone who knows the structure of image.c please work on it? Usually, you can use the macro ENCODE_FILE to encode a filename. But, please note that it may call a Lisp function, thus may cause GC. --- Kenichi Handa handa@m17n.org