From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: (re)display problems after font backend merge Date: Sun, 18 May 2008 20:19:52 +0200 Message-ID: <873aofscdz.fsf@escher.local.home> 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> <482FA2EE.7010900@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1211134904 9695 80.91.229.12 (18 May 2008 18:21:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 May 2008 18:21:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 18 20:22:22 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 1JxnWV-0005zq-38 for ged-emacs-devel@m.gmane.org; Sun, 18 May 2008 20:22:19 +0200 Original-Received: from localhost ([127.0.0.1]:35380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JxnVk-0007b7-Sk for ged-emacs-devel@m.gmane.org; Sun, 18 May 2008 14:21:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JxnUT-0007Es-PK for emacs-devel@gnu.org; Sun, 18 May 2008 14:20:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JxnUS-0007EP-PN for emacs-devel@gnu.org; Sun, 18 May 2008 14:20:13 -0400 Original-Received: from [199.232.76.173] (port=39533 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JxnUS-0007EG-Jl for emacs-devel@gnu.org; Sun, 18 May 2008 14:20:12 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:46212 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JxnUS-0000Pq-69 for emacs-devel@gnu.org; Sun, 18 May 2008 14:20:12 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JxnUM-0006K0-RW for emacs-devel@gnu.org; Sun, 18 May 2008 18:20:06 +0000 Original-Received: from i5387e5cd.versanet.de ([83.135.229.205]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 May 2008 18:20:06 +0000 Original-Received: from Stephen.Berman by i5387e5cd.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 May 2008 18:20:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 99 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: i5387e5cd.versanet.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) 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:97365 Archived-At: On Sun, 18 May 2008 04:30:54 +0100 David De La Harpe Golden wrote: > 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. Indeed, setting x-use-underline-position-properties to nil gives me the space with underlining I want. Thanks for the suggestion. > 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. I hadn't used xft before you suggested it, so I don't know, but it would surprise me if Dejavu Sans Mono, the font I am using with Emacs, is at fault here, since it is widely used. > x-underline-at-descent-line seems to cause underline to outright > disappear on my current emacs build though - presumably not right. I see this too (i.e., I don't see any underlining with x-underline-at-descent-line set to t). > 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. Indeed, with 30pt Dejavu Sans Mono I do see a space between the underline and the characters (with x-use-underline-position-properties at its default value of t). [...] > 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. All I know is that the broken underlining only appears post font-backend merge, and regardless of whether I use xft or not. > (* 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 ? In fact, it is to all appearances the same font as is used in the splash screen, and there I can use C-u C-x =, which shows this (on the first character after the image in the splash screen): character: T (84, #o124, #x54) preferred charset: ascii (ASCII (ISO646 IRV)) code point: 0x54 syntax: w which means: word category: a:ASCII graphic characters 32-126 (ISO646 IRV:1983[4/0]) l:Latin r:Japanese roman buffer code: #x54 file code: not encodable by coding system utf-8-unix display: by this font (glyph code) -monotype-Andy MT-normal-normal-normal-*-12-*-*-*-*-0-iso8859-1 (#x37) Character code properties are not shown: customize what to show There are text properties here: auto-composed t face (variable-pitch (:foreground "red")) help-echo [Show] The face variable-pitch has only the font attribute set, to "helv". I don't know why "monotype-Andy MT" shows up. I mentioned in my previous post that changing certain attributes of variable-pitch face changes its appearance drastically. In fact, it changes the font family. For example, changing the width attribute to "narrow" results, according to C-u C-x =, in a font family of "monotype-Impact". Steve Berman