<chris> a box and whisker plot of the font size distribution

<myles> (chris is asking Garret for ^^^)

<scribe> scribeNick: Persa_Zula

<chris> a graph of "bytes remaining" for the font sizes, especially for CJK fonts where 90% is the bare minimum reduction to make things work

<Garret> Yes I can do both.

<chris> the report is due like yesterday, so needs to be sent today or tomorrow but we can make minor updates after announcing

Review, discuss and collectively approve Evaluation Report

chris: summarizing changes from last week
... "Terminology" section added
... 1.3 "Uneven success" moved from the introduction, and now is understandable after the terminology
... Added "Initial Trials", because we compared it with the Adobe method on CJK fonts, and also repeated with fonts from Monotype
... this is important to compare with the commercial solutions
... reoganized study design section
... defined the different methods of the study
... then explained the cost function

myles: wanted to make sure that we stated that we invented the cost function

chris: yes, and added in tables of the network times
... a graph would help in fonts by language types
... byte savings need to be in the context of how much of the total font is saved
... glyph shaping, showed some mix results
... changed the saturation of green/red coloring (added bold as well)
... for CJK results, added info about how the byte reduction might not be enough
... taken from Garret's doc info on codepoint reduction in patch-subset; does it apply to range-request?

Garret: I _believe_ so but not sure

chris: about the codepoint prediction - do you send extra ones in hopes that it is useful?

myles: no, unless simulation adds it. range-request doesn't do it by itself
... because the font is sorted, it's fairly likely that you need what's inbetween the two characters requested; "accidental prediction".

chris: is the sorting described somewhere in the email list?

myles: can write up a desciption of what it does

<scribe> ACTION: myles to write description of sorting for range-request

<trackbot> Created ACTION-227 - Write description of sorting for range-request [on Myles Maxfield - due 2020-10-19].

chris: CJK section has no red or green coloring in section because conclusion is tough with this set - depends on use case

Garret: because we're using a smart client in both use cases, the smart client can use its knowledge of the network connections to decide which method to use

<jpamental> Sorry all - have to drop off

chris: final conclusion - call to action to standardize

myles: question - about the graph with bytes remaining - what should the x-axis be? methods or network speed?

chris: two graphs, one for range-request and one for patch-subset
... y-axis is network type, x-axis is filesize

myles: bars are horizontal?

chris: yes

Garret: planned on using the same style as the percent reduction graphs; x-axis is the final filesize average

myles: if bars are horizontal, we can add a vertical line of the relative (a stacked graph), total size vs remaining size

chris: then all your data will be in 10% of it if you have a 90% file reduction so you can waste resolution where the data is

myles: can we see what it looks like?

chris: yes

myles: can you send it today, Garret

<scribe> ACTION: garret to send out different styles of percent reduction graphs

<trackbot> Created ACTION-228 - Send out different styles of percent reduction graphs [on Garret Rieger - due 2020-10-19].

myles: we need to call out that range-request doesn't use compression

chris: but if the server has compression, http will apply compression transparently?
... you generate content, server compresses it, client decompresses it, no?
... much like the 2nd stage of woff

Vlad: if you remember woff1 efforts; table-based compression; woff1 didn't materialize that way

myles: not interested in table-based compression; brotoli allows you to have individual blocks; blocks are independent of each other; within an individual table we can download specific parts rather than downloading the whole table

<chris> HTTP Archive Web Almanac for 2019 found 75% of fonts served from a font CDN, 25% from the same host as the content

<chris> https://almanac.httparchive.org/en/2019/fonts#are-fonts-being-hosted-on-the-same-host-or-by-a-different-host

myles: for servers that don't support any type of content compression, they could still see a benefit in range-request method that wouldn't be represented in this eval report
... if there's a description of patch-subet and range-request, there's no set of what is needed for a website author to employ these methods
... we also need to describe what mechanically they'd have to do to make this work

chris: clients, servers, and things inbetween clietns and servers need updated
... if 75% of the fonts come from 10 3rd party hosts, then you just. have to serve just those hosts, right?

myles: yes, but we want to make sure philosophically we can't make a solution that works only for companies that are large enough to hire CDNs

Vlad: woff2 is that solution?

myles: for CJK that is not a solution

Vlad: not clear at this point in time that range-request would solve the problem that woff2 can also not solve

myles: it's better; website owners can make the decision on that point
... clients would have to be updated - mechanism needs to be added - would have to be integrated with CSS specifically

chris: would it? yes, with unicode-range; but for the PFE methods, it's a single font family, initial value could be everything

Garret: client needs some way of knowing that it needs to make a progressive request instead of HTTP request
... needs some way to say this is not just a WOFF2
... always thought it would be something in CSS; maybe it's just a different format in the SRC

chris: we should probably make a proposal on how it would work; but that might be premature

myles: we need to discuss it in this group
... there's a particular loading timeline for a font; websites rely on that to make their page loading experience the way the web author wants; if we mess with that experience neither users nor authors will be served by that

chris: will go through this after this call and make edits by today
... where are we on this report? and when do we announce it to the AC?

RESOLUTION: once these edits are in, we will publish the report

close action-225

<trackbot> Closed action-225.

close action-226

<trackbot> Closed action-226.

<chris> action-228?

<trackbot> action-228 -- Garret Rieger to Send out different styles of percent reduction graphs -- due 2020-10-19 -- OPEN

<trackbot> https://www.w3.org/Fonts/WG/track/actions/228

<chris> action-227?

<trackbot> action-227 -- Myles Maxfield to Write description of sorting for range-request -- due 2020-10-13 -- OPEN

<trackbot> https://www.w3.org/Fonts/WG/track/actions/227

list attendees

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Garrett/Garret/
Default Present: Persa_Zula, Vlad, myles, chris, jpamental, SergeyM, Garret, Ned
Present: Persa_Zula Vlad myles chris jpamental SergeyM Garret Ned
Found ScribeNick: Persa_Zula
Inferring Scribes: Persa_Zula
Found Date: 12 Oct 2020
People with action items: garret myles

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)