[font/opentype] add ResourceSlicer, so tables are not copied

[mike-ward]

Loader.RawTable copies every table out of the Resource into a new buffer, and a font.Font keeps the tables it parses. For a color emoji font that is most of the file. The sbix table of macOS Apple Color Emoji.ttc is 182 MB, so NewFont on it keeps 193 MB on the Go heap. A terminal that falls back to this font for one emoji grows by that much.

As suggested in review, this PR adds an optional interface, checked in findTableBuffer:

type ResourceSlicer interface {
	Resource
	Slice(start, end int64) ([]byte, error)
}

func NewSliceResource(data []byte) ResourceSlicer

When the Resource given to NewLoader or NewLoaders is a ResourceSlicer, each uncompressed table is the slice that Slice returns. It is not copied. NewSliceResource wraps a bytes.Reader for callers that have the whole file in memory. The data can also be a read-only memory mapping of the file. The OS then pages the tables in as they are used, and can drop the pages again under memory pressure.

• The capacity of each returned table stops at the table end, so if a caller appends to it, the next table is not overwritten.
• If Slice returns an error, or a slice of the wrong length, RawTable returns an error.
• Compressed WOFF tables are still decoded into a new buffer.
• On this path dst in RawTableTo is not used. dst can be a table that an earlier call returned (NewFont and fontscan pass the previous buffer back), and that table is now a view of read-only memory.
• NewSliceResource rejects the same table ranges as bytes.Reader.ReadAt, so both paths accept the same fonts.
• A Resource that does not implement Slice works as before.

I checked that nothing in font or tables writes into a table buffer. The only write found, in KernData1.parseValues, goes to a [4]byte array field.

Measured

Apple Color Emoji.ttc, face 0, heap after runtime.GC() with the Font alive:

Resource	Heap
os.File	+193 MB
syscall.Mmap + NewSliceResource	+11 MB

U+1F600 still decodes as a PNG GlyphBitmap.

Tests

• Every table of each common and collections font (this includes a compressed WOFF) reads back the same as from a bytes.Reader.
• Each uncompressed table is a view of the input, with cap == len.
• RawTableTo with the previous table as dst leaves the input unchanged.
• A truncated input returns errors and does not panic.
• A Slice error, or a short slice, from an outside implementation is returned as an error.
• In font, sbix glyph data from the Sbix toy fonts is the same as from a bytes.Reader, and it points into the input.

go test ./..., go vet and staticcheck v0.8.2 are clean.

🤖 Generated with Claude Code

[benoitkugler]

Hello,

While I sympathize with the issue, I'm not sure I like the proposed solution that much. It seems the issue is that findTableBuffer always allocate (when dst is nil). It is indeed unfortunate when using read-only memory mapping.

Could we instead introduce an interface extending Resource with the following method :
Slice(start, end int) []byte
and change findTableBuffer to rely on such a method if present ?

Then, the new interface is easy to implement if you already have the whole resource as a byte slice.

[mike-ward]

Thanks, that is cleaner. I'll rework it as an optional interface checked in findTableBuffer. Two questions:

1. Can Slice return an error, Slice(start, end int64) ([]byte, error)? Then a bad table offset returns an error and does not panic, and the types match ReadAt.
2. Do you want an exported type that wraps []byte and has Slice, or should callers write their own?

On the slice path, dst will still be ignored (a previous result can be a view of read-only memory), and the returned slice will be capped at the table end.

[benoitkugler]

Thanks, that is cleaner. I'll rework it as an optional interface checked in findTableBuffer. Two questions:

1. Can Slice return an error, Slice(start, end int64) ([]byte, error)? Then a bad table offset returns an error and does not panic, and the types match ReadAt.
2. Do you want an exported type that wraps []byte and has Slice, or should callers write their own?

On the slice path, dst will still be ignored (a previous result can be a view of read-only memory), and the returned slice will be capped at the table end.

Yes, returning an error should be fine.

I'm not sure about exporting a concrete type wrapping a slice. Maybe that would benefit other users who already have the full slice "in memory" ?

[mike-ward]

Thanks. I'll add ResourceSlicer (Resource + Slice(start, end int64) ([]byte, error)), checked in findTableBuffer, and drop NewLoadersFromBytes. I'll also export a small NewSliceResource([]byte) wrapper over bytes.Reader, since any mmap or in-memory user needs one. It is easy to remove if you'd rather not have it.

[mike-ward]

@benoitkugler The rework is pushed (b157558):

• ResourceSlicer (Resource + Slice(start, end int64) ([]byte, error)) is checked in findTableBuffer. NewLoadersFromBytes is removed.
• NewSliceResource([]byte) wraps a bytes.Reader. It is easy to remove if you'd rather callers write their own.
• On the slice path, dst is not used, and each table is capped at its end. A Slice error, or a slice of the wrong length, is returned as an error.

The heap result is the same as before: +11 MB with an mmap of Apple Color Emoji, against +193 MB with an os.File. The PR description has the details.

[mike-ward]

The static_analysis failure is not caused by this PR. analysis.yml installs staticcheck@v0.8.0 with go-version: 'stable', which is now Go 1.27. Staticcheck v0.8.0 cannot read the export data of Go 1.27:

internal error in importing "internal/byteorder" (cannot decode "internal/byteorder", export data version 5 is greater than maximum supported version 4)

It stops before it checks any code. Other branches fail the same way, for example fontscan/system-fonts-without-cache on Oct 11. With staticcheck v0.8.2, this branch has no findings. All six test jobs pass.

Changing the pin in .github/workflows/analysis.yml to staticcheck@v0.8.2 fixes it. I can open a separate PR for that if you want.