Re: Glyph Closure Scaling

Here’s the data from Google Fonts:







Looks a bit more difficult than the Windows fonts.

NTR-Regular.ttf
Telugu
78.736248482
Lohit-Bengali.ttf
Bengali
78.831622569
TenaliRamakrishna-Regular.ttf
Telugu, Latin
81.910529391
Peddana-Regular.ttf
Telugu, Latin
82.017367
Ramaraja-Regular.ttf
Telugu, Latin
82.060643793
Ponnala-Regular.ttf
Telugu
82.925248156
Sitara-Regular.ttf
Devanagari, Latin
83.176943573
Sitara-Bold.ttf
Devanagari, Latin
83.176943573
Sitara-BoldItalic.ttf
Devanagari, Latin
83.186576710
Sitara-Italic.ttf
Devanagari, Latin
83.186576710
Amiri-Italic.ttf
Arabic
83.235126624
Amiri-BoldItalic.ttf
Arabic
83.304386938
Amiri-Regular.ttf
Arabic
83.363365799
Amiri-Bold.ttf
Arabic
83.39951432
SreeKrushnadevaraya-Regular.ttf
Telugu
85.420147454
Suranna-Regular.ttf
Telugu
85.4847986935
Taprom.ttf
Khmer
85.498475514
Angkor-Regular.ttf
Khmer
85.498475514
Timmana-Regular.ttf
Telugu
85.7927372355
Chathura-ExtraBold.ttf
Telugu, Latin
86.099921648
Chathura-Regular.ttf
Telugu, Latin
86.099921648
Chathura-Bold.ttf
Telugu, Latin
86.099921648
Chathura-Thin.ttf
Telugu, Latin
86.099921648
Chathura-Light.ttf
Telugu, Latin
86.099921648
Bokor-Regular.ttf
Khmer
86.153956081
Moul.ttf
Khmer
86.153956081
Siemreap.ttf
Khmer
86.153956081
Dangrek.ttf
Khmer
86.153956081
Metal.ttf
Khmer
86.153956081
Moulpali.ttf
Khmer
86.153956081
Content-Bold.ttf
Khmer
86.153956081
Content-Regular.ttf
Khmer
86.153956081
Freehand.ttf
Khmer
86.153956081
Siemreap.ttf
Khmer
86.153956081
Koulen.ttf
Khmer
86.153956081
Preahvihear.ttf
Khmer
86.272334086
Bayon-Regular.ttf
Khmer
86.272334086
Chenla.ttf
Khmer
86.272334086
OdorMeanChey.ttf
Khmer
86.272334086
Mallanna-Regular.ttf
Telugu
86.441653183
Mandali-Regular.ttf
Telugu
86.442915173
Dhurjati-Regular.ttf
Telugu
86.442915173
Ramabhadra-Regular.ttf
Telugu
86.443724933

> On Aug 6, 2019, at 11:58 AM, Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com> wrote:
> 
> For a glyphID-based model - the first request could simply be the "whole font file" with glyph data zeroed out (which compresses to almost nothing). The subsequent request would patch that with the glyphs that are actually in use.
> 
> -----Original Message-----
> From: mmaxfield@apple.com <mmaxfield@apple.com> 
> Sent: Tuesday, August 6, 2019 12:31 PM
> To: Jonathan Kew <jfkthame@gmail.com>
> Cc: public-webfonts-wg@w3.org
> Subject: 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
>> 
> 
>