Re: Hybrid approach to PFE

Agreed that a glyph based approach is going to yield a simpler server
implementation, however I'm not sure that this is much of an issue since
the for a codepoint based approach complexity is going to reside entirely
in the subsetter, which there are already good quality open source
implementations available for. In fact, in Chrome the resolution of
codepoints to glyphs is handled by harfbuzz shaping, which is the exact
same code that the harfbuzz subsetter uses to compute the closure.

For the problem of knowing which codepoints are in a font: a codepoint
based approach can be easily supplied with a complete codepoint listing
that the font covers in the first response. I'm pretty close to finishing a
design doc for the protocol for subset and patch and my current iteration
does exactly this. The benefit is the first response also contains glyph
data so you don't need to make a second request to complete rendering of
the initial page. The way I have it working currently is the client first
sends a list of codepoints needed for the particular page (the font may not
cover all of these), in response you get back a font with glyph data for
any codepoints that are covered plus a listing of all codepoints the font
does cover. The browser can then make fallback decisions if needed and
future augmentation requests will be better informed.

As for which approach (glyph id vs codepoint based) is going to ultimately
transfer less data I think we may need to wait for the analysis to answer
that question, there's quite a few variables in play (for example
compression and how much extra data  glyph data a closure transfers vs a
glyph requesting approach) and these depend closely on the specifics of the
fonts, the content of pages, and the order in which pages are loaded.
Ultimately it may be the case that both methods work well in specific cases
and an ideal solution would support either depending on the scripts in use
in the font (for example use codepoints for CJK and glyphs for Arabic).

On Fri, Aug 9, 2019 at 8:40 AM Levantovsky, Vladimir <
Vladimir.Levantovsky@monotype.com> wrote:

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