googlefonts / googlefonts/oxidize

Brief may update

Open
#18 5 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
351
Forks
13
PR merge metrics
No merged PRs in 30d

Description

### status

The past month or so has been a bit slow, and a bit frustrating, and so I want to step back and outline my current thinking & progress.

I've ended up spending a bunch of time just developing a better understanding of how to think about table structure, packing, tracking offsets, etc. I've also spent a bunch of time trying to come up with an API/design that supports both from-scratch compilation as well as allowing reuse of parsed font data.

In brief, there is a fundamental tension between the design of a harfbuzz-style subsetter and the design of a general purpose font compiler. I am comfortable coming up with a design for each of these things independently, but I am finding it challanging to come up with something that does both (although I believe we should be able to have components, such as a repacker, that can be reused in both cases, and this is not insignificant.)

While the subsetter cannot be reused for compilation, general purpose compilation types *can* be reused for subsetting. We can, if desired, use these types to implement a subsetter or an instancer, in addition to a full compiler.

So I would now like to focus explicitly on the general case of 'types for compilation'. This involves having higher-level representations of the various tables and records, that can be created and mutated and then compiled down to their binary representations. It will be possible to create these types directly, and it will also be possible to convert parsed font types into these higher-level types.

If we find that the performance of this approach is unacceptable, we can then choose to write more specialized implementations. We can also do this piecemeal, specializing only specific tables.

### next steps / tl;dr

I am taking the last two weeks of May off. I would like to spend the two weeks leading up to then really focusing on the general case of compiling font tables. I feel like I have been letting myself be too concerned with abstract concerns about performance and flexibility, and that this is letting me expand the scope of the problem too drastically. Once I have a design that basically *works*, we will be able to determine its limitations, and decide if there are specific areas that need further attention.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.