16:59:53 RRSAgent has joined #webfonts 16:59:58 logging to https://www.w3.org/2023/02/21-webfonts-irc 17:00:08 Zakim has joined #webfonts 17:00:18 zakim, start meeting 17:00:18 RRSAgent, make logs Public 17:00:20 Meeting: Web Fonts Working Group Teleconference 17:01:58 present+ 17:03:45 present+ 17:09:22 Garret has joined #webfonts 17:09:26 present+ 17:10:26 Vlad: topic 1. checksums 17:10:39 Skef: I've been looking at client side stuff and working through the implications. 17:10:42 scribenick: Garret 17:10:49 Skef: reminded of my general checksum objections. 17:10:58 Skef: question, does anything check checksums? 17:12:08 Garret: My guess, for chrome, is that if they are being checked it's going to be in OTS. 17:12:33 Vlad: back when we had these discussions, the client side is the browser which will load the font and pass to font engine. 17:13:52 Skef: I think at this point browsers can probably modify those to ignore them. 17:15:36 Skef: at this point I don't think the checksums have much value. Because the recaculation will get the right checksum for wrong data. My proposal is to ask the CSS folks for some kind of interface tweak/check to say the checksums may not be right but it would be fine. 17:16:19 Vlad: agree. Additional testing is probably needed. The assumption was client will manipulate font and then used by platform supplied engine. 17:17:04 Skef: if there's a platform that can't get around the problem. If we're talking about browsers, like say the edge folks may be able to get the internal rendering engine updated. 17:18:03 Skef: firefox I think uses native. 17:18:09 Skef: not sure about Edge. 17:18:47 Garret: there's also safari. 17:20:31 Garret: a compromise solution would be where it's hard to update rendering libraries, would be to recalculate the checksums. 17:21:20 Garret: there's also value for this serverside when generating custom diffs I explored earlier. 17:22:30 Garret: ok as next step, Skef, could you test across browsers and see which ones care about checksums? 17:22:35 Skef: yes 17:25:14 2nd topic: General purpose dictionary encoding for http 17:25:59 Want to make sure that the IFT proposal is compatible with this shared dictionary system 17:26:15 scribenick: skef 17:26:28 Would be helpful to stop sending a custom response and just send a normal response 17:26:59 This is easier now that most of the state is in a table in the font file 17:27:43 Draft PR with the changes has been submitted 17:28:20 Major change: in handling the exceptional case where the client has a code point ordering that the client doesn't understand 17:28:51 Server will send the whole font instead of having this extra handshake 17:29:48 (Another option, if we want to keep this, is to use a pre-existing HTTP status code as the signal.) 17:30:27 Chris has a minor preference for the status code approach 17:33:15 The changes needed to align with this still very early spec also have their own motivations -- basically making the http transactions more like a typical request 17:34:48 Sounds like we're in agreement and can go ahead. 17:35:06 to be decided: Whether to use the status code approach 17:36:39 Next topic: The spec has been shifted to make brotli the default and vc-diff optional 17:37:41 Skef: what are the OTS implications of the integration work with the extra table. 17:38:53 Garret: I'm not sure, but we can update the OTS implementation to ignore that table if needed. 17:39:15 Skef: we had a shift in priorities and I'm working on the statically chunked prototype. 17:39:34 scribenick: Garret 17:39:36 Skef: not at the point of running tests yet, but I've overcome the major hurdle of dep analysis for the chunks. Not pretty but seems to work. 17:40:34 Skef: if this ever becomes real, the thing you'd want to do. It's a graph partition problem. The deps form a graph. You take out a reasonable baseline and then you do graph partition and take minimally connected groups and remove connections by moving things into the baseline. 17:40:57 Skef: I don't have a good feeling for what the optimization function would be. Since you're trying to take advantage of spacial locality. 17:41:28 Skef: so I'm doing a extremely bruteforce arpproach with harfbuzz mechanisms. I think i've got a pattern thatwill work. 17:41:38 Skef: maybe in a ocuple weeks I'll have something to show. 17:43:42 Skef: assume you've arranged the glyphs into a single array and you want things close to each other based on that array. 17:43:51 present+ Chris Lilley 17:43:58 Skef: so you need some sort of cost function. Not my area of expertise though. 17:44:17 Skef: someone would have to sit down for a few weeks to do something that's really optimal. 17:44:56 Skef: need a cost function, graph partition. 17:45:21 Garret: makes sense, we can define how it works and leave it to the real implementations to optimize. 17:45:42 Skef: spec will explain how it works. 17:46:12 Skef: so when you look up a gid you need to get a chunk that has all the downstream needed data. 17:46:37 Skef: when I'm ready I'll email in advance and get you a draft. 17:53:02 Next meeting planned for march 7th 17:53:03 Next meeting is tentatively on March 7. 17:53:35 zakim, list attendees 17:53:35 As of this point the attendees have been Vlad, skef, Garret, Chris, Lilley 17:53:55 present- Lilley 17:53:57 zakim, list attendees 17:53:57 As of this point the attendees have been Vlad, skef, Garret, Chris, Lilley 17:54:36 rrsagent, make minutes 17:54:37 I have made the request to generate https://www.w3.org/2023/02/21-webfonts-minutes.html Vlad