W3C

- DRAFT -

Web Fonts Working Group Teleconference

28 Feb 2019

Attendees

Present
Vlad, KenLundeADBE, Garret, PersaZulaADBE, jpamental, myles, chris, myles_, ChristopherChapman, sergeym
Regrets
Chair
Vlad
Scribe
chris

Contents


<Vlad> Any volunteers for scribing today?

<Vlad> We'll wait for couple more minutes

<zula> Dialing in... WebEx is being weird

<scribe> scribenick: chris

<jpamental> Sorry - in the car so might have connectivity problems

<myles_> having audio problems, let me reconnect

<myles_> i can scribe if no one else wants to

PersaZulaADBE: our dynamic subsetting is JS in browser, included by customer from our code, specific tothe fonts they chose
... has links to fonts we have subsets for
... as page is modified, sends requests, bitmap of font map, send augmentation instruction to update font in memory, then swapped into current page

<scribe> ... new augmentation request on each page cotent change

UNKNOWN_SPEAKER: only used for CJK fonts, others use static subset eg for Latin

Vlad: initial subset is a separate resource or combined into one package

PersaZulaADBE: js is the subscript file people include. We do update the font resources as requests happen

Vlad: linked via CSS, or from JS?

PersaZulaADBE: linked via css injected in page by JS

Vlad: you said it is like a binary patch?

PersaZulaADBE: send on which unicode items to move, write, overwrite. Not a binary patch but a set of instructions, compressed

ChristopherChapman: (scribe missed)

The JS is doing what we would like the browser to do natively, modfying what the browser is storing in cache or in memory, then swapping it in to avoid a repaint

Vlad: what data does the js receive?

ChristopherChapman: overwrite, insert in memory

myles: what is the input to the diff algorithm?

PersaZulaADBE: not sure

ChristopherChapman: you know what you had before and what you need, so can work out the diff

PersaZulaADBE: sometimes we have more glyphs than are actually needed, not sure of specifics

myles_: there are commn subsetting algorithms to remove parts of a font not needed for a set of unicode codepoints

ChristopherChapman: we are subsetting GSUB and GPOS in response, if that is what you are asking

myles_: using a library or custom code?

ChristopherChapman: in-house code

myles_: as new text is added to the page is it continually scanned?

PersaZulaADBE: yes
... and we avoid FOUT flashes

myles_: there is some window of time where it is styled in the wrong font, right?

PersaZulaADBE: yes

myles_: was that a big problem for you, or was it not a big deal?

PersaZulaADBE: few complaints, except internally in an Adobe app (chatroom-like) ith fast, localized updates in CJK
... issue because of the speed of updates
... normal web use, few complaints so far but they have few other choices :)

<KenLundeADBE> This page, which references several 65,535-glyph fonts, makes extensive use of dynamic augmentation → https://source.typekit.com/source-han-serif/

KenLundeADBE: these fonts have 64k glyphs, used language tagging to handle diff langs, multiple weights

Vlad: in Bram's write up he said initial subset is base64 data. same for the incremental updates too?
... so should not take too long. My slides from 2 weeks ago also showed a base64 encoded font, 10-20ms frame, very short flash

PersaZulaADBE: yes, updated in base64 also

myles_: webkit team spends a herculean effort to avoid flashes

Vlad: uses lots of different tricks
... multiple ways to avoid flashes
... depending on content and font size. No one size fits all

jason: reference to flashing is avoiding absence of font at all. creating new resource before removing the old one

PersaZulaADBE: yes, even if the chatroom app it really helps. new chars never seen before is a flip to maybe a notdef then the proper glyph

Chris: notdef or fallback?

PersaZulaADBE: depends on the application

jason: depends on font-display property too

myles_: hard question

PersaZulaADBE: our solution does depend on font-display property

myles_: lets compare and contrast the adobe and google solutions

Garret: biggest diff is that ours doesnt use custom code for subsetting. otherwise doing a before-after diff

<Vlad> It seems like my audio got cut off

Garret: ours relies on existing tolls, no custom logic. easy to add new tables in the subsetter for instance

ChristopherChapman: lets be clear which project we are using. adobe is working on fasterhorse with google, our old one is skytype

Garret: relying on an existing patching alg likely gives a smaller result. Brotli patchmode uses a lot of great tech to make small patches
... any other comments on difference between fasterhorse and skytype?

myles_: any performance metrics?

ChristopherChapman: fasterhorse cant do everything skytype can do , so hard to do comparisons

myles_: skytype compared to staic subsets?

PersaZulaADBE: not to hand but can bring that data to another meeting

myles_: interested in methodology too, what was tested and why

PersaZulaADBE: person responsible is no longer with us, was not involved at the time, but will look

