Re: Hybrid approach to PFE

This is pretty much exactly how the Tachyfont (Google's existing solution)
works (see:
https://docs.google.com/document/d/1AQ2VwiVwF77H2h_nuDHR1A5hRyGlpyIQYpYodMtEz1w/edit).
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.
   - Allow GPOS/GSUB and other tables to be incrementally transferred as
   well (a tachyfont like solution can only incrementally transfer glyph data).
   - 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).
   - 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).
   - 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.

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> 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
>
>
>