W3C

- DRAFT -

Web Fonts Working Group Teleconference

02 Nov 2020

Attendees

Present
Persa_Zula, Vlad, myles, sergeym, Garret, chris
Regrets
Chair
vlad
Scribe
Persa_Zula

Contents


<scribe> scribeNick: Persa_Zula

Set the stage for the next 2 years of activities

Feedback

chris: some Chinese companies have webfonts available and have some subsetting capabilities available that we aren't aware of
... a service called fontplus has publicly available dynamic subsetting for Japanese market
... created new issues for the setup of various setups of fonts in different companies; Korea, Japan, China so we can gather more information

myles and garret: sounds like there is a need for this as other companies are coming up with solutions

chris: other issues logged; httparchive data is becoming available; median webfont size - korea was highest, Chinese was lowest (but maybe because there aren't many fonts)
... data for most used service as well - g fonts highest, even in China

Vlad: did you get any feedback on companies that may want to join this group?

chris: yes, this is main reason to get the report translated

<Vlad> https://www.w3.org/TR/2020/NOTE-PFE-evaluation-20201015/

Next steps for this group

Vlad: decide and agree on the scope of work
... may not all happen in this discussion

myles: natural direction forward; we need to come up with triggering mechanisms; a way for both methods to co-exist; come up with a way for whether patch-subset will use POST or GET; talk to companies foundries to let them know about this work; and publish a specification that describes the methods and implementer to implement them; font maker to do their fonts to use them; what a website would have to do to use them

Garret: useful for us to create a working prototype in a browser; to help figure out decisions for the specification

myles: another piece to this; where we decided to validate our findings in a real-world scenario instead of a simulation

Garret: yes, prototype should unblock that

chris: heard contradictory opinions from folks on whether we can predict whether something can be predicted what is being read - privacy concerns

Garret: the data set from the simulation is real-world; you can use that to do an analysis on this

chris: are they tagged with subject matter?

Garret: no, and there's no way to get back to get back to the original data

chris: we need a subject-tagged corpus and try to extract back to the original subject to see if this a real concern

jpamental: we need to be explicit on the request exchange process works, so people can figure out whether they need to be concerned

myles: https seems necessary
... particular vector is not man in the middle; font server itself - service hosting the fonts is the one of concern
... the extent of the discussion previously was to request a bunch of extra glyphs, but sounds like we need to dive deeper and also get experts to look at it
... language and privacy experts

jpamental: would cybersecurity folks be useful?
... agree we need to look at this asap

Vlad: will those results significantly change the outcome of what we do?

jpamental: Primary concerns are around how much we are fuzzing up the data; perhaps the end-user can also set the level of that fuzzing for the uber-concerned?

Garret: if we deal with the privacy issue by expanding the subset, then the technology solution is still the same

Vlad: certain amount of technical work can be started right now because we have a clear understanding of what it is, not saying that's the only thing we can do, and should start doing

chris: want it to be done in parallel, not after we're done

myles: one step further, not only should we do it in parallel, and we need a section in that specification that describes both the method for how to improve privacy, and also how to control it, and making an informed decision of what to choose

Vlad: need to be clear in those descriptions that privacy issues might affect other languages and scripts in a different way for each one

chris: setting needs to be explicit

Garret: the client implementation might be in charge of how to expose those settings to the user

myles: when you add UI to browser settings, there's a tradeoff for complexity, flexibility, simplicity
... two other parts; 1. whatever triggering mechanism used (in CSS), should be possible when using it to be able to add a hypothetical third...
... one possible triggering mechanism is JS that does logic on behalf on the website (not saying it's a good option); another method where font hosting website does some work up front but not at runtime; but the 3rd is to support a website that does no work and browser tries to download just chunks of fonts

Garret: compressed versions of WOFF is most served style; auto range request can work with TTF fonts, but most fonts are not transfered this way

chris: 75% of fonts are woff2; 12% woff1; small amount for SVG; TTF or OT is almost 0%

myles: SVG fonts were used because older versions of iOS because they were implemented in the browser; seen it on the web because of older versions of iOS

Garret: yes, same here for older iPhone versions

chris: EOT is way down, like 0.001%

Vlad: can we break it down to 3 buckets, what, when and why?

Garret: first thing, get a rough sketch of what we want to standardize. once we have a vision of that, then we can look at the triggering mechanism; privacy should start now
... need to define what supporting both of these methods looks like; before spec work begins

Vlad: good way forward, conceptually, what can be done in parallel if resources are available

chris: we can start this in issues

Garret: will take ownership for the combined PFE method for one system
... we should sit down and write it out and make sure it looks good

chris: an @font-face would be a reasonable way forward for the CSS part?

myles: don't know about that - the supports function - this is a COLR font, if the browser doesn't support it, it will skip that font; if the browser doesn't support streaming we probably don't want to skip it. we need to think about fallback here
... the fallback solution might be 2 src: descriptors in the @font-face block, but we need to think about it

chris: will start an issue on it

call schedule cadence

Garret: weekly or bi-weekly

chris: would rather have more frequent calls and cancel if no agenda

Email about testing WOFF2 in patch-subset

Garret: results show that we might want to include it for at least CJK

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/11/02 17:52:05 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/myles/myles and garret/
Succeeded: s/than others/in a different way for each one/
Succeeded: s/2 source/2 src:/
Default Present: Persa_Zula, Vlad, myles, sergeym, Garret, chris
Present: Persa_Zula Vlad myles sergeym Garret chris
Found ScribeNick: Persa_Zula
Inferring Scribes: Persa_Zula
Found Date: 02 Nov 2020
People with action items: 

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.)


[End of scribe.perl diagnostic output]