jason: also worth calling out the ideas and use cases from Bram's doc. Ideally we should not need JS so it can be called by a regular CSS link to an asset

Vlad: in the ideas and use cases, the css-only solution was not clear

PersaZulaADBE: a lot of our customers don't want to add JS. They want a css include even, more control over the css
... some people think that JS in a page makes it heavy so we want a lighter, CSS only solution. They just link to a CSS resource we provide

KenLundeADBE: the JS requirement, it is huge to not need that, teams are more willing if they don't have to add a lot of JS beyon just a font-face observer, stuff like that
... webfonts should work without JS

<ChristopherChapman> That was jpamental, not KenLundeADBE.

Vlad: consistent with what we discussed, we want something that can be natively implemented
... prototyped in JS of course
... any other details that we haven't touched on yet?

PersaZulaADBE: don't think so. I'm familiar so hard to see what is unclear. Sounds like group understands it well.

Vlad: specific mention of older browsers, not sure how strongly we want to do that. Safe bet that older browsers won't support it

myles_: js polyfills and feature detection is the usual way to solve that

PersaZulaADBE: yes, a polyfil fallback is needed

Garret: sending the full font is another fallback option
... should compare that to the polyfill, js can be low in older browsers too

myles_: i'm interested in a new file format as there are fewer browsers than servers

Vlad: by new format, you mean a font data format for transfer? because woff2 seems to be already there.

myles_: I mean a format conducive to streaming, not random reads and writes

Vlad: woff2 binary patch is conducive to streaming

myles_: but most servers support byterange streaming, no need for new RPC endpoints

Vlad: not sure, covers many data tables
... in scope for charter?

Chris: yes

myles_: not married to the idea, just want to investigate it

jason: sidesteps issue with older browsers. easier to work with millions of different apache versions etc
... big concern is th server component, new apache plugin, etc

Vlad: want to have a solution, in a reasonable timeframe, first stage is re-using exting functionality and then, if that is usable, works in existing browsers, tackle the better file format

myles_: no, these are two solutions to the same problem. Need to evaluate them at the start. Willing to do this investigation

Vlad: need to consider the time and resources

jason: sense of the timeframe needed to evaluate this?

myles_: a few weeks, not a few months
... this is the point of my success criteria, already started. Need to agree on what we are trying to measure

Vlad: ok so we covered the first two items in the agenda. Any other questions on the solution described by Adone, or their use cases and solutions?
... myles, action item to get back to group with proposal on font streaing?

myles_: absolutely

<scribe> ACTION: myles to investigate and report back on different solutions to progressive font enrichment

<trackbot> Created ACTION-206 - Investigate and report back on different solutions to progressive font enrichment [on Myles Maxfield - due 2019-03-07].

jason: coming together in these docs, a description of what the solutions hould include and the success criteria, performance metrics. Feens like we should get those all in one place

chris: (explains evaluation report goals)

Vlad: yes, that is our first deliverable per charter
... jason did you mean a place for discussion or a place for the results?

jason: both
... file in a githb repo

chris: (explains bikeshed, gh issues, pull requests etc)

Vlad: next meeting once we have more to discuss, will cancel next cll unless there is something of substance to discuss
... sent a poll for f2f meeting, AtypI and TPAC, please choose which. Both in Japan in September, 2 weeks apart
... please fill in the poll

https://www.w3.org/2002/09/wbs/44556/WebFontsWG-Sep2019F2F/

Vlad: so far, prefeence seems to be AtypI (as with previous years)

myles_: probably won't make AtypI
... failing which a call-in would be great

Jason: ATypI board is happy to accomodate the WG, would welcome a meeting

Vlad: Fonts WG has appreciated past support from ATypI for meetings

<KenLundeADBE> In case ATypI cannot host the meeting the day before the conference, I may be able to host it at Adobe's office in Tokyo, which is one stop from Shinagawa station.

Vlad: we have met twice at TPAC, all other years at ATypI

(adjourned)

<scribe> chair: vlad

<myles_> Thanks chris for minuting!!!

Summary of Action Items

[NEW] ACTION: myles to investigate and report back on different solutions to progressive font enrichment
 

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/02/28 17:58:38 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/sae/same/
Succeeded: s/horse/horse with google/
Succeeded: s/tams/teams/
Succeeded: s/theyse/these/
Succeeded: s/weeks, not months/a few weeks, not a few months/
Succeeded: s/oll/poll/
Succeeded: s/filing/failing/
Succeeded: s/TypI/ATypI/
Present: Vlad KenLundeADBE Garret PersaZulaADBE jpamental myles chris myles_ ChristopherChapman sergeym
Found ScribeNick: chris
Inferring Scribes: chris

WARNING: No "Topic:" lines found.

Found Date: 28 Feb 2019
People with action items: myles

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


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]