RE: Hybrid approach to PFE

On Thursday, August 8, 2019 5:38 PM Garret Rieger wrote:

This is pretty much exactly how the Tachyfont (Google's existing solution) works (see: https://docs.google.com/document/d/1AQ2VwiVwF77H2h_nuDHR1A5hRyGlpyIQYpYodMtEz1w/edit).

Yes, there are definitely similarities between what I proposed and all existing approached (hence a “hybrid” approach). However, modifying the Tachyfont approach with certain elements of binary patch/subset approach offers additional benefits:

-          No need for clients to manipulate with outline data, it happens automatically when the new patch is applied;

-          No need to preprocess fonts, no sophisticated processing required on either server or client side, and no need “to tune bytes table by table”;

-          Whatever logic is needed for a successful / optimal solution would still reside server side (simplified client implementations), clients only need to ask for glyph IDs that were determined by the shaping/layout engine.

The main reasons we're advocating for the patch/subset approach instead of a Tachyfont like approach is:
·       Eliminate the need to download the layout and codepoint coverage information separately.
From what I gathered as a result of our discussion so far, this could be both good and bad (see Jonathan’s email<http://lists.w3.org/Archives/Public/public-webfonts-wg/2019Aug/0015.html> on this subject).
·       Allow GPOS/GSUB and other tables to be incrementally transferred as well (a tachyfont like solution can only incrementally transfer glyph data).
Again, this is a tradeoff we’d need to make between two different approaches – either

-          Hybrid approach: provide the client with full shaping/layout/coverage data, and then patch that based on the requested set of glyph IDs with specific, page-optimized glyph data subset (so, two requests are needed to complete the initial font load; with minimal complexity and data size for subsequent requests), or

-          Binary patch: subset GPOS/GSUB/coverage data based on the set of requested codepoints, but have to calculate glyph closure and include potentially significant amount of redundant glyph data (we’d still keep a client in the dark as to what is not covered by the font, the initial font load is completed in a single request, but have to repeat the same processing for all subsequent requests).
·       Inability to allow for patched version upgrades (ie. new version of the font is released, with subset and patch you can just patch the clients existing font to get them onto a new version).
I don’t see why the same result cannot be accomplished with the hybrid approach that uses binary patch for updates.
·       Similar to the HTTP range approach this it's hard to effectively apply compression (for example if glyph outlines contain redundant data those won't get compressed if the glyphs are transferred in separate requests).
I am not sure how to quantify this. From prior experience with WOFF2, most of the glyph data redundancies are contained within a single glyph structure and can be effectively minimized. However, with hybrid approach the result would be drastically different compared to HTTP range approach since multiple byte-ranges will be processed and compressed at the same time to produce a single binary patch.
·       Also I have a feeling that browser implementation of a client will be easier if we're hooking in font enrichments before shaping happens, since that's already supported with things like unicode range.
Again, the main tradeoff here is calculating glyph closure with potentially significant processing complexity and redundancy in output data vs. very simple glyphID-based table subset where you don’t need to guess anything – if client asks for glyphs X, Y and Z this is what it gets, no questions asked.
Thank you,
Vlad

That said, we should definitely plan to test a hybrid/tachyfont like approach alongside the other two proposals in the analysis.


On Thu, Aug 8, 2019 at 1:10 PM Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com<mailto:Vladimir.Levantovsky@monotype.com>> wrote:
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