Re: Average Font Size in the Simulation

Yeah, I'll re-run the numbers and get percentiles instead of the average.

That's correct Chris, I calculated the size as woff2's because that's what
the baseline of Whole Font uses. This size measure is meant to give context
to the % reductions vs the baseline. Since it might be interesting I'll
generate the size distributions for both the TTF and the WOFF2 version of
the library.

Small correction, neither patch subset or range request use WOFF2, but both
use Brotli compression (via http content encoding, or the patch encoding).
Brotli is responsible for the majority of savings in WOFF2 so this is a
pretty minor distinction. On that note though I actually want to experiment
with using the woff2 glyf table transformations before computing patches in
patch subset. I think that could get us a couple more percent reduction in
transfer sizes.


On Wed, Oct 7, 2020 at 5:28 AM Chris Lilley <chris@w3.org> wrote:

>
> On 2020-10-07 08:30, Myles C. Maxfield wrote:
> >> On Oct 6, 2020, at 6:15 PM, Garret Rieger <grieger@google.com> wrote:
> >>
> >> During the last call there was a question about what the typical font
> size was for each language grouping in the simulation. I gathered up the
> sizes of the fonts used in each language grouping and computed the average
> file size (as a woff2)
> > Are the fonts actually woff2 files?
>
> My understanding is that woff2 of the whole font was the 100% baseline
> against which any savings (or losses!) from PFE were measured. If I have
> that wrong, please correct me.
>
> My understanding is also that for patch subset, the initial font
> download id a woff2 (thus, using Brotli) and that binary patches sent
> subsequently are also Brotli compressed and make use of the compression
> dictionary for the initial font download.
>
> And for glyph byterange, the initial download is a woff2 which is halted
> once the start of the glyf table (r the charstrings part of the CFF
> table) is detected; and that the byteranges specified over HTTP relate
> to the uncompressed font (because HTTP compression is transparent). And
> the byterange downloads do not benefit from the Brotli compression
> dictionary but each one can use (a separate) Brotli compression step (or
> zlib compression step) as determined by the server HTTP setup. Yes?
>
> >> weighted by the number of occurrences of each font within that group.
> Here are the results:
> >>
> >> Latin, Cyrillic, Greek, and Thai: 31 kb
> >> Arabic and Indic: 47 kb
> >> CJK: 1002 kb
> > It would be great if we could get a breakdown with box-and-whiskers
> plots rather than just averages.
> Yes, I think that would be a lot more helpful.
>
> --
> Chris Lilley
> @svgeesus
> Technical Director @ W3C
> W3C Strategy Team, Core Web Design
> W3C Architecture & Technology Team, Core Web & Media
>
>
>