From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 14 Feb 2010 13:34:11 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] problem using a vera font in rio Topicbox-Message-UUID: d34db7c6-ead5-11e9-9d60-3106f5b1d025 > 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