TrueType problem + question

[Thomas Dickey]

On Tue, 7 Jun 2005, Alexander Gottwald wrote:

> On Tue, 7 Jun 2005, Thomas Dickey wrote:
>
>> On Tue, 7 Jun 2005, Alexander Gottwald wrote:
>>
>>> Other programs (like xterm, gvim and other gtk2 based programs)
>>> use client side fonts which are named with the true font name.
>>>
>>>
>>> In xterm:
>>> xterm -fn -microsoft-tahoma-bold-r-normal--24-0-0-0-p-0-iso8859-1
>>> xterm -fa "Tahoma 24" -fs 24
>>>                 ^^^ This disables wide paddings.
>>> @Thomas: Do you know what is causing this?
>>
>> I'm not sure what "wide paddings" refers to.
>
> with -fa "Tahoma" it looks like
> a g o @ l i s z t   / u s r / b i n
> $
>
> each character takes about twice the space, but the second half is just blank.
> I noticed  this behaviour with "Bitstream Vera Sans" but not with "Bitstream
> Vera Sans Mono" on Debian Sarge and on cygwin.

I've seen that - but not recently (but can check these fonts).  Mostly I 
recall this in the context of bitmap fonts. xterm checks the font metrics 
and uses the maximum cell dimensions. Usually this shows up with bitmap 
proportional fonts (compare "M" and "."), but apparently some fixed-pitch 
fonts have incorrect metrics.

xterm is drawing all of the cells to the same width, based on the 
information it can obtain about the font.

Checking for the comparable code with Xft, I see this in fontutils.c
around line 1260, e.g.,

 	if (norm == 0) {
 	    term->misc.render_font = False;
 	    update_font_renderfont();
 	} else {
 	    win->f_width = norm->max_advance_width;
 	    win->f_height = norm->height;
 	    win->f_ascent = norm->ascent;
 	    win->f_descent = norm->descent;
 	    if (win->f_height < win->f_ascent + win->f_descent)
 		win->f_height = win->f_ascent + win->f_descent;
 	    if (is_double_width_font_xft(screen->display, norm))
 		win->f_width >>= 1;
 	}

The "win->f_width" is coming from Xft's max_advance_width value for the 
font (there's no average value).  I suppose there might be a double-width 
glyph in the font, but without some work (a quick look at the header files 
for Xft and fontconfig doesn't seem to show individual cell sizes), I'm 
not sure if it's an error in the fonts.

>> A  quick check on my Debian machine shows I can run
>>
>> xterm -fa "Tahoma 24" -fs 24
>> xterm -fa "Tahoma" -fs 24
>>
>> with the same effect.  Perhaps the Xft library is ignoring the part after
>> the space.
>
> Xft tries an exact match and with "Tahoma 24" it fails and uses the default
> font instead.

I'd expect that - but when I ran it this morning I got the same font with
and without the " 24".  Perhaps there's an alias.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net