From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Adrian Robert Newsgroups: gmane.emacs.devel Subject: Re: How to convert char from Emacs-20 internal to UTF-8? Date: Wed, 16 Mar 2005 19:20:26 -0800 (PST) Message-ID: <200503170320.j2H3KQHr027977@zakros.ucsd.edu> References: <64cb038a0c479b993368280a127af987@cogsci.ucsd.edu> <87acp3jyqi.fsf-monnier+emacs@gnu.org> <1edb21fc2b6a61e8bd8d7b4d77aec1ec@cogsci.ucsd.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1111029638 13492 80.91.229.2 (17 Mar 2005 03:20:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 17 Mar 2005 03:20:38 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 17 04:20:37 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DBlYj-0007OE-Dh for ged-emacs-devel@m.gmane.org; Thu, 17 Mar 2005 04:20:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DBlow-0002gY-AS for ged-emacs-devel@m.gmane.org; Wed, 16 Mar 2005 22:37:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DBlol-0002ft-Ra for emacs-devel@gnu.org; Wed, 16 Mar 2005 22:37:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DBloj-0002eY-DN for emacs-devel@gnu.org; Wed, 16 Mar 2005 22:37:01 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DBloj-0002eH-7F for emacs-devel@gnu.org; Wed, 16 Mar 2005 22:37:01 -0500 Original-Received: from [132.239.6.132] (helo=zakros.ucsd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DBlZh-0006iT-OC for emacs-devel@gnu.org; Wed, 16 Mar 2005 22:21:30 -0500 Original-Received: from zakros.ucsd.edu (IDENT:arobert@localhost [127.0.0.1]) by zakros.ucsd.edu (8.13.1/8.13.1) with ESMTP id j2H3KRPe027978; Wed, 16 Mar 2005 19:20:27 -0800 (PST) Original-Received: (from arobert@localhost) by zakros.ucsd.edu (8.13.1/8.13.1/Submit) id j2H3KQHr027977; Wed, 16 Mar 2005 19:20:26 -0800 (PST) Original-To: Adrian Robert , Stefan Monnier 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: news.gmane.org gmane.emacs.devel:34653 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34653 > The trunk of the CVS repository (which will becomes Emacs-22) > already supports OS X (via Carbon). > > If that doesn't help you because you want to use some other > API, I recommend you start from the emacs-unicode-2 branch in > the CVS repository (which may become Emacs-23). That branch > changes the internal character set of Emacs to Unicode, so you > won't need to convert chars at all. > > But work on Emacs-20 so obviously counter productive to me that > I suspect I just don't understand your motivations enough to > give you a good response, I'm sorry, perhaps I should have explained a bit more at first.. desire to avoid a long-winded email has led to 3 medium-winded ones. ;) http://emacs-on-aqua.sf.net is a project to resurrect the old NeXTstep port of Emacs, that has actually been maintained to some extent over the years, until the point where it was based on Emacs 20.7 and partially working on OS X. (The Cocoa APIs are based on OpenStep, the successor of NeXTstep). We are interested in getting this running well on both OS X and GNUstep, an open-source implementation of OpenStep, and in bringing it up to be based on the latest Emacs. Rather than trying to do both of these at once, we decided to bring the port up to date first on Emacs 20.7, since the code has gotten a little rusty over the years. This has been going well, but one of the remaining tasks is 2-byte font rendering, which led to my query. We think we can handle it as long as we deliver UTF-8 (or possibly plain unicode) to our renderer. But we need to try to be sure, and then will come the task of getting fontsets working.. So, in our code we have a function ns_dumpglyphs() which plays the role of dumplglyphs() in xterm.c: an array of GLYPHS is received, the character info is extracted using GLYPH_FAST_CHAR(), along with other face-related info, and the text is rendered. In our case, we need to convert the result of GLYPH_FAST_CHAR() into UTF-8 or unicode.