From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: no-spam@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Several suggestions for image support Date: 29 Apr 2004 02:17:47 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083191286 11314 80.91.224.253 (28 Apr 2004 22:28:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Apr 2004 22:28:06 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 29 00:27:57 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 1BIxX2-0000XL-00 for ; Thu, 29 Apr 2004 00:27:56 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BIxX1-00061S-00 for ; Thu, 29 Apr 2004 00:27:55 +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 1BIxVv-0002cV-7G for emacs-devel@quimby.gnus.org; Wed, 28 Apr 2004 18:26:47 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BIxTX-0001NA-Vh for emacs-devel@gnu.org; Wed, 28 Apr 2004 18:24:19 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BIxSm-0000pG-Tg for emacs-devel@gnu.org; Wed, 28 Apr 2004 18:24:04 -0400 Original-Received: from [195.41.46.235] (helo=pfepa.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BIxSE-0000Ki-Sa; Wed, 28 Apr 2004 18:22:59 -0400 Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepa.post.tele.dk (Postfix) with SMTP id BD7EB4801BF; Thu, 29 Apr 2004 00:18:01 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: Original-Lines: 54 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:22317 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22317 Richard Stallman writes: > Quite contrary, I always found it very odd (i.e. buggy) that emacs > forces all lines to be at least as high as the default frame line > height. That means that you cannot have any "fine print". > > Paragraphs of "fine print" should have smaller line spacing. However, > when text in a smaller font appears in the middle of a paragraph that > is mainly ordinary size, even if one whole line is in the smaller > font, that line's spacing should not be reduced. But 21.2 did that, so I have tried to be compatible. > > So the right way to handle this is not really based on the size > of the text in the line. > > Another idea is to make it depend on the height of the newlines. That is what it does already -- the height of the newline is derived from the face font of the newline, not the text in the line. But if the text in the line is taller than the ordinary line height, the text height "wins". > That > would mean putting the newlines into the ordinary font even though the > text around them is in a smaller font. That would work provided the > fill commands know how to keep the newlines in the ordinary font. > We could accomplish this by setting the line-height property to the pixel height of a specific face *) The effect of this would be that newlines would have the height of that face, rather than the current font. Code could then set the line-height from that face's height on a whole paragraph to make it immune to filling changing the spaces & newlines in the paragraph. Of course, this requires that code explicitly specifies the face to use for line spacing, but since any existing code will assume the 21.2 behaviour, this approach is backwards compatible. *) I don't see any way to actually obtain the pixel height of a face from lisp. What about adding a face-char-height function (corresponding to frame-char-height). Args would be FACE &optional FRAME. -- Kim F. Storm http://www.cua.dk