From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Several suggestions for image support Date: 27 Apr 2004 15:22:16 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200404230033.JAA10583@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083074901 30149 80.91.224.253 (27 Apr 2004 14:08:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Apr 2004 14:08:21 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, Kenichi Handa , Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Apr 27 16:07:40 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BITFL-0007nw-00 for ; Tue, 27 Apr 2004 16:07:39 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BITFL-0007I4-00 for ; Tue, 27 Apr 2004 16:07:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BISrN-0001oQ-Vb for emacs-devel@quimby.gnus.org; Tue, 27 Apr 2004 09:42:53 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BISZW-0004d5-Gb for emacs-devel@gnu.org; Tue, 27 Apr 2004 09:24:26 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BISXZ-00045s-PI for emacs-devel@gnu.org; Tue, 27 Apr 2004 09:22:58 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BISXZ-00045a-8G for emacs-devel@gnu.org; Tue, 27 Apr 2004 09:22:25 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BISVS-0008O3-95; Tue, 27 Apr 2004 09:20:14 -0400 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 63 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22239 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22239 storm@cua.dk (Kim F. Storm) writes: > Miles Bader writes: > > > David Kastrup writes: > > > > nil -> use height of current face (the default) > > > > t -> use default face height (as minimum height) > > > > 0 -> use (don't increase) actual line height > > > > N (integer > 0) -> use N pixels (as minimum height) > > > > F (float > 0.0) -> use F * current face font height > > > > > > Is 0 a special case of N (use 0 pixels as minimum height)? > > > > Sounds like it. > > Not exactly -- the 0 value is a little special in the sense that it > _also_ tries to reposition the ascent/descent of the space glyph > so that when the cursor is on that glyph, as much as possible of the > cursor is visible. > > This is different from a value > 0, as that just gives a minimum > height -- and if the space glyph is taller than that, clipping occurs. > Maybe it should also try to reposition the cursor in this case; if so, > 0 would indeed be just a special case of N > 0 and F > 0.0 Ok, here is my take on it: the height of the newline glyph is more or less relevant when we visibly mark a region or change the background locally in any other manner or have the cursor box on it: then the skyline of the top is given by the glyph height, right? It would appear to me that for this purpose it would be most consistent if we used the same rules for spaces as for newline. The rule I would propose is the following: always use the height of the _current_ font at the point of the space or newline, unless that would exceed the actually available height (which normally will never fall behind the ascent of the default font, unless we use text properties on the newline character). 0 will be a special case, spaces will usually have the height of the font that they are corresponding to, and the presence of one overtall character or image will not cause all other spaces to look overtall. > Another issue is whether F should be relative the current face font > or the frame default font? I chose current font, as it enables you > to use default font when necessary, while the opposite isn't true. Well, we already established that having a paragraph of small print with line distance reduced to the natural size of the small print would be nice. Tacking an 1.0 value on the text will achieve that. But in that case, having some smaller print within the small print will again cause inconsistencies. And it is somewhat contraintuitive if a relative size of 1.0 causes a change. So I think that the default of the relative size should refer to the default face of the frame. If you want to allow a different base face for specifying relative sizes, you could allow specifications like (1.0 . small-face) That would allow to set a paragraph in small print by placing the respective line distance property on it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum