From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: missing docs for _MULE_BASELINE_OFFSET_ Date: Mon, 6 Sep 2004 16:28:37 +0900 (JST) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200409060728.QAA20779@etlken.m17n.org> References: <20040906.085422.172911340.wl@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1094455749 25779 80.91.224.253 (6 Sep 2004 07:29:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Sep 2004 07:29:09 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 06 09:28:58 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C4Dvu-0002cw-00 for ; Mon, 06 Sep 2004 09:28:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C4E14-0006v1-75 for ged-emacs-devel@m.gmane.org; Mon, 06 Sep 2004 03:34:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C4E0y-0006us-3y for emacs-devel@gnu.org; Mon, 06 Sep 2004 03:34:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C4E0w-0006uZ-Ak for emacs-devel@gnu.org; Mon, 06 Sep 2004 03:34:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C4E0w-0006uW-8m for emacs-devel@gnu.org; Mon, 06 Sep 2004 03:34:10 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1C4Dvi-0000cw-Ga; Mon, 06 Sep 2004 03:28:47 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i867Sbqf016853; Mon, 6 Sep 2004 16:28:37 +0900 Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6p2/8.11.6) with ESMTP id i867SbU08941; Mon, 6 Sep 2004 16:28:37 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id QAA20779; Mon, 6 Sep 2004 16:28:37 +0900 (JST) Original-To: wl@gnu.org In-reply-to: <20040906.085422.172911340.wl@gnu.org> (message from Werner LEMBERG on Mon, 06 Sep 2004 08:54:22 +0200 (CEST)) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26818 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26818 In article <20040906.085422.172911340.wl@gnu.org>, Werner LEMBERG writes: > There is a single BDF property which might be of interest for the > user: _MULE_BASELINE_OFFSET_. Currently, it is completely > undocumented (except a rough description in ps-bdf.el); you have to > look into the emacs source code to find some explanation. > IMHO the very problem is that the user will never know that this > property exists at all. She will wonder why some glyphs jump out of > the base line, without finding a solution. > Besides documentation I suggest to make this value configurable for > each font. It is a non-trivial task to find the original BDF, add the > _MULE_BASELINE_OFFSET_ property, convert it to PCF and compress it, > replace the proper font in the X11 font directory, run `xset fp > rehash', and finally restart Emacs. > [My suggestion comes from the fact that in the SuSE GNU/Linux > distribution this property is missing for the Efont family -- I've > already submitted a bug report.] _MULE_BASELINE_OFFSET_ is a non-official property introduced in several fonts of foundry "etl" because ascent/descent of those fonts have intentionally wrong values so that they fit well with CJK fonts of the same size. So, _MULE_BASELINE_OFFSET_ should be necessary only for such a font. Do you mean Efont family also has incorrect ascent/descent values? --- Ken'ichi HANDA handa@m17n.org