> And is it just my problem I can't find the source of ttf2subf? > (It seems that although the package ttf2subf installs the 386 binary > and a man page, the sys/src/cmd/ttf2subf directory is empty...)
a p9p version of ttf2subf is in /n/sources/contrib/quanstro/ttf2subf i've been able to fix the reported problem just by compiling against a newer version of freetype and reconverting the vera font. it's completely unclear to me if this is a change in freetype, vera, or something else. there are two related bugs that are not fixed by reconversion. using vera, 1. type vj. notice that the right arm of the v gets chopped off. (boys and girls, keep your hands inside moving vehicles!) 2. select the j just typed and cut it. now move the tick somplace out. notice the grey goo left behind. the second can be "fixed" by having ttf2subf by clamping right at 0. this is wrong, since we're just chopping off the tail of the j. one can get a feel for what's going wrong by looking at the first problem. consider the string vera itself. you'll notice that the v is placed so it overlaps the e. this looks great, but it violates the unwarranted (and most likely unintended) assumption — that characters live inside bounding boxes. this assumption is partially due to the fact that stringbg is used by libframe to avoid α² problems when redrawing, and to avoid severe performance penalities for fonts of depth>1. frame buffers are slow. but even without using stringbg, things still don't look right. (try a little highlighting with a ca. 2006 rio.) i haven't had a chance to think this through, but naïvely, one would think that also drawing adjacent characters and clipping would solve the problem via the use a bigger hammer technique. - erik
