Sure, but we need a specific API proposal, and I don't have much spare time to work on that myself.

I guess API-wise, there are 3 main avenues:

a) export a bunch of methods (attached to the sfnt.Font type) that return a specific exported table type:

func (f *Font) CMapTable()  CMapTable
func (f *Font) KernTable()  KernxTable
func (f *Font) KernxTable() KernxTable
func (f *Font) MathTable()  MathTable
// etc...

b) export a bunch of table fields, each with its own type

type Font struct {
    // ...
    CMapTable CMapTable
    MathTable MathTable
}

c) export a single sfnt.Font method that takes as argument a Table interface that knows how to decode itself from a provided range of bytes (the sfnt.table type)

type Table interface {
    Kind() TableKind // or just: Name() string where string is the 4b-tag. eg: "OS/2", "math", "maxp", ...
    decodeFrom(src table, f *Font) error
}

func (f *Font) Table(tbl Table) error {
    src, err := f.table(tbl.Kind())
    if err != nil { return err }
    return tbl.decodeFrom(src, f)
}

type MathTable struct { ... }
func (tbl *MathTable) Kind() TableKind { return MathTableKind }
func (tbl *MathTable) decodeFrom(src table, f *Font) error { ... }

// use:
func foo(f *sfnt.Font) {
    var tbl sfnt.MathTable
    err := f.Table(&tbl)
    if err != nil { panic(err) }
}

then comes the question of whether for the Table types:

• to be "just" a view into the table+Font sea of bytes (and thus only export methods to decode+retrieve that data on each invocation) - this complicates a bit the ownership model of the src source field of the Font values, or
• to have the Table types decode+store the decoded data into their own dedicated fields.

from the precedent of the existing sfnt.PostTable table, I guess the latter would be preferred, but that may not be advisable if the tables are large ( eg. the "glyf" table)

then comes the question of whether for the Table types:

Well, that's the important question for me. What are the actual fields of type CMapTable, etc.