15:59:53 RRSAgent has joined #webfonts 15:59:57 logging to https://www.w3.org/2025/04/22-webfonts-irc 16:00:05 Zakim has joined #webfonts 16:00:11 present+ 16:01:30 rrsagent, make logs public 16:01:52 Garret has joined #webfonts 16:02:06 Vlad has joined #webfonts 16:02:11 present+ skef 16:02:23 present+ garret 16:02:29 present+ vlad 16:02:47 I'm a bit ill today so I'm mostly here pro forma today 16:03:32 present+ Treunde 16:03:57 Topic: URI templates 16:05:09 present+ ragvesh 16:08:13 present+ 16:08:42 Topic: uri templates discussion. 16:10:50 Summary there are concerns over the specific uri template rfc that we chose to use. Suggested to either use url patterns or possibly our own mechanism instead. I've proposed as an option a very simple op code encoding that would do away with human readability to make template parsing/expansion very simple. I've expressed concerns about URL patterns 16:10:50 on the issue due to the complexity in supporting them as they are currently specified. 16:11:01 Don't want to block on waiting for URL patterns to be ready. 16:11:27 Waiting to here back from Anne on whether the op code approach could be acceptable. If we do go down that path the spec and encoder changes would be small. 16:11:41 Hoping to have resolved in the next couple ofweeks if we can to unblock us. 16:12:22 topic: privacy implications 16:12:37 Topic: privacy implications of new patch patterns #267 16:13:40 Skef: current guidance might not be sufficient given some more complex loading cases. Intersects with performance. Privacy section likely needs some updates. 16:14:14 Chris: duplication - when shared between languages might be a good way forward. 16:14:51 Skef: kerning info will be part of table keyed patches. Table keyed patches are diffs, easier since its what we used to do. 16:15:47 Skef: put some documentation into the encoder repository on when to duplicate or not. 16:16:13 Skef: duplication will often make sense. Will not want to be to specific on strategy in the spec. 16:16:33 Skef: at the end we can say it also makes sense from performance perspective. 16:17:21 Garret: how did my suggestion on the issue sound? 16:17:58 Skef: sounds good, we might need more though. Don't necessarily need to figure everything out. 16:18:17 Skef: explain that you can't just rely on number of codepoints, give an example. 16:19:10 Garret: sounds good, I'll start by drafting some changes. 16:19:39 topic: status 16:19:41 Oh, I just closed https://github.com/w3c/IFT/issues/101 16:22:58 Skef: question about hwo the current IFT client handles font storage. 16:23:16 Garret: client currently doesn't handle that, leaves it up to the specific implementation to decide how to store. 16:24:30 Skef: there's a discrepancy about this that we might want to clear up. The place to store this is the http cache. So if you load the font and modify it how is the entry in the cache handled. 16:24:47 Do we need cache invalidation once the patch is applied? 16:31:47 q+ for a couple of minor updates 16:34:48 Skef: doesn't belong in the IFT spec but we should consider possibly working with others to see if we can improve the situation (number of copies when dealing with storage/cache). The whatwg/fetch group might be a good place to start. 16:36:55 Chris: couple of small updates issue 101 I've closed as the shared brotli spec is no longer expired. 16:37:08 Chris: tag has acknowledged receipt of the review request. 16:37:17 streude has joined #webfonts 16:39:24 rrsagent, make minutes 16:39:26 I have made the request to generate https://www.w3.org/2025/04/22-webfonts-minutes.html ChrisL 18:58:40 Zakim has left #webfonts