(re)display problems after font backend merge

(re)display problems after font backend merge

[Stephen Berman]

[-- 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

Re: (re)display problems after font backend merge

[Kenichi Handa]

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

Re: (re)display problems after font backend merge

[Stephen Berman]

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

Re: (re)display problems after font backend merge

[David De La Harpe Golden]

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.

Re: (re)display problems after font backend merge

[Stephen Berman]

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

Re: (re)display problems after font backend merge

[David De La Harpe Golden]

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

Re: (re)display problems after font backend merge

[Stephen Berman]

[-- 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

Re: (re)display problems after font backend merge

[David De La Harpe Golden]

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 ?

Re: (re)display problems after font backend merge

[Stephen Berman]

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

Re: (re)display problems after font backend merge

[Stephen Berman]

[-- 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

Re: (re)display problems after font backend merge

[David De La Harpe Golden]

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...

Re: (re)display problems after font backend merge

[Stephen Berman]

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

Re: (re)display problems after font backend merge

[David De La Harpe Golden]

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?

Re: (re)display problems after font backend merge

[Stephen Berman]

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

Re: (re)display problems after font backend merge

[David De La Harpe Golden]

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.

Re: (re)display problems after font backend merge

[James Cloos]

>>>>> "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

Re: (re)display problems after font backend merge

[Stephen Berman]

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

Re: (re)display problems after font backend merge

[David De La Harpe Golden]

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. :-)

Re: (re)display problems after font backend merge

[James Cloos]

>>>>> "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

Re: (re)display problems after font backend merge

[Stephen Berman]

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

Re: (re)display problems after font backend merge

[Stephen Berman]

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