Re: [9fans] problem using a vera font in rio

[erik quanstrom <quanstro@quanstro.net>]

> 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