From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: (re)display problems after font backend merge Date: Sun, 18 May 2008 04:30:54 +0100 Message-ID: <482FA2EE.7010900@harpegolden.net> References: <87fxsjmmo2.fsf@escher.local.home> <87fxsiczun.fsf@escher.local.home> <482E4EB0.3070003@harpegolden.net> <87wslti040.fsf@escher.local.home> <482EE57C.8050009@harpegolden.net> <87ve1cn5dz.fsf@escher.local.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1211081480 9932 80.91.229.12 (18 May 2008 03:31:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 May 2008 03:31:20 +0000 (UTC) Cc: handa@m17n.org, emacs-devel@gnu.org To: Stephen Berman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 18 05:31:56 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 1JxZco-000545-Ea for ged-emacs-devel@m.gmane.org; Sun, 18 May 2008 05:31:54 +0200 Original-Received: from localhost ([127.0.0.1]:43451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JxZc4-0001Ja-GJ for ged-emacs-devel@m.gmane.org; Sat, 17 May 2008 23:31:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JxZc0-0001JL-BY for emacs-devel@gnu.org; Sat, 17 May 2008 23:31:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JxZbx-0001J9-Ma for emacs-devel@gnu.org; Sat, 17 May 2008 23:31:03 -0400 Original-Received: from [199.232.76.173] (port=58329 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JxZbx-0001J6-I0 for emacs-devel@gnu.org; Sat, 17 May 2008 23:31:01 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:55593) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JxZbx-0003YD-9M for emacs-devel@gnu.org; Sat, 17 May 2008 23:31:01 -0400 Original-Received: from golden1.harpegolden.net (unknown [86.45.2.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id 5BF2583B8; Sun, 18 May 2008 03:30:58 +0000 (UTC) User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) In-Reply-To: <87ve1cn5dz.fsf@escher.local.home> X-Enigmail-Version: 0.95.0 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:97345 Archived-At: Stephen Berman wrote: > the underlining is still broken and > too close to the bottom of the characters. Re the vertical position: Have you played with customize-variables x-use-underline-position-properties and x-underline-at-descent-line ? They may make a difference. AFAIK truetype fonts as used in xft/freetype typically provide a real underline positioning metric, so maybe there's a bug lurking there (or just a todo)... and of course maybe there are fonts that just actively say to put the underline in a bad position. x-underline-at-descent-line seems to cause underline to outright disappear on my current emacs build though - presumably not right. Other underline rendering issues: Not-bad-as-such-but-close underline positions needing a bodge offset to account for the pixel grid for display clarity for small onscreen sizes. That one might be immediately relevant - e.g. if you examine rendering of some fonts at, say, 30pt, you can see the font-specified underline is not simply at the baseline, but if you're using the font at more usual 8-10pt sizes on usual screen-type displays (with vertical res of < 100 dpi), it might as well be. Appropriate underline position for multi-font spans/lines (taking the max offset across the line is probably adequately aesthetic in many cases). Breaking the underline for clarity when descenders intersect it - somewhat computationally costly (though that matters less these days) even with the old rendering cheat of drawing the underline first, then drawing a directionally filled variant (to avoid "bits" in the loopy descenders of e.g. g,j...) of letters in background colour, h-stretched or offset left+right a bit, and then overlaying the letters in real size+position in the foreground colour. (note that the higher resolution of printed material means the issue is a bit less severe in print than on-screen, though high-quality print typesetting will also break underline for descenders). ... High-quality font rendering => hard work! Re broken underlining: Not too sure about this - there are certainly issues with underlining being used for different purposes in emacs, where underlining being visible for various amounts of inter-word and trailing whitespace may or may not be appropriate*. Though it looks like you may have odd underlining beyond whitespace vs. non-whitespace. (* textual emphasis vs. poor-man's separator bars, for example, as in bug #26) > This image shows split windows, with the Gnus Summary buffer on top and > the Article buffer below. The mode line of the Summary buffer has my > customized mode-line face (Helvetica font as in variable-pitch face, > plus over- and underlining). The mode line of the Article buffer has > mode-line-inactive face, which inherits from mode-line but overrides the > weight attribute, making it light. One of the modelines sure doesn't *look* like helvetica ?