Meeting minutes
Vlad: topic 1. checksums
Skef: I've been looking at client side stuff and working through the implications.
Skef: reminded of my general checksum objections.
Skef: question, does anything check checksums?
Garret: My guess, for chrome, is that if they are being checked it's going to be in OTS.
Vlad: back when we had these discussions, the client side is the browser which will load the font and pass to font engine.
Skef: I think at this point browsers can probably modify those to ignore them.
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.
Vlad: agree. Additional testing is probably needed. The assumption was client will manipulate font and then used by platform supplied engine.
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.
Skef: firefox I think uses native.
Skef: not sure about Edge.
Garret: there's also safari.
Garret: a compromise solution would be where it's hard to update rendering libraries, would be to recalculate the checksums.
Garret: there's also value for this serverside when generating custom diffs I explored earlier.
Garret: ok as next step, Skef, could you test across browsers and see which ones care about checksums?
Skef: yes
<skef> 2nd topic: General purpose dictionary encoding for http
<skef> Want to make sure that the IFT proposal is compatible with this shared dictionary system
Would be helpful to stop sending a custom response and just send a normal response
This is easier now that most of the state is in a table in the font file
Draft PR with the changes has been submitted
Major change: in handling the exceptional case where the client has a code point ordering that the client doesn't understand
Server will send the whole font instead of having this extra handshake
(Another option, if we want to keep this, is to use a pre-existing HTTP status code as the signal.)
Chris has a minor preference for the status code approach
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
Sounds like we're in agreement and can go ahead.
to be decided: Whether to use the status code approach
Next topic: The spec has been shifted to make brotli the default and vc-diff optional
<Garret> Skef: what are the OTS implications of the integration work with the extra table.
<Garret> Garret: I'm not sure, but we can update the OTS implementation to ignore that table if needed.
<Garret> Skef: we had a shift in priorities and I'm working on the statically chunked prototype.
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.
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.
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.
Skef: so I'm doing a extremely bruteforce arpproach with harfbuzz mechanisms. I think i've got a pattern thatwill work.
Skef: maybe in a ocuple weeks I'll have something to show.
Skef: assume you've arranged the glyphs into a single array and you want things close to each other based on that array.
Skef: so you need some sort of cost function. Not my area of expertise though.
Skef: someone would have to sit down for a few weeks to do something that's really optimal.
Skef: need a cost function, graph partition.
Garret: makes sense, we can define how it works and leave it to the real implementations to optimize.
Skef: spec will explain how it works.
Skef: so when you look up a gid you need to get a chunk that has all the downstream needed data.
Skef: when I'm ready I'll email in advance and get you a draft.
<skef> Next meeting planned for march 7th
<Vlad> Next meeting is tentatively on March 7.