Hybrid approach to PFE

Folks,

On a couple of different occasions I made remarks about a potentially different approach to progressive font enrichment - the initial idea [that was inspired by internal discussions with Kamal Mansour] prompted me to consider glyphID-based vs. codepoint-based approaches [1], and I recently alluded to a different twist of a glyphID-based approach [2] without giving it much substance in my brief remark. So, this email is an attempt to describe what I have in mind and open it up for discussion as a potential hybrid approach to PFE, drawing on some bits and pieces from both SmartServer patch-based solution and from Myles' alternative proposal for a byte-range solution.

The hybrid approach is a twist of a smart server solution [that is much less demanding as far as smarts are concerned], which IMO offers additional benefits addressing certain concerns we recently discussed. In a nutshell, the solution would consist of implementing the following steps:

1)      Every initial webfont request is satisfied with a font load where all mapping/metrics/layout/shaping tables are intact, and all glyph data is removed (could be as simple as zeroing out loca and glyf tables for TTF glyphs, where the subsequent Brotli compression would essentially eliminate this extra weight).

2)      Once a browser receives a webfont, it would be able to do the following:
- determine the codepoint coverage for a given webfont (therefore, being able to immediately make decisions about fallback fonts, or kicking in another request for an additional font resource), and
- make shaping / layout decisions based on available data to determine glyph IDs that need to be fetched for rendering of a page content.

3)      A browser sends a request for a set of glyphIDs that are needed for this particular page content. (Since all shaping decision are made by the browser taking into account CSS feature settings and relevant script- and language-specific font features - a set of glyphIDs is all that is needed to communicate back to the server, consider it a combined instance of multiple byte-range requests with a caveat that the actual byte ranges will be determined on a server side.)

4)      Font server responds with a patch that includes the requested glyphIDs data to update the initial font load, thus creating a complete functional subset suitable for this particular page.

5)      Subsequent content updates would require steps 2) - 4) be repeated to obtain a new patch.

The benefits:

-          Much simplified server side processing that
- eliminates the need to make complex subsetting decisions
- arguably, much faster server-side processing and response time (creating a subset for known glyph IDs as a breeze compared to codepoints-based calculation of glyph closure)
- eliminates the need to send [potentially significant amount of] redundant data

-          Enabling browsers to
- make font fallback decisions early on, with the very first font load
- using readily available shaping engine to determine glyph IDs and layout, and
- eliminating the implementation complexity associated with determining / optimizing byte-range requests (as described in Myles' proposal)

-          Resolving (to an extent) certain privacy concerns - glyphID-based solution doesn't leak the content of a page to the same extent that codepoint-based solution would - one has to make certain steps to reverse-trace glyph IDs to determine their semantical meaning.

Thought?
Thank you,
Vlad

[1] http://lists.w3.org/Archives/Public/public-webfonts-wg/2019Jul/0018.html
[2] http://lists.w3.org/Archives/Public/public-webfonts-wg/2019Aug/0020.html