Meeting minutes
extending the IFT format to allow having multiple listed patches per entry.
I'll follow up with an email to the mailing list but here's a high level summary of the proposal:
- Having multiple patches associated with an entry can allow us to significantly reduce the number of patches needed when we want table keyed patches that add multiple segments at once. Prior to this change it's necessary to have a patch for each combination.
- We can extend the spec to support this without being to distruptive to existing processes (or encoding size) by reserving one bit of the entry id delta field to indicate another delta follows.
- Then in extension we treat any entry ids beyond the first as a set of additional patches to preload. This goes into the existing preload step.
Agreement this sounds like a good idea.
Garret to create a PR spec change
a quick look into some work on glyph keyed patch segmentation.
I've been doing some prototyping on an analysis program that can determine glyph segmentations for glyph keyed patches that satisfy the closure requirements. This is an extension of Skef's earlier work on binned ift, it uses the new capabilities of IFT to find form glyph segments that can be loaded conditional (eg if f and i is present then load a
patch with fi)
Early results are very promising, it was able to find homes for all glyphs in a segmentation of Noto Nastaliq Urdu (which is extremely complex with respect to shaping) and the total size of that segmentation is comparable to one that uses a minimal number of patches.
Skef has concerns about the overall performance of this approach. In the earlier IFTB version some fonts could take 4 minutes of processing.
Skef also the work I'm doing on dependency analysis could feed into this by helping creating good quality initial segmentations. Then the dep analysis can skip handling some of the more complex cases since a pass of the closure analysis can ensure correctness.
Garret agreed on performance concerns, something I want to test more with an emoji font. Good news is this can be parallelized to help on the performance side.
Tenative plan for next meeting is Mar 4th