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 ?