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: 24 Apr 2004 17:16:01 +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 1082819870 5765 80.91.224.253 (24 Apr 2004 15:17:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 24 Apr 2004 15:17:50 +0000 (UTC) Cc: storm@cua.dk, emacs-devel@gnu.org, handa@m17n.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Apr 24 17:17:44 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 1BHOuW-0006QL-00 for ; Sat, 24 Apr 2004 17:17:44 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BHOuW-0005yZ-00 for ; Sat, 24 Apr 2004 17:17:44 +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 1BHOuO-0006t3-HM for emacs-devel@quimby.gnus.org; Sat, 24 Apr 2004 11:17:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BHOtb-0006jM-RG for emacs-devel@gnu.org; Sat, 24 Apr 2004 11:16:47 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BHOt5-0006a7-EN for emacs-devel@gnu.org; Sat, 24 Apr 2004 11:16:46 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BHOt5-0006Zy-08 for emacs-devel@gnu.org; Sat, 24 Apr 2004 11:16:15 -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 1BHOrG-00023N-LT; Sat, 24 Apr 2004 11:14:23 -0400 Original-To: rms@gnu.org In-Reply-To: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-Lines: 53 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:22097 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22097 Richard Stallman writes: > So I think that > the space between two baselines should be > > max(line space of newline, max(all glyph depths of upper line,0) > +max(all glyph heights of lower line,0)) > where depth is the extent of a glyph below the baseline, and the > height is the extent above. > > You may be right, but it occurs to me that we should see if text > formatters have any guidance to offer us on how to decide this. TeX is pretty quirky in this regard. It has some design decisions resulting from efficiency and memory considerations, and some that are due to dealing best with pagination. Since an editor window is usually not intended to display paginated material but rather to provide a view on part of a long scroll, we don't need to bother with stuff like "flexible glue" that is used for fitting things better to a page. Basically, lines are governed by the three values \baselineskip, \lineskiplimit and \lineskip. TeX tries to arrange lines such that their baselines are \baselineskip apart. If the descenders of the upper line come closer than \lineskiplimit to the ascenders of the lower line, however, TeX instead separates those parts of the lines by using \lineskip between them. The plain TeX values are 12pt for \baselineskip, 0pt for \lineskiplimit, and 1pt for \lineskip. There is a discontinuity involved in those standard settings: the separation jumps from 0pt to 1pt once overlap can't be avoided anymore with the standard settings. In calculating ascent and descent of a line, TeX uses only the maximum of any actually involved characters and does not distinguish where on the line these occur. For an editor, this is certainly appropriate, as we use rectangular areas of differing background color for highlighting things. When typesetting running text, TeX uses the values of the line spacing variables that are current at the end of the paragraph. This causes a whole paragraph to be typeset with consistent (though sometimes surprising) baseline distances. This consistency is what I am mostly worried about: if we have a few words of small print in a paragraph, and auto-fill-mode happens to break between them, the newline will belong to a face with a smaller baseline distance. So I am not sure whether we should making changes of the baseline distance as easy as changing a face for a few words in running text. I don't have a much better idea, though. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum