> When I use vera/unicode.12.font for either acme or rio (see the
> screenshot attached) and I write e.g. 'troff', then I move in front of
> 'troff', write something there, say 'mv', 'space', and move the mouse
> cursor away by clicking e.g. at the end of the line, the 't' letter of
> the 'troff' word is not correctly displayed.
>
> What causes this?
it turns out that neither the 'm' nor the space trigger this problem.
the problem lies with 'v'.
i wrote a little program to dump Cacheinfo/Fontchar information.
i copied the source an executable (capable of 32-bit runes) to sources:
/n/sources/contrib/quanstro/^(fontchr fontchr.c)
it appears that v's left takes on an unexpected value. note the
value of left for the vera font:
; char=v {8.out $char; 8.out -f /lib/font/bit/vera/vera.14.font $char}
sfname /lib/font/bit/cyberbit/cyberbit.14.0000
Cacheinfo x 6 w 6 left 0 v 000076
Fontchar x 582 top 4 bottom 11 left 0 width 6
sfname /lib/font/bit/vera/vera.14.0020
Cacheinfo x 10 w 7 left -1 v 000076
Fontchar x 639 top 5 bottom 13 left -1 width 7
i would suspect that this is a fault in ttf2subf.
the definitions in subfont(2) notwithstanding, it's not clear to
me that a value of -1 is necessarily bogus. consider an antialiased
font with a character like 'v'. the top left edge of the v should be
shaded to the left. if the top left edge of the font is at x=0, then
antialiasing would leave our character box and bleed into the previous
one. this would lead to surprising values of Fontchar->left.
likewise, i think that ttf2subf could set Fontinfo->width greater than
Cacheinfo->x.
- erik
