16:58:01 RRSAgent has joined #webfonts 16:58:05 logging to https://www.w3.org/2024/09/24-webfonts-irc 16:58:12 RodS has joined #webfonts 16:58:26 rrsagent, make logs public 16:58:36 Garret has joined #webfonts 16:58:44 present+ 16:58:48 present+ 16:58:54 present+ 16:59:09 Vlad has joined #webfonts 16:59:54 zakim, start meeting 16:59:54 RRSAgent, make logs Public 16:59:55 Skef has joined #webfonts 16:59:56 Meeting: Web Fonts Working Group Teleconference 17:00:03 scribenick: RodS 17:00:15 present+ 17:00:56 Chair: Garret, Vlad 17:01:21 present+ Vlad, Rod Garret, Jimmy, Dwaine, ChrisL 17:01:35 zakim, list attendees 17:01:37 As of this point the attendees have been Vlad, skef, bberning, Garret, sergeym, ChrisL, davelab, Jeff, JH, jpamental, RodS, Jimmy, Dwaine 17:02:41 zakim, list participants 17:02:41 As of this point the attendees have been Vlad, skef, bberning, Garret, sergeym, ChrisL, davelab, Jeff, JH, jpamental, RodS, Jimmy, Dwaine 17:03:17 Garret: feedback from Dominik from Chrome 17:03:32 Garret: various formatting, nits, etc. Won't cover in detail. 17:04:22 Garret: he also suggested merging two sections performance considerations wrt reducing network requests 17:04:30 ChrisL: would prefer to lean into separation 17:04:56 Garret: also had a comment about error handling, lack of detail wrt CSS font loading 17:05:07 Garret: agreed, will firm this up 17:05:39 ChrisL: nuances of exactly when what errors occur need to be firmed up 17:05:51 Garret: also what happens if you apply a bad patch needs elaboration 17:07:00 Garret: there is also some language about woff2 17:07:15 ChrisL: we should also be mroe explicit about woff1 is fine, no further complmication 17:07:44 Skef: we should also define if the initial file is an opentype font compressed however you want or if compression is part of spec. Need to clarify. 17:08:05 Garret: prefer to leave as regular font file and clarify application of woff2. Dropping pure brotli patch will help there. 17:08:21 Garret: suggests encoding considerations might want to move outside spec. Or maybe an appendix? 17:08:42 Rod: https://docs.google.com/document/d/1MAuXOJr7FQevxTg9NhaBOB5Y45Ak9Ad3SRyKDfND8SY/edit?usp=drivesdk is notes from my review 17:09:04 ChrisL: unclear on removal of encoding, having that be a black box seems like a problem 17:09:29 Rod: question was whether it should be in spec or not 17:09:50 ChrisL, Skef: want something in spec, need the practical guidance 17:10:09 Garret: maybe an appendix, we can discuss that later 17:10:16 sergeym has joined #webfonts 17:10:58 https://w3c.github.io/IFT/Overview.html#abstract 17:11:59 Rod: tl;dr room for an editorial pass to make easier to read. Don't suggest reviewing step by step here, just perhaps one of the editors could review and see if they deem any changes to make sense. 17:12:29 Garret: volunteers to review Rod's doc and see if any changes make sense 17:12:41 ChrisL: also enjoys reviewing docs and making edits 17:14:17 Rod: filed as https://github.com/w3c/IFT/issues/213 17:14:59 ChrisL: this format defines 3 patch formats each for it's own scenarios immediately before defining 4 :) 17:15:16 Garret: 4 format #s but 2 are the same patch type ... this might merit clarification 17:17:14 Garret: two brotli patches. Full font and per table. In theory whole font is mroe efficient because it spans tables but it's incompatible with woff2 due to woff2 not having stable binary output. 17:17:37 Skef: and it's impractical to mix with glyph-keyed patches 17:17:56 Garret: leaves us with a very niche, marginally better, patch format. Suggest dropping. 17:18:06 ChrisL: seems like a footgun 17:18:42 Garret: yes, can non-obviously not work or fail in the face of a new binary because woff2 doesn't guarrantee sthe output 17:18:59 (clarification the patch references the decoded file) 17:19:29 Rod: because you want to refer to the decoded data, that's the reused thing 17:19:45 Agreement to remove the full file brotli patch 17:20:29 https://github.com/w3c/IFT/issues/214, high level description left to be elaborated later 17:20:50 Skef: perhaps we can now change the Per Table Brotli nomenclature to better reflect what it does over how it does it 17:21:08 Skef: something complimentary to Glyph Keyed 17:21:51 (updated 214 to note ^) 17:22:07 Garret: encoding considerations is entirely non-normative, it's all up to you! 17:22:22 (https://w3c.github.io/IFT/Overview.html#encoding-considerations leads with not normative) 17:22:45 Garret: so the question is does this deserve to be top-level or should it be out-spec or in an appendix to make it's auxiliary nature more obvious 17:23:14 Garret: brotli has an encoding considerations akin to ours 17:23:23 Rod: prefer in spec, whether appendix or otherwise 17:23:39 Skef: fan of how 7 flows into 7.1 17:24:04 Skef: 7.1 explains how to concretely meet the normative requirements of 7 17:24:14 ChrisL: would like more sub-headings for 7 17:24:33 ChrisL: foundries, rights owners, breaking fonts if you like, etc ... these merit breaking apart 17:25:52 Vlad: normative followed by non-normative section works 17:25:55 (nobody seems to object) 17:26:29 Skef: prefer this way unless it's going to produce a lot of pushback, if so we could move to an appendix 17:26:57 Conclusion: leave it in 7 17:27:40 Vlad: other specs tend to leave encoding nuances non-normative to leave it open for implementations to compete there. Make an exceptionally fast or efficient or w/e encoder as long as it decodes properly. 17:28:05 Skef: Privacy Considerations and Security Considerations ... are they part of 7.1? Why aren't they #'d? 17:28:13 ChrisL: specs often don't, but we could 17:28:24 Skef: if not numbered ... can we more clearly divide 17:28:48 RodS: can we just number them unless there is some specific reason to do otherwise? 17:29:07 ChrisL, Garret: no specific objection, we shall go forth and # them 17:29:33 Garret: (but won't # appendix etc) 17:32:22 https://github.com/w3c/IFT/pull/215 17:32:30 Skef: in the sections discussing interpreting formats, e.g. "Interpreting Format 1" suggest adding more words to specify what this is for. This is how to understand, not necessarily the exact thing you'd write. 17:33:22 Garret: next up some sections discussing extensions 17:33:28 Vlad: COFFEE BREAK! 17:33:47 ChrisL: privacy review surfaced an issue about minimum patch sizes, only issue to come out 18:19:10 jfkthame__ has joined #webfonts 18:37:20 sergeym has joined #webfonts 18:56:11 Skef2 has joined #webfonts 18:57:01 zakim, list attendees 18:57:01 As of this point the attendees have been Vlad, skef, bberning, Garret, sergeym, ChrisL, davelab, Jeff, JH, jpamental, RodS, Jimmy, Dwaine 18:57:32 leaverou2 has joined #webfonts 18:58:09 We have a power outage in Anaheim and are continuing the meeting offline 19:55:40 Skef2 has joined #webfonts 19:56:05 Zakim, show attendees 19:56:05 I don't understand 'show attendees', Skef2 19:56:21 Zakim, list attendees 19:56:21 As of this point the attendees have been Vlad, skef, bberning, Garret, sergeym, ChrisL, davelab, Jeff, JH, jpamental, RodS, Jimmy, Dwaine 20:49:19 jfkthame__ has joined #webfonts 21:15:15 RodS has joined #webfonts 21:24:22 (pause for power outage and lunch) 21:24:39 Garret: other than editorial pass, any other spec changes people are anxious to have in? 21:24:46 Skef: filed issues for any I had 21:25:56 Skef has joined #webfonts 21:26:03 present+ 21:26:24 present+ 21:26:27 jfkthame__ has joined #webfonts 21:27:51 (review of github issues) 21:28:21 Garret: https://github.com/w3c/IFT/issues/192 Possible "all other codepoints" semantic, I proposed a change, did people review? 21:29:02 Skef: seems plausible, suggests an encoder issue we might want to discuss. 21:30:13 Skef: in switching from patch/subset to the current approach we seem to have gained an assumption that we're going to segment the font and then produce permutations 21:30:24 Skef: say you segmented roughly on scripts (latin, greek, etc) 21:31:28 Skef: say you looked at the documents in the world you'd find many with one script. Fewer with more than one script. So often you'd want two levels and then everything else. So it's a waste to segment deeper. 21:31:50 Skef: when developing the encoder we'll want control over depth 21:32:16 Garret: we do have a note about max depth under "Managing the number of patches" 21:32:49 (in https://w3c.github.io/IFT/Overview.html#encoding-considerations) 21:34:45 Skef: say you segment into 7 scripts and one catch-all. Then you have add-a-script patches for each script. So you limit max round trips. 21:35:08 Skef: believe use of an everything-else bucket will be common 21:35:23 Skef: so we should be sure this can be done efficiently 21:35:47 Skef: for format 1 only 21:36:16 Garret: to specify everything else you have to encode the full set of what's available total 21:36:43 (discussion of cmap being the additional source for what's supported) 21:37:25 Garret: https://github.com/w3c/IFT/issues/192#issuecomment-2313736461 proposes the lean-on-cmap bit, will draft related changes 21:37:55 Skef: where are we at for https://github.com/w3c/IFT/issues/201 Considerations for "desiccated" initial font files 21:38:02 Garret: I have some spec edits to make 21:39:28 Skef: if the client wants to make determinations about the font and doesn't have adequate information, e.g. codepoints, how do you proceed? 21:39:47 Skef: say you want the psname from the font 21:39:59 (postscript name from name table) 21:40:17 Garret: we once talked about explicit font not initialized 21:40:37 Skef: user will need to pay to load some patch. Just wondering how to select a patch absent a set of codepoints. 21:41:27 Skef: assuming any patch you load will have the data needed. You want to pick a small one. 21:41:42 Garret: we'd be making assumptions about the encoder, intent is the client follows the algorithm ... but this case is outside that. 21:42:25 (discussion of whether or not trusting that encoder will patch basic global tables into place if you load any patch is reasonable) 21:42:40 Garret: not sure the client can assume this 21:43:18 Skef: the font won't work if not, violates a "should" wrt the font working 21:43:28 Garret: so you'd try to grab whatever looks smallest 21:44:18 Skef: would prefer to say you should activate a codepoint 21:45:54 Garret: will add advice, suggesting choose a codepoint and light it up by following the algorithm 21:47:17 Skef: regarding encoding, we can say there's an uncompressed initial font file. Lossless compression just works. WOFF2 has additional considerations. 21:47:36 Garret: notably the woff2 glyf transform does not have stable output 21:48:00 Garret: we should note that you decompress prior to operating on it 21:48:11 Skef: an IFT font is an OpenType font with specific extra tables 21:49:16 Garret: https://github.com/w3c/IFT/issues/125 Client conformance tests is next, that has it's own agenda item so maybe we can switch to that 21:49:41 Garret: update on https://github.com/w3c/IFT/issues/101 Shared Brotli, as of August it looks like this spec is moving again 21:50:14 Garret: so will continue to watch, worst case we'll copy the spec text inline. I'll post an update to the issue. 21:50:37 Garret: next topic, client conformance tests 21:51:32 Vlad: two buckets for entries. 1) non-normative parts of spec we won't test need to have record, what are we not testing and why. 2) everything we do want to test to ensure we know how to test. 21:52:00 Vlad: based on woff2 conformance testing this may be an issue, conformance testing development is time consuming 21:53:00 Skef: suppose you have a directory with a hierarchy of pages you load in sequence. One loads full font, one loads incremental, rendering should be the same at every step. 21:53:29 Skef: doesn't that test almost everything? 21:53:51 Garret: we need a test for every MUST, and some of them are negative. The browser must reject this font. 21:54:05 Skef: so not much infrastructure 21:54:18 Garret: right, woff2 has relatively clear sets of static files 21:54:51 Vlad: woff2 has a bunch of files damaged in various ways. The test is designed to load and display P/F for pass/fail. 21:56:21 Vlad: so we had a bunch of minimal bespoke fonts with two glyphs and almost nothing else 21:56:50 Garret: our MUST statements are almost all error conditions. There is also an implied requirement for tests for algorithms. 21:57:21 Garret: we don't require rendering identically, just that you should end up at some known end state. 21:57:52 Skef: I was thinking things could be described in terms of behavior 21:58:27 Garret: most client tests likely around applying a patch. We'll have to design tests to expose that in client-side observable behavior. We want black-box tests, look at the doc and get a clear answer. 21:59:25 (discussion of observation of expected result of patch application) 21:59:57 Garret: I volunteer as tribute! 22:00:50 Vlad: we want tests with a very simple pass/fail check. The people running the tests will be implementers. 22:01:30 Garret: we can start marking up test refs 22:01:46 Vlad: approach for woff2 allowed linking to specific tests which was useful 22:02:16 Garret: next step is to markup the spec. Not sure about timing of actually building tests, perhaps not until we have a basic Chrome implementation. 22:03:22 Garret: in addition to client conformance tests we might need to discuss encoder conformance tests because we have at least one normative statement there 22:04:18 Skef: are we going to do anything about https://github.com/w3c/IFT/issues/109 It'd be interesting to discuss markup discoverability 22:04:27 Garret: would ideally like to discuss with Yoav 22:04:55 Skef: seems to imply something more sophisticated than just pick the highest priority source you support 22:05:30 Garret: this issue is from the patch/subset days when client could over-request, but now you just obey what the encoder tells you. The issue is probably irrelevant now. 22:06:19 Garret: I'll try to catch Yoav at TPAC, failing that I'll close with a comment. 22:06:43 Garret: final topic, how to build a high quality encoder. Not really a spec issue but interesting wrt deployment for real. 22:07:52 Skef: two aspects of question, neither for spec. 1) parameterization of what encoder will do. By default general, based on how docs and fonts tend to work here are some ideas about organization. Then able to tweak, influence results. 22:08:10 Skef: 2) how you actually build the encoder, how does it work, what is it doing 22:08:41 Skef: not sure what we'd say about per-table patches in terms of configuration data 22:09:15 Garret: in the case of a general purpose encoder for the web I think the main tuning knob is how many files you want. More files will permit higher granularity. 22:09:40 Garret: e.g. no more than 10k patches, my environment doesn't like large file counts 22:10:20 Garret: can give additional knobs, e.g. spend most on glyph key patches 22:11:30 Skef: if I'm doing per-table patches and I have a budget for #patches then the more finely I cut things the more round trips I have 22:11:51 Garret: I imagine trying to ensure things are no more than one round trip away 22:12:13 Garret: e.g. a patch for each subset, a patch for each pair, etc 22:13:06 Skef: if the knob includes the width of patch the narrower the deeper the graph will be. Split latin in half, 2 patches just for latin, etc. 22:13:38 Garret: want it as close as possible to Just Works 22:15:24 Skef: a script might be a good split point so the input data needs to tell the encoder what a script is. Maybe we have core script, extended script for each script. Some scripts would default to separate encoding, others segment per-glyph but not per-table. 22:16:44 Skef: for CJK the division between core and extra might be frequency based. Per-table patch for this part, and then the rest. So you have config data about core vs data cutoff for per-table vs not. 22:17:13 Skef: by default I might not segment a script beyond those two buckets 22:18:22 Garret: a file budget enables reasoning about depth in per-table patching 22:19:39 Skef: consider per-table and glyph-keyed separately. Both require tuning. One way to express is target # patches. Another way is depth for per-table. On glyph-keyed side you could give a target # patches. 22:20:26 Skef: another tunable might be patch size, another might be #glyphs in patch 22:21:46 Garret: #files is based on notion that a server, say a cdn, might not want vast #s of files. That's the key limit the user has. 22:23:57 Skef: speaking of encoding, what about emoji 22:24:59 Skef: early on we talked about ligatures and I pushed back 22:25:48 Rod: icon fonts and emoji both have ligature problems 22:27:54 Skef: emoji will be more separable than icon names 22:28:59 Skef: in a color language font things may separate relatively well, most shapes correspond to individual characters 22:29:40 Skef: for emoji, the other aspect is likely more complex reuse of shapes 22:30:16 Skef: with enough reuse you might want to grow the base font 22:30:55 Skef: what you merge is different in an emoji font than a language font 22:31:15 Skef: you might want relatively few codepoints in a glyph keyed patch 22:31:29 Rod: can confirm there are a small set of highly used emoji 22:33:05 Skef: colorized things would use the same base outlines 22:33:58 Skef: if someone does shape coalescing that's a problem 22:35:41 (speculation about how emoji fit together) 22:35:58 RodS: for reference, https://unicode.org/Public/emoji/16.0/emoji-test.txt is the set you are supposed to handle 22:39:05 Skef: if designers reuse outlines heavily across concepts the grouping is non-obvious, we have to decide whether to group or duplicate 22:39:20 Garret: format 1 requires disjointness but format 2 doesn't 22:40:16 Garret: widely duplicated things can thus be de-duplicated in format 2, it doesn't have the format 1 requirement of 1 glyph => 1 bin 22:42:42 Garret: in format 2 if A maps to multiple patches all of them ultimately get loaded 22:43:57 (discussion of how patch mapping updates in the face of patch format 2) 22:47:47 Skef: I still find the interaction of encoding options and patch application a bit opaque. 22:48:28 Garret: the encoding reasoning differs because of how the different patch types can alter the font 22:49:19 Skef: for variable fonts the spec really only explains how to decode. How an encoder should build the data structures there's no guidance at all. 22:50:04 Skef: in our spec we haven't really explained how to write an encoder. We've specified the decoder and left the encoder as an exercise. 22:51:47 Garret: once formats are in common representation processing differs only in order, which ones go first 22:52:18 q+ 22:52:40 Skef: why when using per-table patches does it load only one vs all for glyph keyed 22:53:07 Garret: algorithm says to load one by one but it is intended that a client can make speculative loads for probable future patches 22:54:03 Does anyone need a zoom link for the meeting? 22:54:37 Garret has joined #webfonts 22:54:39 Vlad has joined #webfonts 22:54:44 leaverou2, question? 22:55:03 oops sorry, wrong room 22:55:51 RodS: do we define how to build a basic encoder? 22:56:05 Garret: I have pseudo-code for the most basic possible per-table implementation 22:56:40 Garret: it's relatively easy to do pure glyph-keyed and pure per-table, mixed is trickier 22:57:20 Skef: we define things in terms of a subsetter, which is complex, but we can elide that 22:58:02 Garret: I have a simple mixed-type implementation so it's definitely possible 22:58:54 Skef: I worry that in the way we describe things we've over-optimized for compactness and unification vs comprehensibility. Some sections are hard to understand. 23:00:25 (meaning compactness of spec text) 23:01:00 Skef: we could switch to more of how this is how per-table works, this is how glyph-keyed works 23:01:26 Garret: it is possible to duplicate the wording 23:02:42 Garret: but the current wording does reflect how an exploratory implementation went quite closely 23:04:30 (additional discussion of how only client [decoder] is specified, encoder is less clear ... which is arguably by design, encoding is left open to permit ongoing innovation) 23:05:33 Garret: we could have pseudo-code for pure per-table, pure glyph-keyed, *and* how to combine 23:07:38 Skef: still have questions like where does the fi ligature go 23:07:55 Garret: I'll have to think about it, whether we can come up with a terse correct description 23:08:45 Skef: consider solving correctness using the abstraction of static subsetting, that's what mine does. Can we describe what mine does tersely? 23:09:09 Garret: I need to try it 23:09:29 Skef: my implementation puts complicated things into the base font 23:09:50 Skef: I think you are saying merge wherever there is an interaction 23:10:14 Garret: the spec pseudocode needs to be usable 23:12:00 Garret: we could add an informal description to the apply a patch section 23:12:08 RodS: how to encode is the hard part 23:12:17 Skef: perhaps concrete examples? - OpenType has some of this and it's useful 23:13:42 https://github.com/w3c/IFT/issues/216 for concrete example 23:23:30 (side discussion of encoders and Rust) 23:23:51 VICTORY? 23:31:32 Garret has joined #webfonts 23:38:25 Summary of discussion about privacy issue (https://github.com/w3c/IFT/issues/207) while room was offline: 23:38:25 - Just enforcing minimum group sizes on the patches isn't doesn't really add anything as it's possible to construct patches that work around this while still allowing for single character level granularity. 23:38:25 - Single character granularity font loading is already possible via unicode range. Functionally IFT works quite similar to unicode range and so has the very similar privacy characteristics. 23:38:25 - We should document in the spec that including third party resources in a site is implying a level of trust in that resources (eg. like including third party javascript or css). 23:38:27 - If we do want something like minimum group sizes as part of patch subset we'd want to to the codepoint grouping prior to executing the patch subset extension algorithm. That potentially has performance implications but may be able to be written in a way that doesn't affect performance if the font is already well formed (disjoint groupings over a 23:38:27 minimum size).