- From: Jonathan Kew <jfkthame@gmail.com>
- Date: Mon, 5 Aug 2019 21:13:53 +0100
- To: public-webfonts-wg@w3.org
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