From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: Problem with narrow vs condensed fonts Date: Thu, 28 Feb 2008 11:17:18 +0000 Message-ID: <47C6983E.50503@gnu.org> References: <47C3DFD7.4030406@gnu.org> <47C3FF62.1080003@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1204197466 31660 80.91.229.12 (28 Feb 2008 11:17:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Feb 2008 11:17:46 +0000 (UTC) Cc: schwab@suse.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 28 12:18:08 2008 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 1JUgm2-0007uL-QP for ged-emacs-devel@m.gmane.org; Thu, 28 Feb 2008 12:18:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUglW-00019A-6T for ged-emacs-devel@m.gmane.org; Thu, 28 Feb 2008 06:17:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JUglP-00017u-IJ for emacs-devel@gnu.org; Thu, 28 Feb 2008 06:17:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JUglO-00016v-EN for emacs-devel@gnu.org; Thu, 28 Feb 2008 06:17:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUglO-00016m-Aj for emacs-devel@gnu.org; Thu, 28 Feb 2008 06:17:22 -0500 Original-Received: from mk-outboundfilter-3.mail.uk.tiscali.com ([212.74.114.23]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JUglO-0003ac-5r for emacs-devel@gnu.org; Thu, 28 Feb 2008 06:17:22 -0500 Original-X-Trace: 50552064/mk-outboundfilter-1.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/83.67.23.108 X-SBRS: None X-RemoteIP: 83.67.23.108 X-IP-MAIL-FROM: jasonr@gnu.org X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALQmxkdTQxds/2dsb2JhbAAIkjSbXA X-IP-Direction: OUT Original-Received: from i-83-67-23-108.freedom2surf.net (HELO [127.0.0.1]) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Feb 2008 11:17:20 +0000 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: <47C3FF62.1080003@gnu.org> X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:90715 Archived-At: Jason Rumney wrote: > Kenichi Handa wrote: >> By the way, I think having different numeric values for >> Windows is not right. The function font-spec accepts also >> numeric values for style parameters (:weight, :slant, >> :width). So, it is better that the numeric values are >> consistent in all versions of Emacs. Is it difficult (or >> time consuming) to map windows numeric values to what >> specified in font-XXX-table in w32_enumfont_pattern_entity? >> > > It is probably quite difficult and error prone, as we would be mapping > a larger range (100-900 for weight on windows) onto a smaller range > (0-210), and the mapping appears to be non-linear. Although in > practice, most fonts probably use the fixed values currently defined > in font-weight-table, I don't think it is guaranteed. > > I don't think users will be surprised if numeric weights are defined > as backend specific. Perhaps we shouldn't even allow them for the x > backend, since they are not supported natively. I think it would be better if font-spec allowed either symbols or integers for weight, slant and swidth. Only certain symbols (medium/normal/regular, bold, italic, roman) are guaranteed to be supported, other symbols and integer values are implementation specific and should not be used internally by Emacs, or by Lisp packages, but are available to end users to fine tune their face customizations etc. The x backend would not recognize integer weights, and would convert symbols for inclusion in xflds by symbol-name. The xft, Windows and other backends would have their own tables for converting symbols to numeric values where numeric values are used internally by the implementation. I thought the intention of the new font backend was to abstract out the differences between font APIs, but by imposing fontconfig definitions of numeric weight, slant and swidth, we have only moved from a XFLD centric font implementation to a fontconfig centric one.