Meeting minutes
overview of the new approach to IFT which replaced patch subset/range request
<ChrisL> Explainer at https://
<Vlad> IFT Working Draft: https://
<ChrisL> binned IFT should be added to the explainer. But we should say why we merged in Patch-Subset and why we need non-independent patches
sounds good
<ChrisL> Does the encoder depend at all on the content to be rendered, or just on overall statistical data for the langauge(s) in question?
<ChrisL> Ok so the pre-prepared groups help with privacy but actual patch requests are still determined by the content on the page. I think we need to say that more clearly in the explainer
Sergey: are segment sizes configurable?
<ChrisL> small group sizes (and non-uniform group sizes) have little effect on efficiency
Garret: yes, small segments are supported due to low overhead
Skef: it should be possible to configure segments for specific content if the font is only used for that content.
Skef: Adobe's experience is youre going to have cases where you struggle to serve the content. Say you have a popular tv website with chat and a new episode comes out and people join and different times with idfferent context everyone has a different subset
Skef: difficult to serve all those with a dynamic approach.
Skef: and so ultimately not as performant.
Sergey: question about patch map - how big are the maps?
Garret: map needs to encode codepoints so scales with that, we re-use the sparse bit set encoding from the earlier patch subset approach which allows us to very compactly encode integer sets.
Skef: also for dependent patches we only encode one level at a time.
John: can you explain independent/dependent distinction?
<ChrisL> Probably worth going into how this works with subsetted variation axes, too
Garret: dependent patches have to be applied in serial, applying one invalidates others. They are only valid against a specific base.
Skef: explains example of dependent patches.
John: why do we need the twotypes?
Garret: independent patches can only modify glyph data, while dependent patches can modify any data in the table. Most encodings are expected to use a mix of both.
Skef: some cjk fonts may be special case that only need independent
Chris: we can also patch in variation spaces. Those would be dependent.
Skef: spec allows you to have idependent patches can patch gvar, but can't do things like extend the number of axes.
John: say I have a big font with nastaliq. You've got unicode ranges that segment those into patches. Each of those arabic codepoints maps to multiple glyphs. There's shaping stuff that's needed there (eg. cmap, gsub)
<ChrisL> vlad, Garret hope we can cover the other two agenda items while we still have John and davelab6 - or do we need another call?
Garret: yes, the encoder will typically use a subsetter that will ensure all the relevant glyphs and other data is present for the specific subset.
Skef: spec also has some details on the glyph closure requirement for independent patches.
Skef: eg. if you have glyphs reachable from two different segments, both might include data for that glyph so it's available if either is used on it's own.
https://
John: how does gpos data get added when it's split across two patches?
Garret: common data between two patches would be added when the second patch is applied (due to the dependent nature of the patches)
<ChrisL> Let's take the stakeholder support/opposition to github because that is holding up starting TAG review.
Sergey: what state is needed on the client? eg. what needs to be stored in cache?
Garret: the font file has all state information needed contained.
<davelab6> Dave: I suggest garret using vids.google.com to make a presented version of his deck and putting it on youtube
<davelab6> chris: lets present 'what does this do for me' first and then 'how does it do it'
<ChrisL> rssagent, make minutes