Re: Glyph Closure Scaling

> On Aug 5, 2019, at 1:13 PM, Jonathan Kew <jfkthame@gmail.com> wrote:
> 
> On 05/08/2019 19:11, Myles C. Maxfield wrote:
>> So, we’re trying to decide whether our solution should operate on code points or glyph IDs. The two models are:
>> A) The client sends a set of code points to the server, and the server replies with the glyph closure of those code points. This has the drawback that the server may have to send tons of unnecessary glyphs to the client
>> B) The client sends an early request to the server to get shaping information, and then sends additional requests to the server for glyphs. This has the drawback that every font requires an extra round trip to the server before the client can even begin to start requesting glyphs. The benefit is that no unnecessary glyphs would be sent to the client.
>> The range-request option already has to send an early request to the server (to get the table of contents), so Option B sounds clearly better there.
> 
> I'm not sure B does sound better... in that scenario, presumably the client has to first send a request for the TOC, then a request for the shaping information, and then a request for the glyphs. So it requires *three* sequential request/response round-trips before it's ready to render anything.

Yeah, this is probably worth clarifying. I was envisioning the range request model would send an early request for everything in the font other than the outlines. Percentage-wise, this works great for big fonts.

Here’s a graph of the table sizes in CJK fonts in the Google Fonts corpus:


> 
> A codepoint-based "smart server" should be able to give the client a usable font in response to a *single* request for a set of code points.
> 
> My intuition (yes, that's highly non-scientific!) says that keeping the number of separate (and non-parallelizable) requests down is going to be more important than achieving an absolute minimum number of glyphs transferred. Otherwise we're at risk of ending up with situations where the per-request overhead kills any performance gains we were hoping to gain by subsetting.

Yes, absolutely.

> 
> JK
>