Re: (re)display problems after font backend merge

[Stephen Berman]

On Sun, 18 May 2008 04:30:54 +0100 David De La Harpe Golden <address@hidden> 
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