From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard Wordingham" Newsgroups: gmane.emacs.devel Subject: Re: [w32] display international HELLO Date: Thu, 15 Nov 2007 02:48:26 -0000 Message-ID: <00d801c82732$0001dfb0$d5101252@JRWXP1> References: <001501c822ab$ccfec5e0$d5101252@JRWXP1> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1195094926 29524 80.91.229.12 (15 Nov 2007 02:48:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2007 02:48:46 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 15 03:48:50 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 1IsUmg-0003dH-19 for ged-emacs-devel@m.gmane.org; Thu, 15 Nov 2007 03:48:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IsUmT-00053L-7l for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2007 21:48:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IsUmP-0004zk-Ds for emacs-devel@gnu.org; Wed, 14 Nov 2007 21:48:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IsUmN-0004vA-IK for emacs-devel@gnu.org; Wed, 14 Nov 2007 21:48:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IsUmN-0004uy-Bn for emacs-devel@gnu.org; Wed, 14 Nov 2007 21:48:31 -0500 Original-Received: from mtaout01-winn.ispmail.ntl.com ([81.103.221.47]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IsUmM-0008NT-Qs for emacs-devel@gnu.org; Wed, 14 Nov 2007 21:48:31 -0500 Original-Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20071115024829.FRAT1988.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Thu, 15 Nov 2007 02:48:29 +0000 Original-Received: from JRWXP1 ([82.18.16.213]) by aamtaout02-winn.ispmail.ntl.com with SMTP id <20071115024829.WAFL17393.aamtaout02-winn.ispmail.ntl.com@JRWXP1> for ; Thu, 15 Nov 2007 02:48:29 +0000 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta) 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:83228 Archived-At: Kenichi Handa wrote: > Richard Wordingham wrote: Thanks for the explanations. >> 3. Compositions of Lao characters, (i.e. with the 'composition' string >> property) using the Code2000 font (the only fully working Lao font I >> have), >> do not display properly, whether they are in the Lao or >> mule-unicode-0100-24ff charset. > I think it's a waste of time to learn composition mechanism > of Emacs 22. It will be a lot improved in emacs-unicode-2. Are you talking of future work or the present state of emacs-unicode-2, as in Emacs 23.0.60.0? Are you talking of applying the composition property, or of the rendering of composed sequences? With the help of Jason Rumney I got 23.0.60.0 to build and run on Windows XP, but the Lao compositions are still displaying unreadably bizarrely. Unfortunately the more thorough application of composition in emacs-unicode-2 currently makes matters worse! Before, one could easily if tediously avoid the composition mechanism. For example, to make a Lao closed syllable consonant-vowel sequence , in Emacs 22.1 one can type d, space, delete, a. The best I can find in Emacs 23.0.60.0 is d, space, a, left, delete. However, as soon as one moves the cursor the characters compose and are then misdisplayed. The display problems also apply to Thai. It seems, however, that with Emacs 22.1 and a system default codepage ('ANSI' in Microsoft jargon) of Thai (CP-874), using a Thai keyboard avoids composition until the Emacs Thai input method (I've only investigated Kesmanee - I don't use Pattachote) is selected. Thus, Emacs 22.1 works fairly well for Thai on a 'Thai PC'. Emacs 23.0.60.0 seems not to be aware of the system default codepage - just switching the keyboard to Thai Kesmanee in Windows and issuing no commands in Emacs resulted in Latin-1 characters appearing as I typed. These display problems seem to me to be a straightforward bug, at least as far as operation on MS Windows is concerned. However, I am still no nearer to locating it. Richard.