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: fail on osx between 2/4/2009 and 2/5/2009 Date: Tue, 17 Feb 2009 12:26:08 +0200 Message-ID: <5BF9D3EF-54F8-4386-BAF5-B7BCB510E4C1@gmail.com> 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 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1234866756 6412 80.91.229.12 (17 Feb 2009 10:32:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Feb 2009 10:32:36 +0000 (UTC) Cc: emacs-devel@gnu.org, Kenichi Handa To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 17 11:33:51 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 1LZNGw-0001K0-2u for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2009 11:33:50 +0100 Original-Received: from localhost ([127.0.0.1]:45527 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZNFb-00006x-Jc for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2009 05:32:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZN98-0005pB-ET for emacs-devel@gnu.org; Tue, 17 Feb 2009 05:25:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZN97-0005oe-2h for emacs-devel@gnu.org; Tue, 17 Feb 2009 05:25:45 -0500 Original-Received: from [199.232.76.173] (port=57973 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZN96-0005oZ-Nj for emacs-devel@gnu.org; Tue, 17 Feb 2009 05:25:44 -0500 Original-Received: from mail-fx0-f16.google.com ([209.85.220.16]:52873) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZN95-0006lz-Qb for emacs-devel@gnu.org; Tue, 17 Feb 2009 05:25:44 -0500 Original-Received: by fxm9 with SMTP id 9so562672fxm.18 for ; Tue, 17 Feb 2009 02:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=kCWHj+/rC06F9RQYORpBbHViq3JnhCa9YtEQTkEDgaA=; b=ZT9lYKdxMVSknDYp6mOVYtYfNpjj2N+01QYgQVHhvCcuPG0xBHsAnlskmdsyXSVEq7 45UWAj9XGcFOuqHOH3pb10ctcjv3wfDFY1AHZBbQm14fI02fVaQgXgo1gUv9wS05hbwC vGJMjz3R3TUYRADEB1ozeo2civlQxNPbTkFH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=ZFTzVCotpYeFHNm21rxe6tLT4bqdBs5CLWXc3xIQcGzMCyN64eGJ+29thqublDNbPe SyjvoKtAmvGJ47CDqck9vCNov7TZIMy9zxcfaAzFtssBNfagNwW2WG7tQcK2QMEpur2Z qrR25m3RXOoaKivZ/rJocejdPq6mf3Jp/8Zio= Original-Received: by 10.103.227.13 with SMTP id e13mr3534530mur.20.1234866340468; Tue, 17 Feb 2009 02:25:40 -0800 (PST) Original-Received: from ?10.20.48.125? (gw1.panoulu.net [212.50.147.101]) by mx.google.com with ESMTPS id e8sm822910muf.29.2009.02.17.02.25.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Feb 2009 02:25:39 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.753.1) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 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:109122 Archived-At: On Feb 16, 2009, at 2:33 AM, YAMAMOTO Mitsuharu wrote: >>>>>> 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. At the beginning of font.h, font-spec and font-entity are described as lists of properties, and then those properties are listed in font_property_index. There is one property, "FONT_EXTRA_INDEX", that serves as a kind of basket for various additional properties, that don't merit being "first class" (listed explicitly) for whatever reason. The doc says, "extra information of a font such as name, OpenType features, and language coverage". At the time I was writing the NS backend (fall 2006) -- with only Handa-san's X impl and emacs's previous font-handling architecture to go by -- it wasn't clear to me that although some of these properties ("OpenType features" and "name") were not important for all back- ends, there were other "extra" properties, such as ":script" and friends, that were. >> 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. The only other impl was the X one, and it was difficult to separate out from the code what was X-specific, and what was generally applicable for all backends. At the time I understood that emacs handled multiple scripts through explictly-defined fontsets. script- representative-chars was there, but didn't seem to be used for anything, and most of the X code seemed centered around low-level font glyph encoding schemes like the "'japanese-jisx0208" and "chinese-gb2312" that you use in your example, rather than scripts. NS does not expose font glyph encoding schemes to the developer. There were also the has_char() and encode_char() methods in the font backend driver API. These led me to think that the determination of whether a font was suitable for rendering a given script would be done automatically by the font backend common code (through calling these methods on representative characters). So I might not have been as persistent in tracking down things relating to ":script" as I might have been. > 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 agree that platform-independent is better. However I did not have enough knowledge at the time of what Handa-san's full plans were, of how X fonts worked in Xft/Freetype, nor whether what I did under NS was possible under X. Nonetheless adding it was valuable because (a) it allowed users on one platform to benefit from automatically- generated fontsets, and (b) it COULD have inspired people who ARE familiar with other platforms to try implementing something like it themselves. Allowing for some innovation around the edges on different platforms can help drive the entire application forward on all systems. Disallowing it, you have a situation where no one tries any new features, because they cannot themselves do them for all platforms. For example, the font backend system itself was started only on X. That brought some new functionality, but it also "caught X up" to functionality that had already been innovated on other platforms, such as antialiasing. Anyway, I appreciate your recent criticism which has been helpful in improving the port, but it would be even nicer if you would help out with the code. ;-) Together we could make it better and hopefully satisfying all of your standards as well as mine and most importantly the needs of users. You have expressed reservations because you feel the port tries to do things in a different way from the rest of emacs, but that is not really accurate. It would be counterproductive. As I've said before, the port aims for clean, clear code taking into account both other ports' approaches and the fact that Cocoa is an OO API. It's not always going to fit as well as Carbon or X, but it has been improving. Certainly my efforts over the past months have been to shift things rather towards using common approaches than away. It doesn't happen overnight with a codebase of that size, but it gets better, and your help would speed that process. Adrian