From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.devel Subject: Re: font selection mechanism (e.g., Japanese) Date: Tue, 2 Feb 2010 09:36:54 -0500 Message-ID: <8DE939F2-1B72-44E9-9AF1-615E47BBB23B@gmail.com> References: <9775B394-9A01-4730-A4AE-98949DCA54DF@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-43--948593962" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1265121462 1146 80.91.229.12 (2 Feb 2010 14:37:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Feb 2010 14:37:42 +0000 (UTC) Cc: adrian.b.robert@gmail.com, emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 02 15:37:39 2010 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.69) (envelope-from ) id 1NcJsP-0006p3-Vg for ged-emacs-devel@m.gmane.org; Tue, 02 Feb 2010 15:37:14 +0100 Original-Received: from localhost ([127.0.0.1]:49071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NcJsP-0002AR-A4 for ged-emacs-devel@m.gmane.org; Tue, 02 Feb 2010 09:37:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NcJsK-0002AB-Js for emacs-devel@gnu.org; Tue, 02 Feb 2010 09:37:08 -0500 Original-Received: from [199.232.76.173] (port=40217 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NcJsJ-0002A3-97 for emacs-devel@gnu.org; Tue, 02 Feb 2010 09:37:07 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NcJsI-0001Fh-8a for emacs-devel@gnu.org; Tue, 02 Feb 2010 09:37:07 -0500 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:65404) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NcJsH-0001FR-Ta for emacs-devel@gnu.org; Tue, 02 Feb 2010 09:37:06 -0500 Original-Received: by vws8 with SMTP id 8so49130vws.0 for ; Tue, 02 Feb 2010 06:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-pgp-agent:x-mailer; bh=xQcuqXnhT2stp9wMv0gR1xAXpba//8VYcp/nnmYKtXc=; b=hXZCfkP26ZempyxGvKVWbonEq+YEAyyJZtQk//N2taJKUaMPPVcBQarSgj7qnBAofZ tnVsk3KZoh3zGKMT9gXrPr8p71vltTQhbCZW0olOGVQx68iJ9YOC4RNHEI3rQhBc9AH3 PqpDBH9hrPn1DVnWxvTFJatrnRwvahOY+UM/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-pgp-agent :x-mailer; b=nRiOB22lyqH2ndUHIdd6PPQIC9272/m8M1Vgjq/YJWAdA/zckuEXcI8U25hqCSZPz3 SsgYqxjNs9CBo4SQMleAiNh+TqXA8qa6jUa8+KYAjxMP/O10X5HSFnlgC0Mi0lCycdvh bXHU+GB79q6nFQ3iO2e5qiCsouvevMeoIOj1c= Original-Received: by 10.220.89.66 with SMTP id d2mr7942291vcm.74.1265121424519; Tue, 02 Feb 2010 06:37:04 -0800 (PST) Original-Received: from ?192.168.1.42? (pool-96-236-181-152.pitbpa.east.verizon.net [96.236.181.152]) by mx.google.com with ESMTPS id 32sm60486804vws.19.2010.02.02.06.37.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 02 Feb 2010 06:37:01 -0800 (PST) In-Reply-To: X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) 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:120821 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-43--948593962 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 2, 2010, at 6:51 AM, Kenichi Handa wrote: > Hmmm, then NS's font-backend should be improved. Could > someone working on NS port please port take a look at this > problem. FWIW, I have experimented with other variants of ns_findfonts() (for = "match", not for "list"), but ultimately found that it's mostly "list" = that is called while the code in font.c iteratively reduces that = constraints. I also found one font that is returned with the first batch ("Osaka"), = which has sufficient (.95) coverage for the 'han' script. However, it = is still not chosen, and I assume that this is because there is not = sufficient information present about the font weight. That's the NS = font driver's fault. I have filed a bug report about this; of course = I've tried to provide the weight information (with odd results - not = sure why). Similarly, we don't get the "ADSTYLE" information about = fonts either, so that the alternative font can't be chosen according to = that either. Someone with better knowledge of nsfont.m might be able = to debug this. >> The problem I have now is to get it to choose different fonts within =20= >> the same script in cases where a low-coverage font does not provide a = =20 >> glyph. The above threshold change makes things work better in =20 >> practice, but the HELLO file shows serious regressions. >=20 > Regression in which part? Only for Han scripts, or for all scripts? For more than han. What I have since noticed is that we're unable or = unwilling to select font foo for a given script, but, when foo doesn't = have glyphs for all needed characters, switch to another font bar for = the same script for those characters. Is that correct? >> Where in the code would one get it to choose a different font for a =20= >> character if the current font can't display it? This is by-character = =20 >> selection, not by-script. >=20 > The function fontset_find_font in fontset.c does that job. OK, I'll look into that. I assume it does that automatically, i.e. = without explicit specifications in a fontset? (All I'm talking about here is automatic selection. It's clear that a = fontset can be constructed manually.) > By the way, I locally have a code that respect the order of > fonts returned by font_driver->list () in font sorting. I'm > going to commit it for post 23.2 branch. Then, each driver > can return fonts in their preferred order. But then the driver also needs an argument such as a full font spec for = the target font, so that the order can be determined by similarity. = Right now, the only information it has is a set of hard constraints. =20 - D= --Apple-Mail-43--948593962 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) iEYEARECAAYFAktoOIoACgkQYotoJUVQB4JzEgCfZtcJQ6m8pmUW0UWftd4GlikH 3mUAoK0w79Rv0kfTk2eSHHdQ0OA0JWkN =dLK5 -----END PGP SIGNATURE----- --Apple-Mail-43--948593962--