Re: Glyph Closure Scaling

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.

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.

JK

Received on Monday, 5 August 2019 20:14:18 UTC