libttf might still have a bit of life in it.  I have another set of patches
that adds 8 bit support and am part way through changing the rasterization
to compute coverage analytically.
That removes the need for the truetypefs and ttfrender supersampling paths,
and makes it cheap to perform the coverage calculation at three different
offsets for subpixel coloring.
I think this is a more invasive change, requiring an API change to libttf,
adding a depth or format parameter to the allocation calls.

If we want to do subpixel then it's probably an even more invasive change,
using a full format specifier to allow libttf to generate r8g8b8a8 (r, g, b
for subpixel, raw coverage in alpha?), and then changes in devdraw and
drawterm support the correct compositing.

My opinion is that the short term "make truetype work" is to use my
truetypefs patch.  The next step would be to move the coverage calculation
into libttf, in hscan().  The subpixel change is so invasive that I'd
prefer to wait (and perhaps help with) for the full do-over Sigrid is
working.

Are there any other users of truetypefs?  It's now my daily driver for
rio/acme, with Kurinto and Go fonts in regular use.  Though some the
Kurinto fonts have some problems in hinting which crash libttf.

Thoughts, Sigrid?

Paul

On Mon, Jan 20, 2025 at 9:53 AM <ori@eigenstate.org> wrote:

> Quoth Sigrid Solveig Haflínudóttir <sigrid@ftrv.se>:
> > The more common way to do it, I believe, is to render 3x the size
> > (on either X or Y axis, depending on your display's pixels) image
> > of a character, then apply a FIR to get rid of as much color
> > banding as possible.
> >
> > https://git.sr.ht/~ft/fnt does exactly that. The sources are there
> > for anyone to explore and contribute to.
>
> I the path forward may be to port truetypefs to this, and then
> remove libttf -- Sigrid, thoughts?
>