From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: fail on osx between 2/4/2009 and 2/5/2009 Date: Mon, 16 Feb 2009 09:33:06 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <861vubqc79.fsf@blue.stonehenge.com> <10DD5733-4089-4A60-B090-4CB5E32A0E19@42tools.com> <49917BE9.6020903@gnu.org> <15A24001-137F-469F-8B05-DB31D4E8995D@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1234744405 18017 80.91.229.12 (16 Feb 2009 00:33:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2009 00:33:25 +0000 (UTC) Cc: emacs-devel@gnu.org, Kenichi Handa To: Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 16 01:34:40 2009 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 1LYrRX-0005oF-Tl for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2009 01:34:40 +0100 Original-Received: from localhost ([127.0.0.1]:51389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LYrQD-0007qv-TK for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2009 19:33:17 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LYrQ8-0007qg-Q9 for emacs-devel@gnu.org; Sun, 15 Feb 2009 19:33:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LYrQ7-0007qS-D6 for emacs-devel@gnu.org; Sun, 15 Feb 2009 19:33:12 -0500 Original-Received: from [199.232.76.173] (port=44382 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LYrQ7-0007qP-6u for emacs-devel@gnu.org; Sun, 15 Feb 2009 19:33:11 -0500 Original-Received: from ntp.math.s.chiba-u.ac.jp ([133.82.132.2]:65522 helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LYrQ6-0005nf-IT for emacs-devel@gnu.org; Sun, 15 Feb 2009 19:33:11 -0500 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 1268F2C44; Mon, 16 Feb 2009 09:33:06 +0900 (JST) In-Reply-To: <15A24001-137F-469F-8B05-DB31D4E8995D@gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by monty-python.gnu.org: NetBSD 3.0 (DF) 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:109095 Archived-At: >>>>> On Thu, 12 Feb 2009 20:42:42 +0200, Adrian Robert said: > When I first implemented the Cocoa font back-end, the list and match > APIs were mainly based around the font-entity structure, which > contained the following information: > foundry, family, adstyle, registry, weight, slant, width, size, dpi, > spacing, avgwidth Both the list and match are designed to take a font spec and returns either font entities or a font entity. So the knowledge of font specs as well as font entities were necessary to implement them properly in the first place. > Display of characters in multiple scripts was handled by the existing > emacs "fontset" structure. The "kludge" Yamamoto Mitsuharu refers to > was designed to allow this mechanism to work under NS without the > user or distributor needing to manually define a font set. It works > reasonably well, judging by the HELLO screen. Of course, users / > distributors always had the option to fall back to manual fontset > definitions to get better results as in other emacsen. Also, the existence of script-representative-chars you used in the kludge implies there were already some mechanisms such as the :script property in the font specs for selecting appropriate fonts without needing manual definition of fontsets. You could have noticed that if you read the implementations of other font backend drivers. In general, you should consider/propose platform-independent ways of solving problems/adding features rather than doing that by adding platform-specific kludges, unless they are inherently platform-specific matters. Such kludges might be acceptable for unofficial distributions, but not for the official Emacs distribution, I think. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp