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: macos.texi updated Date: Tue, 11 Oct 2005 13:10:55 -0400 Message-ID: <7131209A-E2AA-4FBE-8EB7-0AA4A77448CD@cogsci.ucsd.edu> References: <8C0A68AE-EF12-4D6C-9879-D0FF3B04DE1B@mac.com> <87r7bhw2o8.fsf-monnier+emacs@gnu.org> <991DC775-381E-4B96-BBC6-B3701CCD6EAD@cogsci.ucsd.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1129050815 4446 80.91.229.2 (11 Oct 2005 17:13:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2005 17:13:35 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 11 19:13:26 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EPNel-0000Kv-Ie for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2005 19:11:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EPNek-00086B-KJ for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2005 13:11:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EPNeY-00084v-Gv for emacs-devel@gnu.org; Tue, 11 Oct 2005 13:11:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EPNeW-00083B-Tz for emacs-devel@gnu.org; Tue, 11 Oct 2005 13:11:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EPNeW-000835-R3 for emacs-devel@gnu.org; Tue, 11 Oct 2005 13:11:00 -0400 Original-Received: from [140.251.1.25] (helo=smtp-in1.med.cornell.edu) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EPNeV-0004JY-QU for emacs-devel@gnu.org; Tue, 11 Oct 2005 13:11:00 -0400 Original-Received: from mpx1.med.cornell.edu (biglb-vlan511vip.med.cornell.edu [140.251.11.120]) by smtp-in1.med.cornell.edu (Switch-3.1.6/Switch-3.1.6) with ESMTP id j9BHAu6u270802 for ; Tue, 11 Oct 2005 13:10:57 -0400 Original-Received: from [140.251.33.115] by mpx1.med.cornell.edu (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTP id <0IO7005X6H28HHA0@mpx1.med.cornell.edu> for emacs-devel@gnu.org; Tue, 11 Oct 2005 13:10:56 -0400 (EDT) In-reply-to: Original-To: YAMAMOTO Mitsuharu X-Mailer: Apple Mail (2.734) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.10.11.17 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:43881 Archived-At: On Oct 11, 2005, at 4:01 AM, YAMAMOTO Mitsuharu wrote: >>>>>> On Fri, 07 Oct 2005 10:53:22 -0400, Adrian Robert >>>>>> said: >>>>>> > > >> In addition, I've been integrating the Cocoa port's font handling >> with xfaces.c, and can say it's onerous for developers. All of >> these structures and functions concerned with creating, parsing, and >> storing the XLFD representation. And you can't avoid using it in a >> port (at least, all of my attempts to work around it so far have >> failed), so each platform gets to join in the fun. Thus you find the >> various functions for faking (and unfaking) them under the two (now >> three) non-X platforms. >> > > What we need to provide with respect to XLFD in the platform-dependent > part is x_list_fonts and x_load_font, whose main components are > emulations of XListFonts and XLoadQueryFont. Not so many, I think. > Just out of curiosity, what part of them do you think is onerous? Is > it missing or oversimplified in the Carbon port? This is subjective.. it works out to about 2-3% of the ports on the unicode 2 branch, but that is a lot: In Carbon (macterm.c), my brief survey found "only" 500 lines concerned more or less directly with XLFD compatibility. In W32 (w32fns.c), I found around 1000 lines. Obviously the approach makes a difference here, and I'm hoping the Cocoa port can be less, as it has around 600 lines for all of font management right now ex-XLFD, and doubling that would be depressing. ;-) Bottom line, 500 lines seems a lot when this is over and above both the code doing the main business of x_list_fonts and the code filling in all of the XFontStruct and font_info when loading fonts. Also, xfaces.c itself suffers; if the XLFD stuff were separated out to "xfaces.c" (and "wfaces.c" was made for the windowing-general part), I strongly suspect the code would be easier to understand and maintain.