* (re)display problems after font backend merge @ 2008-05-15 18:45 Stephen Berman 2008-05-16 0:57 ` Kenichi Handa 0 siblings, 1 reply; 21+ messages in thread From: Stephen Berman @ 2008-05-15 18:45 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 341 bytes --] Since Kenichi Handa's font backend merge yesterday I see different, and at least partly buggy, display and redisplay effects. This shows up clearly in some of my customizations, in particular of the mode line and the Gnus Summary buffer. The following screen shots show the differences; the top image is post-merge, the bottom pre-merge: [-- Attachment #2: Post-merge display --] [-- Type: image/png, Size: 18836 bytes --] [-- Attachment #3: Pre-merge display --] [-- Type: image/png, Size: 18672 bytes --] [-- Attachment #4: Type: text/plain, Size: 942 bytes --] Here is a description of the differences I see: - In the post-merge image, the underlining I use in the mode line is broken, as is the underlining of the current article in the Gnus Summary buffer, and the latter underlining touches the bottom of the characters in the post-merge image, while there is a (IMO more pleasing) space in the pre-merge display. - The fringe arrow in the Summary buffer is redisplayed in the mode line. - The character size in the mode line is larger in the post-merge image than in the pre-merge image (in both it is font family Helvetica). - The appearance of the non-ascii characters I use for threading and separation in the Summary buffer differs; in particular, the separator forms a broken vertical line in the post-merge buffer, while it is a continuous vertical line in the pre-merge buffer (except for the line containing the Indic characters, which is also misaligned in both images). Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-15 18:45 (re)display problems after font backend merge Stephen Berman @ 2008-05-16 0:57 ` Kenichi Handa 2008-05-16 10:22 ` Stephen Berman 0 siblings, 1 reply; 21+ messages in thread From: Kenichi Handa @ 2008-05-16 0:57 UTC (permalink / raw To: Stephen Berman; +Cc: emacs-devel In article <87fxsjmmo2.fsf@escher.local.home>, Stephen Berman <Stephen.Berman@gmx.net> writes: > Since Kenichi Handa's font backend merge yesterday I see different, and > at least partly buggy, display and redisplay effects. This shows up > clearly in some of my customizations, in particular of the mode line and > the Gnus Summary buffer. The following screen shots show the > differences; the top image is post-merge, the bottom pre-merge: > [2 Post-merge display <image/png (base64)>] > [3 Pre-merge display <image/png (base64)>] > [4 <text/plain (7bit)>] > Here is a description of the differences I see: > - In the post-merge image, the underlining I use in the mode line is > broken, as is the underlining of the current article in the Gnus Summary > buffer, and the latter underlining touches the bottom of the characters > in the post-merge image, while there is a (IMO more pleasing) space in > the pre-merge display. Please show me how you customize Gnus, and exactly which font is used in the Gnus summary buffer by C-u C-x =. > - The fringe arrow in the Summary buffer is redisplayed in the mode > line. This is very strange. The font-backend merge should not touch fringe displaying. > - The character size in the mode line is larger in the post-merge image > than in the pre-merge image (in both it is font family Helvetica). > - The appearance of the non-ascii characters I use for threading and > separation in the Summary buffer differs; in particular, the separator > forms a broken vertical line in the post-merge buffer, while it is a > continuous vertical line in the pre-merge buffer (except for the line > containing the Indic characters, which is also misaligned in both > images). Please do C-u C-x = on that vertical line to see which font is used in both version. --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-16 0:57 ` Kenichi Handa @ 2008-05-16 10:22 ` Stephen Berman 2008-05-17 3:19 ` David De La Harpe Golden 0 siblings, 1 reply; 21+ messages in thread From: Stephen Berman @ 2008-05-16 10:22 UTC (permalink / raw To: emacs-devel On Fri, 16 May 2008 09:57:42 +0900 Kenichi Handa <handa@m17n.org> wrote: > In article <87fxsjmmo2.fsf@escher.local.home>, Stephen Berman <Stephen.Berman@gmx.net> writes: > >> Since Kenichi Handa's font backend merge yesterday I see different, and >> at least partly buggy, display and redisplay effects. This shows up >> clearly in some of my customizations, in particular of the mode line and >> the Gnus Summary buffer. The following screen shots show the >> differences; the top image is post-merge, the bottom pre-merge: > >> [2 Post-merge display <image/png (base64)>] > >> [3 Pre-merge display <image/png (base64)>] > >> [4 <text/plain (7bit)>] > >> Here is a description of the differences I see: > >> - In the post-merge image, the underlining I use in the mode line is >> broken, as is the underlining of the current article in the Gnus Summary >> buffer, and the latter underlining touches the bottom of the characters >> in the post-merge image, while there is a (IMO more pleasing) space in >> the pre-merge display. > > Please show me how you customize Gnus, (setq gnus-summary-line-format "%U%R%z%((%4L) %-20,20f \x2502 %*%B%s%)\n" gnus-sum-thread-tree-root "\x25b6 " gnus-sum-thread-tree-false-root "\x25b7 " gnus-sum-thread-tree-vertical "\x2502 " gnus-sum-thread-tree-leaf-with-other "\x251c\x2500\x25b8 ..." gnus-sum-thread-tree-single-leaf "\x2570\x2500\x25b8 ...") > and exactly which > font is used in the Gnus summary buffer by C-u C-x =. For ascii: -unknown-DejaVu Sans Mono-normal-normal-normal-*-12-*-*-*-m-0-iso8859-1 For the non-ascii characters: -gnu-unifont-medium-r-normal--16-160-75-75-p-80-iso10646-1 This is post-merge, in the pre-merge buffer, the corresponding line of the character description for both ascii and non-ascii characters is this: dejavu sans mono:pixelsize=12:foundry=unknown:weight=medium:slant=r:width=normal >> - The fringe arrow in the Summary buffer is redisplayed in the mode >> line. > > This is very strange. The font-backend merge should not > touch fringe displaying. I cannot reproduce this; maybe it was a random redisplay glitch, which I just happened to catch in the screen shot. (In contrast, the broken underlining persists.) >> - The character size in the mode line is larger in the post-merge image >> than in the pre-merge image (in both it is font family Helvetica). > >> - The appearance of the non-ascii characters I use for threading and >> separation in the Summary buffer differs; in particular, the separator >> forms a broken vertical line in the post-merge buffer, while it is a >> continuous vertical line in the pre-merge buffer (except for the line >> containing the Indic characters, which is also misaligned in both >> images). > > Please do C-u C-x = on that vertical line to see which font > is used in both version. post-merge: character: │ (9474, #o22402, #x2502) preferred charset: unicode (Unicode (ISO10646)) code point: 0x2502 syntax: _ which means: symbol category: c:Chinese h:Korean j:Japanese buffer code: #xE2 #x94 #x82 file code: #xE2 #x94 #x82 (encoded by coding system utf-8-unix) display: by this font (glyph code) -gnu-unifont-medium-r-normal--16-160-75-75-p-80-iso10646-1 (#x2502) pre-merge: character: │ (9474, #o22402, #x2502) preferred charset: unicode (Unicode (ISO10646)) code point: 0x2502 syntax: _ which means: symbol category: c:Chinese h:Korean j:Japanese buffer code: #xE2 #x94 #x82 file code: #xE2 #x94 #x82 (encoded by coding system utf-8-unix) display: by this font (glyph code) dejavu sans mono:pixelsize=12:foundry=unknown:weight=medium:slant=r:width=normal (#x858) Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-16 10:22 ` Stephen Berman @ 2008-05-17 3:19 ` David De La Harpe Golden 2008-05-17 12:30 ` Stephen Berman 0 siblings, 1 reply; 21+ messages in thread From: David De La Harpe Golden @ 2008-05-17 3:19 UTC (permalink / raw To: Stephen Berman; +Cc: handa, emacs-devel Stephen Berman wrote: > For ascii: > > -unknown-DejaVu Sans Mono-normal-normal-normal-*-12-*-*-*-m-0-iso8859-1 > Call it (a) > For the non-ascii characters: > > -gnu-unifont-medium-r-normal--16-160-75-75-p-80-iso10646-1 > Call it (b) This is mostly me trying to understand something: Those (a) and (b) look like XLFD font specs, as used by X core 1-bit fonts - see output of command xlsfonts [*] > This is post-merge, in the pre-merge buffer, the corresponding line of > the character description for both ascii and non-ascii characters is > this: > > dejavu sans mono:pixelsize=12:foundry=unknown:weight=medium:slant=r:width=normal > Call it (c). That looks like a fontconfig font spec, as used by xft antialiased fonts - see output of fc-list [*] Are you setting X resource "Emacs.FontBackend: xft"? I've found that without that, I get a strange mix of decent and horrible font rendering as xft fonts (yay) and x core fonts (boo) are apparently both used somehow? :::::: I've just found that, at least post font-backend merge and possibly for some time before, emacs /even with/ FontBackend: xft returns XLFD-style specs even when it's clearly using xft rendering and fonts that I _know_ I didn't make available to X core font handling - I find that kind of confusing, emacs must be just inventing and using XLFDs internally ??? e.g. describe-char gives me, which looks like your (a), though I naively expected something like (c): -unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1 A sort of "synthetic XLFD" that emacs has invented. ::::: I would speculate that you [Stephen] don't have FontBackend: xft and your (a) is one of these synthetic XLFDs and (b) is a "real" XLFD corresponding to an X core font ?? So some of your characters (those in (b)) are getting drawn with X core font rendering and some with Xft font rendering (those in (a)), leading to at least some of the visually ugly appearance that is a "feature" of all X core font handling (e.g. lack of antialiasing, poor alignment) ??? [*] Sometimes the same font dirs are added to paths for both core fonts and fontconfig, so the same fonts show up in both xlsfonts and fc-list, but that's a bad assumption to make in general. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-17 3:19 ` David De La Harpe Golden @ 2008-05-17 12:30 ` Stephen Berman 2008-05-17 14:02 ` David De La Harpe Golden 0 siblings, 1 reply; 21+ messages in thread From: Stephen Berman @ 2008-05-17 12:30 UTC (permalink / raw To: emacs-devel On Sat, 17 May 2008 04:19:12 +0100 David De La Harpe Golden <david@harpegolden.net> wrote: > Stephen Berman wrote: > >> For ascii: >> >> -unknown-DejaVu Sans Mono-normal-normal-normal-*-12-*-*-*-m-0-iso8859-1 >> > > Call it (a) > >> For the non-ascii characters: >> >> -gnu-unifont-medium-r-normal--16-160-75-75-p-80-iso10646-1 >> > > Call it (b) > > This is mostly me trying to understand something: > > Those (a) and (b) look like XLFD font specs, as used by X core 1-bit > fonts - see output of command xlsfonts [*] > >> This is post-merge, in the pre-merge buffer, the corresponding line of >> the character description for both ascii and non-ascii characters is >> this: >> >> dejavu sans mono:pixelsize=12:foundry=unknown:weight=medium:slant=r:width=normal >> > > Call it (c). That looks like a fontconfig font spec, as used by xft > antialiased fonts - see output of fc-list [*] > > Are you setting X resource "Emacs.FontBackend: xft"? I've found that > without that, I get a strange mix of decent and horrible font rendering > as xft fonts (yay) and x core fonts (boo) are apparently both used somehow? I have not been setting any X resources, though the distribution I'm using (openSUSE 10.3) does set default X resources for Emacs, though "Emacs.FontBackend: xft" is not among them. I just put that in ~/.Xresources and started a fresh Emacs, but I don't see any difference: the broken underlining and Gnus Summary buffer problems I documented are still present. Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-17 12:30 ` Stephen Berman @ 2008-05-17 14:02 ` David De La Harpe Golden 2008-05-17 18:37 ` Stephen Berman 0 siblings, 1 reply; 21+ messages in thread From: David De La Harpe Golden @ 2008-05-17 14:02 UTC (permalink / raw To: Stephen Berman; +Cc: emacs-devel Stephen Berman wrote: > I have not been setting any X resources, though the distribution I'm > using (openSUSE 10.3) does set default X resources for Emacs, though > "Emacs.FontBackend: xft" is not among them. I just put that in > ~/.Xresources and started a fresh Emacs, but I don't see any difference: > the broken underlining and Gnus Summary buffer problems I documented are > still present. > Just in case: did you add it to the active resource database itself? You can see the current contents of your X resource database with xrdb -q , and add to it by e.g. echo "Emacs.FontBackend: xft" | xrdb -merge ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-17 14:02 ` David De La Harpe Golden @ 2008-05-17 18:37 ` Stephen Berman 2008-05-18 3:30 ` David De La Harpe Golden 0 siblings, 1 reply; 21+ messages in thread From: Stephen Berman @ 2008-05-17 18:37 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1334 bytes --] On Sat, 17 May 2008 15:02:36 +0100 David De La Harpe Golden <david@harpegolden.net> wrote: > Stephen Berman wrote: > >> I have not been setting any X resources, though the distribution I'm >> using (openSUSE 10.3) does set default X resources for Emacs, though >> "Emacs.FontBackend: xft" is not among them. I just put that in >> ~/.Xresources and started a fresh Emacs, but I don't see any difference: >> the broken underlining and Gnus Summary buffer problems I documented are >> still present. >> > > Just in case: did you add it to the active resource database itself? > You can see the current contents of your X resource database with > xrdb -q , and add to it by e.g. > > echo "Emacs.FontBackend: xft" | xrdb -merge Ah, thank you. It was indeed not in the active resource database. After adding it the way you suggest and restarting Emacs, I now do see very clear differences. The non-ascii characters in the Gnus Summary buffer appear as they did before the font backend merge. However, the underlining is still broken and too close to the bottom of the characters. But in addition, now the appearance of variable-pitch face is peculiar and literally variable depending on the values of certain face attributes, in ways that are to me unexpected and unpredictable. The following screen shot shows these observations: [-- Attachment #2: display and face problems with xft font backend --] [-- Type: image/png, Size: 34507 bytes --] [-- Attachment #3: Type: text/plain, Size: 735 bytes --] 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. The Article buffer also has a header line from the tabbar library, which I've customized with font Helvetica, width compressed, height 85 in 1/10 pt and weight medium (and it also shows the over- and underlining from my customized header-line face -- note the underlining is unbroken, in constrast to that of the mode-line face). Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-17 18:37 ` Stephen Berman @ 2008-05-18 3:30 ` David De La Harpe Golden 2008-05-18 18:19 ` Stephen Berman 0 siblings, 1 reply; 21+ messages in thread From: David De La Harpe Golden @ 2008-05-18 3:30 UTC (permalink / raw To: Stephen Berman; +Cc: handa, emacs-devel 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 ? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-18 3:30 ` David De La Harpe Golden @ 2008-05-18 18:19 ` Stephen Berman 2008-05-22 20:36 ` Stephen Berman 0 siblings, 1 reply; 21+ messages in thread From: Stephen Berman @ 2008-05-18 18:19 UTC (permalink / raw To: emacs-devel On Sun, 18 May 2008 04:30:54 +0100 David De La Harpe Golden <david@harpegolden.net> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-18 18:19 ` Stephen Berman @ 2008-05-22 20:36 ` Stephen Berman 2008-05-23 4:16 ` David De La Harpe Golden 2008-05-27 13:17 ` Stephen Berman 0 siblings, 2 replies; 21+ messages in thread From: Stephen Berman @ 2008-05-22 20:36 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2210 bytes --] On Sun, 18 May 2008 20:19:52 +0200 Stephen Berman <Stephen.Berman@gmx.net> wrote: > On Sun, 18 May 2008 04:30:54 +0100 David De La Harpe Golden <david@harpegolden.net> wrote: > >> Stephen Berman wrote: [...] >>> 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". Here is a screen shot of my current mode line and Gnus Summary buffer, in GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2008-05-22 on escher, after Handa-san's latest changes: [-- Attachment #2: font problems --] [-- Type: image/png, Size: 30622 bytes --] [-- Attachment #3: Type: text/plain, Size: 936 bytes --] The (active) mode line face now displays Helvetica correctly. Note, however, that in the inactive mode line face the characters are wider, although mode-line-inactive does not override the width attribute of variable-pitch (changing the width attribute to "narrow" still results in a font family of "monotype-Impact"). In addition, the broken underlining remains (the image shows the spacing with x-use-underline-position-properties set to nil), also in the Gnus Summary buffer. In the latter, the underlining to the right of the vertical separator only appeared after moving the cursor over this region; it disappears when the buffer does not have focus, or when the mouse moves over it (it has a mouse-face overlay). Note also that the non-ascii characters (the vertical line and the curves and arrows used for threading) look much worse than after the previous update: thin, misaligned, and leaving vertical gaps. Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-22 20:36 ` Stephen Berman @ 2008-05-23 4:16 ` David De La Harpe Golden 2008-05-23 12:28 ` Stephen Berman 2008-05-27 13:17 ` Stephen Berman 1 sibling, 1 reply; 21+ messages in thread From: David De La Harpe Golden @ 2008-05-23 4:16 UTC (permalink / raw To: Stephen Berman; +Cc: emacs-devel Stephen Berman wrote: > > The (active) mode line face now displays Helvetica correctly. Note, > however, that in the inactive mode line face the characters are wider, And not anti-aliased? Was this still with FontBackend: xft ? And [welcome to complication, Level 2] did you have fontconfig/xft set to allow bitmap fonts or not? While most linux distros now default to "no", if fontconfig/xft /is/ using bitmap fonts, then "new" font handling can still, depending of course on the font, result in x-core-font-like-in-appearance rendering, you see! (including in emacs with FontBackend: xft, as far as I can tell. Hmmm.) At least if you're on debian or a debian-oid (e.g. ubuntu...), this is usually controlled by which one of /etc/fonts/conf.avail/70-yes-bitmaps.conf or /etc/fonts/conf.avail/70-no-bitmaps.conf is symlinked in to /etc/fonts/conf.d/ (if you change this, you may have to run fc-cache -fv ) I recommend "no". Unless you really have a need of particular glyphs from or just can't live without some old favorite (probably monospace) bitmap font I guess. If you do enable bitmaps in fontconfig, try "fc-list :scalable=False family" in a shell to get the fontconfig names for bitmap fonts usable in fontconfig/xft apps... ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-23 4:16 ` David De La Harpe Golden @ 2008-05-23 12:28 ` Stephen Berman 2008-05-23 16:10 ` David De La Harpe Golden 0 siblings, 1 reply; 21+ messages in thread From: Stephen Berman @ 2008-05-23 12:28 UTC (permalink / raw To: emacs-devel On Fri, 23 May 2008 05:16:11 +0100 David De La Harpe Golden <david@harpegolden.net> wrote: > Stephen Berman wrote: >> >> The (active) mode line face now displays Helvetica correctly. Note, >> however, that in the inactive mode line face the characters are wider, > > And not anti-aliased? Indeed not. > Was this still with FontBackend: xft Yes. > And [welcome to complication, Level 2] did you have fontconfig/xft set > to allow bitmap fonts or not? While most linux distros now default to > "no", if fontconfig/xft /is/ using bitmap fonts, then "new" font > handling can still, depending of course on the font, result in > x-core-font-like-in-appearance rendering, you see! (including in emacs > with FontBackend: xft, as far as I can tell. Hmmm.) > > At least if you're on debian or a debian-oid (e.g. ubuntu...), this is > usually controlled by which one of > /etc/fonts/conf.avail/70-yes-bitmaps.conf or > /etc/fonts/conf.avail/70-no-bitmaps.conf > is symlinked in to /etc/fonts/conf.d/ > (if you change this, you may have to run fc-cache -fv ) > > I recommend "no". Unless you really have a need of particular glyphs > from or just can't live without some old favorite (probably monospace) > bitmap font I guess. My system has the above files and directories. There was no symlink from either of those files, so I added the "no" one, as you suggested, ran fc-cache -fv, and then emacs -q. Helvetica is still not anti-aliased. Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-23 12:28 ` Stephen Berman @ 2008-05-23 16:10 ` David De La Harpe Golden 2008-05-23 17:03 ` Stephen Berman 0 siblings, 1 reply; 21+ messages in thread From: David De La Harpe Golden @ 2008-05-23 16:10 UTC (permalink / raw To: Stephen Berman; +Cc: emacs-devel Stephen Berman wrote: >> Was this still with FontBackend: xft > > Yes. > >> I recommend "no". Unless you really have a need of particular glyphs >> from or just can't live without some old favorite (probably monospace) >> bitmap font I guess. > > My system has the above files and directories. There was no symlink > from either of those files, so I added the "no" one, as you suggested, > ran fc-cache -fv, and then emacs -q. Helvetica is still not anti-aliased. > Hmm. Think it is also possible to instruct fontconfig not to antialias for particular fonts and sizes, but I doubt you've deliberately done that. Er. Mind you, on my system, the only font actually *called* "Helvetica" is the bitmap font that IIRC ships with x.org. But quite a few people have a "Helvetica" outline font (sometimes of dubious legality). I had assumed you had an outline helvetica... So.... just to cross-check - what does fc-list : family scalable | grep -i helvetica now return for you? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-23 16:10 ` David De La Harpe Golden @ 2008-05-23 17:03 ` Stephen Berman 2008-05-23 17:37 ` David De La Harpe Golden 0 siblings, 1 reply; 21+ messages in thread From: Stephen Berman @ 2008-05-23 17:03 UTC (permalink / raw To: emacs-devel On Fri, 23 May 2008 17:10:15 +0100 David De La Harpe Golden <david@harpegolden.net> wrote: > Stephen Berman wrote: > >>> Was this still with FontBackend: xft >> >> Yes. >> >>> I recommend "no". Unless you really have a need of particular glyphs >>> from or just can't live without some old favorite (probably monospace) >>> bitmap font I guess. >> >> My system has the above files and directories. There was no symlink >> from either of those files, so I added the "no" one, as you suggested, >> ran fc-cache -fv, and then emacs -q. Helvetica is still not anti-aliased. >> > > Hmm. Think it is also possible to instruct fontconfig not to antialias > for particular fonts and sizes, but I doubt you've deliberately done that. At least not consciously :-) > Er. Mind you, on my system, the only font actually *called* "Helvetica" > is the bitmap font that IIRC ships with x.org. But quite a few people > have a "Helvetica" outline font (sometimes of dubious legality). I had > assumed you had an outline helvetica... > > So.... just to cross-check - what does > > fc-list : family scalable | grep -i helvetica > > now return for you? Adobe Helvetica:scalable=False Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-23 17:03 ` Stephen Berman @ 2008-05-23 17:37 ` David De La Harpe Golden 2008-05-23 19:42 ` James Cloos 2008-05-23 20:41 ` Stephen Berman 0 siblings, 2 replies; 21+ messages in thread From: David De La Harpe Golden @ 2008-05-23 17:37 UTC (permalink / raw To: Stephen Berman; +Cc: emacs-devel Stephen Berman wrote: >> So.... just to cross-check - what does >> >> fc-list : family scalable | grep -i helvetica >> >> now return for you? > > Adobe Helvetica:scalable=False > scalable=False, eh? Well, I _thought_ that effectively meant no antialiasing in fontconfig/xft land*. The puzzle would be where the helvetica-like font that is antialiased is coming from, then :-). [Not sure, but may need to run fc-cache -fv both as root and as yourself, there may be a global /var/cache/fontconfig dir] fc-list :scalable=False file family scalable should return all non-scalable fonts fontconfig is seeing on your system. * in principle one can, given a big 1-bit bitmap font, extrapolate smoothed values, some amiga-era stuff used to do that IIRC, but I don't *think* xft does that. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-23 17:37 ` David De La Harpe Golden @ 2008-05-23 19:42 ` James Cloos 2008-05-23 20:41 ` Stephen Berman 1 sibling, 0 replies; 21+ messages in thread From: James Cloos @ 2008-05-23 19:42 UTC (permalink / raw To: emacs-devel; +Cc: Stephen Berman, David De La Harpe Golden >>>>> "David" == David De La Harpe Golden <david@harpegolden.net> writes: David> The puzzle would be where the helvetica-like font that is David> antialiased is coming from, then :-). If you ask for the pattern «Helvetica» fontconfig will, using the default fonts.conf, match that against a number of alternatives. You need to use fc-match rather than fc-list to see this. It is, in general, what the users want and expect. The relevant comment is: ,----[ /etc/fonts/conf.d/30-metric-aliases.conf ] | <!-- Alias similar/metric-compatible families from various sources: | | PostScript fonts: | Helvetica | Times | Courier | URW fonts: | Nimbus Sans L | Nimbus Roman No9 L | Nimbus Mono L | | Microsoft fonts: | Arial | Times New Roman | Courier New | Liberation fonts: | Liberation Sans | Liberation Serif | Liberation Mono | StarOffice fonts: | Albany | Thorndale | Cumberland | AMT fonts: | Albany AMT | Thorndale AMT | Cumberland AMT | | Of these, URW fonts are design compatible with PostScrict fonts, | and the Liberation, StarOffice, and AMT ones are compatible with | Microsoft fonts. | | We want for each of them to fallback to any of these | available, but in an order preferring similar designs | first. We do this in three steps: | | 1) Alias each specific to it's generic family. | eg. Liberation Sans to Arial | | 2) Weak alias each generic to the other generic of its family. | eg. Arial to Helvetica | | 3) Alias each generic to its specifics. | eg. Arial to Liberation Sans, Albany, and Albany AMT | --> `---- -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-23 17:37 ` David De La Harpe Golden 2008-05-23 19:42 ` James Cloos @ 2008-05-23 20:41 ` Stephen Berman 2008-05-23 21:57 ` David De La Harpe Golden 1 sibling, 1 reply; 21+ messages in thread From: Stephen Berman @ 2008-05-23 20:41 UTC (permalink / raw To: emacs-devel On Fri, 23 May 2008 18:37:00 +0100 David De La Harpe Golden <david@harpegolden.net> wrote: > Stephen Berman wrote: > >>> So.... just to cross-check - what does >>> >>> fc-list : family scalable | grep -i helvetica >>> >>> now return for you? >> >> Adobe Helvetica:scalable=False >> > > scalable=False, eh? Well, I _thought_ that effectively meant > no antialiasing in fontconfig/xft land*. The puzzle would > be where the helvetica-like font that is antialiased is coming from, > then :-). I guess you mean the font that realizes mode-line-inactive face (in my penultimate reply to you, I was confused and mistakenly said that this face was *not* anti-aliased; it *is*, as you seem to realize)? It is this: -unknown-DejaVu Sans-extra-light-normal-normal-*-12-*-*-*-*-0-iso8859-1 Moreover, the face in the tabbar header line, which also inherits variable-pitch but like mode-line-inactive overrides some attributes, is also anti-aliased, and it is realized by this font: -b&h-Lucida Sans-normal-normal-normal-*-10-*-*-*-*-0-iso8859-1 My reply may have confused you as well, so to be clear, the font realizing mode-line face is indeed *not* anti-aliased, and it is indeed Helvetica: -Adobe-Adobe Helvetica-normal-normal-normal-*-12-*-*-*-*-*-iso8859-1 > [Not sure, but may need to run fc-cache -fv both as root and as > yourself, there may be a global /var/cache/fontconfig dir] I only ran it as root. > fc-list :scalable=False file family scalable > > should return all non-scalable fonts fontconfig is seeing on your system. The output includes Adobe Helvetica but not the other two fonts above (though B&H Lucida, B&H LucidaBright, and B&H LucidaTypewriter are listed). I also tried fc-match as per James Cloos's suggestion, but I don't know if I did it right: % fc-match :family=Helvetica n019003l.pfb: "Nimbus Sans L" "Regular" % fc-match :family="Adobe Helvetica" helvR12.pcf.gz: "Adobe Helvetica" "Regular" If either of these is right, it doesn't shed any light on why Emacs uses DejaVu Sans and b&h-Lucida Sans for faces derived from variable-pitch in my cases. Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-23 20:41 ` Stephen Berman @ 2008-05-23 21:57 ` David De La Harpe Golden 2008-05-24 1:16 ` James Cloos 2008-05-24 23:01 ` Stephen Berman 0 siblings, 2 replies; 21+ messages in thread From: David De La Harpe Golden @ 2008-05-23 21:57 UTC (permalink / raw To: Stephen Berman; +Cc: emacs-devel Stephen Berman wrote: > -Adobe-Adobe Helvetica-normal-normal-normal-*-12-*-*-*-*-*-iso8859-1 > > The output includes Adobe Helvetica but not the other two fonts above > (though B&H Lucida, B&H LucidaBright, and B&H LucidaTypewriter are > listed). > I guess the filenames all ended in .pcf or .pcf.gz ? If so, they're all fonts that ship as bitmaps with X. Yours apparently have the foundry names prepended in the family though, which might be some sort of policy change that I haven't encountered yet. Of course they shouldn't be showing up at all if you've successfully disabled bitmap fonts. Huh. > If either of these is right, it doesn't shed any light on why Emacs uses > DejaVu Sans and b&h-Lucida Sans for faces derived from variable-pitch in > my cases. > Guess not. But - bah. That "helv" (rather than "helvetica") that is in emacs' variable-pitch's family by default is IMO unlikely to do anything particularly sensible (unlike the "courier" default in fixed-pitch) - "helv" is neither the name of a font nor an alias in fontconfig as far as I can see, and family matching is not AFAICS substring-based in fontconfig. I had actively set my variable-pitch face to DejaVu Sans. Are you resetting it or leaving it default? Since "helv" doesn't match anything, the decision is probably down to other factors, like charsets covered or phase of the moon e.g. helv: fc-match helv:lang=ie => Vera.ttf: "Bitstream Vera Sans" "Roman" fc-match helv:lang=ru => DejaVuSans.ttf: "DejaVu Sans" "Book" fc-match helv:lang=ja => sazanami-gothic.ttf: "Sazanami Gothic" "Regular" silly name (as you can see, same results as helv): fc-match wheresmyjumper:lang=ie => Vera.ttf: "Bitstream Vera Sans" "Roman" fc-match wheresmyjumper:lang=ru => DejaVuSans.ttf: "DejaVu Sans" "Book" fc-match wheresmyjumper:lang=ja => sazanami-gothic.ttf: "Sazanami Gothic" "Regular" helvetica, apparently using the substitutions James Cloos mentioned: fc-match helvetica:lang=ie => n019003l.pfb: "Nimbus Sans L" "Regular" fc-match helvetica:lang=ru => n019003l.pfb: "Nimbus Sans L" "Regular" fc-match helvetica:lang=ja => n019003l.pfb: "Nimbus Sans L" "Regular" *** So perhaps emacs should default to "helvetica" for variable-pitch if it's gonna default to "courier" for fixed-pitch. Then fontconfig might have a chance. :-) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-23 21:57 ` David De La Harpe Golden @ 2008-05-24 1:16 ` James Cloos 2008-05-24 23:01 ` Stephen Berman 1 sibling, 0 replies; 21+ messages in thread From: James Cloos @ 2008-05-24 1:16 UTC (permalink / raw To: David De La Harpe Golden; +Cc: Stephen Berman, emacs-devel >>>>> "David" == David De La Harpe Golden <david@harpegolden.net> writes: David> silly name (as you can see, same results as helv): David> fc-match wheresmyjumper:lang=ie => Vera.ttf: "Bitstream Vera Sans" "Roman" David> fc-match wheresmyjumper:lang=ru => DejaVuSans.ttf: "DejaVu Sans" "Book" David> fc-match wheresmyjumper:lang=ja => sazanami-gothic.ttf: "Sazanami Gothic" "Regular" That case falls back to the default font, which is usually the «Sans» alias. Though some might set «Serif» as their default. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-23 21:57 ` David De La Harpe Golden 2008-05-24 1:16 ` James Cloos @ 2008-05-24 23:01 ` Stephen Berman 1 sibling, 0 replies; 21+ messages in thread From: Stephen Berman @ 2008-05-24 23:01 UTC (permalink / raw To: emacs-devel On Fri, 23 May 2008 22:57:10 +0100 David De La Harpe Golden <david@harpegolden.net> wrote: > Stephen Berman wrote: > >> -Adobe-Adobe Helvetica-normal-normal-normal-*-12-*-*-*-*-*-iso8859-1 >> >> The output includes Adobe Helvetica but not the other two fonts above >> (though B&H Lucida, B&H LucidaBright, and B&H LucidaTypewriter are >> listed). >> > > I guess the filenames all ended in .pcf or .pcf.gz ? Yes. > If so, they're all > fonts that ship as bitmaps with X. Yours apparently have the foundry > names prepended in the family though, which might be some sort of policy > change that I haven't encountered yet. [...] > But - bah. That "helv" (rather than "helvetica") that is in emacs' > variable-pitch's family by default is IMO unlikely to do anything > particularly sensible (unlike the "courier" default in fixed-pitch) - > "helv" is neither the name of a font nor an alias in fontconfig as far > as I can see, and family matching is not AFAICS substring-based in > fontconfig. [...] > *** So perhaps emacs should default to "helvetica" for variable-pitch > if it's gonna default to "courier" for fixed-pitch. Then fontconfig > might have a chance. :-) I tried both "Helvetica" and "Adobe Helvetica" but didn't notice any difference from just "helv". However, after adding the x font backend (as well as xft), the mode-line-inactive and tabbar-default faces did get realized with Helvetica font (not anti-aliased). Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: (re)display problems after font backend merge 2008-05-22 20:36 ` Stephen Berman 2008-05-23 4:16 ` David De La Harpe Golden @ 2008-05-27 13:17 ` Stephen Berman 1 sibling, 0 replies; 21+ messages in thread From: Stephen Berman @ 2008-05-27 13:17 UTC (permalink / raw To: emacs-devel On Thu, 22 May 2008 22:36:43 +0200 Stephen Berman <Stephen.Berman@gmx.net> wrote: > Here is a screen shot of my current mode line and Gnus Summary buffer, > in GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of > 2008-05-22 on escher, after Handa-san's latest changes: > > > > > The (active) mode line face now displays Helvetica correctly. Note, > however, that in the inactive mode line face the characters are wider, > although mode-line-inactive does not override the width attribute of > variable-pitch (changing the width attribute to "narrow" still results > in a font family of "monotype-Impact"). In addition, the broken > underlining remains (the image shows the spacing with > x-use-underline-position-properties set to nil), also in the Gnus > Summary buffer. In the latter, the underlining to the right of the > vertical separator only appeared after moving the cursor over this > region; it disappears when the buffer does not have focus, or when the > mouse moves over it (it has a mouse-face overlay). Note also that the > non-ascii characters (the vertical line and the curves and arrows used > for threading) look much worse than after the previous update: thin, > misaligned, and leaving vertical gaps. With current CVS (actually, I think since Friday), all the display problems I reported with the mode line and the Gnus Summary buffer have been fixed (and the non-ascii characters look good again). Thanks! Steve Berman ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2008-05-27 13:17 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-05-15 18:45 (re)display problems after font backend merge Stephen Berman 2008-05-16 0:57 ` Kenichi Handa 2008-05-16 10:22 ` Stephen Berman 2008-05-17 3:19 ` David De La Harpe Golden 2008-05-17 12:30 ` Stephen Berman 2008-05-17 14:02 ` David De La Harpe Golden 2008-05-17 18:37 ` Stephen Berman 2008-05-18 3:30 ` David De La Harpe Golden 2008-05-18 18:19 ` Stephen Berman 2008-05-22 20:36 ` Stephen Berman 2008-05-23 4:16 ` David De La Harpe Golden 2008-05-23 12:28 ` Stephen Berman 2008-05-23 16:10 ` David De La Harpe Golden 2008-05-23 17:03 ` Stephen Berman 2008-05-23 17:37 ` David De La Harpe Golden 2008-05-23 19:42 ` James Cloos 2008-05-23 20:41 ` Stephen Berman 2008-05-23 21:57 ` David De La Harpe Golden 2008-05-24 1:16 ` James Cloos 2008-05-24 23:01 ` Stephen Berman 2008-05-27 13:17 ` Stephen Berman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).