From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [w32] display international HELLO Date: Fri, 09 Nov 2007 12:55:17 +0200 Message-ID: References: <001501c822ab$ccfec5e0$d5101252@JRWXP1> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1194605783 20201 80.91.229.12 (9 Nov 2007 10:56:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Nov 2007 10:56:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Richard Wordingham" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 09 11:56:28 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IqRWV-0003vC-M7 for ged-emacs-devel@m.gmane.org; Fri, 09 Nov 2007 11:55:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IqRWK-0000fz-0n for ged-emacs-devel@m.gmane.org; Fri, 09 Nov 2007 05:55:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IqRWE-0000bO-1M for emacs-devel@gnu.org; Fri, 09 Nov 2007 05:55:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IqRWC-0000XH-0b for emacs-devel@gnu.org; Fri, 09 Nov 2007 05:55:21 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IqRWB-0000Wq-RO for emacs-devel@gnu.org; Fri, 09 Nov 2007 05:55:19 -0500 Original-Received: from romy.inter.net.il ([213.8.233.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IqRWB-0005rJ-CG for emacs-devel@gnu.org; Fri, 09 Nov 2007 05:55:19 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-84-228-202-76.inter.net.il [84.228.202.76]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id JIS10786 (AUTH halo1); Fri, 9 Nov 2007 12:55:04 +0200 (IST) In-reply-to: <001501c822ab$ccfec5e0$d5101252@JRWXP1> (richard.wordingham@ntlworld.com) X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) 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:82860 Archived-At: > From: "Richard Wordingham" > Date: Fri, 9 Nov 2007 08:37:42 -0000 > > > Is there any ways to display them? > > Or should I use other fonts? I guess some of the useful stuff you posted should find its way into PROBLEMS. So please keep on with posting any findings you will discover as result of this discussion. Thanks! > 2. My first discovery with Lao was that just selecting a font (Code2000) > that supported Lao was not enough. It would not normally display Lao > characters (in the Lao charset), until I discovered that a trick such as > > (set-fontset-font "fontset-myfont" 'lao '("Code2000" . "iso10646-1")) > > suddenly made the Lao text displayable. How does this work? I have studied > the code of xdisp.c and its supporting functions, but I cannot find where > Emacs character codes are converted to Unicode. I think you need to look in w32term.c as well. For example, the function w32_encode_char there seems to be a good place to start. > I did notice that if I pasted Lao in from an MS application, Emacs > would accept them as Unicode characters and they would be displayed > properly if I selected an appropriate font. Yes, Emacs on Windows uses Unicode for working with the clipboard whenever possible. > 4. When I explicitly specify that a buffer is to be saved in UTF-8 (or one > of its variants), the Lao input method suddenly switches from generating Lao > characters in the Lao charset to generating Lao characters in the > mule-unicode-0100-24ff charset. How is this effect achieved? That's because UTF-8 is supported only for mule-unicode-0100-24ff, so decoding UTF-8 will _always_ produce Unicode characters. > Characters already stored in the Lao charset remain in the Lao > charset in the buffer, as confirmed by C-x C-e (eval-last-sexp). Yes. This is because changing buffer's encoding does not change the buffer contents in any way, it just tells Emacs how to encode the buffer text when the time comes to write it to disk. At that time, if there are any characters in the buffer that cannot be encoded in the encoding you specified, Emacs will complain and show you those files, so that you could choose a different encoding. > Bizarrely, selecting UTF-16 as the encoding for saving the buffer does not > change the charset used by the Lao charset. Probably a bug of some sort. > 6. Latin ligaturing does not work. Yes, Emacs currently does not support this feature.