Re: Glyph Closure Scaling

> On Aug 6, 2019, at 2:34 AM, Jonathan Kew <jfkthame@gmail.com> wrote:
> 
> On 05/08/2019 22:03, Myles C. Maxfield wrote:
>> 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.
> 
> That's still two separate requests, isn't it? The client needs to make one request to get the font header (which it can assume fits within a predetermined reasonable max size); that will tell it how much it needs to request in order to get everything up to the outlines.

I was envisioning the early request wouldn’t be a range request. Instead, it would be a regular request for the whole file, and the browser would parse the bytes as they arrive, and close the connection (or stop requesting or whatever) when the glyph data is reached inside the file. This only makes sense if the glyph data is all at the end of the file.

This idea is based loosely on how <video> streaming works, so I should investigate how they solve this particular problem. That being said, I don’t think this approach has to work in any one particular way. We can (and even should!) try a bunch of different related strategies and see which one works the best in practice. 

> 
> So there are two complete round-trips to the server *before* it can begin to shape text and determine what glyph ranges it needs to request.
> 
> On a sufficiently low-latency connection that might be fine, but I'm concerned that it could amount to many milliseconds in plenty of real-world cases.
> 
> JK
>

Received on Tuesday, 6 August 2019 16:31:13 UTC