Meeting minutes
Bianca: I'm going to present at AtypI too. I'm going to have an interview with a few presenters. Can I interview you, Garret?
Garret: Yes
Bianca: I also invited Peter Constable about color fonts.
<Vlad> ATypI tech talks: https://
Garret: Please send me more details.
Bianca: Thank you.
Garret: That should be a good talk. The ones we've given in the past were vague. Now we can present real results
Garret: None of it will be new to members of the WG. But it will be good to present more widely
Vlad: It will be good for the general public to be informed about what we're doing and what's coming in the future.
Data on removing variable font axes
Garret: This might motivate changes to the spec.
Garret: It's the ability to specify the design space.
Garret: We took a bunch of variable fonts - only a few, actually - and we instanced them to different permutations of the available axes. We focused on fonts with wght, wdth, and opsz
Garret: We tried moving different combinations, and measured size changes
Garret: This captures the result of adding opsz to a font which already has some axes.
Garret: The size increase from 49% at the lowest with 306% at the highest. Average: 150%.
Garret: The next row is adding opsz to a font that already has an axis. Slight variations, but similar increases as adding it to a static instance.
Garret: If we add opsz to a font with the wght axis, it goes from 108% to 190%
Garret: Overall, what we see is on average, adding axes is a pretty significant chunk of data. The averages here are all from 75% to over 100%. Except for wdth, which seems to be cheaper.
Garret: Looking at the extremes, it can be quite small and quite big.
Garret: I think this all supports having the ability to incrementally add axes to fonts. Seems significant reduction of byte saved to incrementally add axes.
Garret: This was done on a small list of fonts. I want to re-run on a larger corpus of ~100 fonts.
Garret: So we'll get much more data.
Garret: We also have graphs!
Garret: The higher these numbers are, there's more benefit to subsetting axes out, because we'll save more bytes. So if these numbers are like 5%, then it might not be worth the complexity cost.
Vlad: When we say "complexity" we mean server complexity subsetting the data.
Garret: and complexity in the protocol.
Vlad: Is this something that we should mandate, or should we just recommend?
Garret: My take is that we should have this be purely optional, so the server could optionally support. We could say "the client should send this info if it has it" and the server can do whatever if wants with that
Vlad: This is nice-to-have because the savings are substantial. But as much as I would love for the spec to not have optional features, but allowing this to be an option allows the implementer the power to not implement the whole subsetting functionality
Vlad: Deployment of the feature itself is more important than incremental improvement and efficiency gains.
Vlad: Allowing this to be deployed without incremental gains would be great
Garret: Re: codepoints, the client says "we need these codepoints" but the server is free to send more. The same thing happens here. The server is free to send more axes than what the client requests
Garret: The first simulation we did was on removing axes as a whole. The second one was we looked in the fonts and found where the masters were, and we cut up the font around the masters. We compared the size savings of this compared to cutting down to just those ranges.
Garret: This is incremental. You can start with one set of masters, and add more masters later. We could have the server first send the inner masters, and then send the outer masters later.
Garret: For some of the fonts, it will say no range found, and that means there are only 2 masters
Garret: There's also in some cases there are no tooling support. This means the range is not part of the default outline. The instancer is not capable of handling that.
Garret: If we go through, we see a range of sizes, but it looks like up to 30%... here is 55% .... and so on. I think this is indicative that this is something we probably want to support
Garret: So not just which axes are necessary, but also which ranges on those axes it needs
myles: How often are clients going to request ranges that just happen to match up with where the masters are?
Garret: Don't know. Will gather more data.
Garret: If someone requests a range that contains the innermost masters, we'll send them just those innermost masters. We do this in our (Google Fonts's) CSS api.
Garret: We can look at how often this happens in our current API to answer that question, myles
Review spec updates for new font and patch font request
Garret: This covers the request behavior
Garret: If there's anything we wanted to discuss, we can do it now. I also have a topic which Vlad brought up.
Garret: Vlad had a comment asking about the keywords "MUST" "SHOULD" SHOULD NOT" and so on. Vlad asked to capitalize them.
Vlad: I'm actually adding a link to the RFC to make us comply. I'm not saying we should explicitly capitalize every "MUST". We need to clearly distinguish what is lowercase must - just descriptive language that has no conformance tests, against capital MUST, which must have a test for it.
Vlad: When you talk about "external features" like using POST request, we need to be careful whether ... we might say MUST because we mean this as a requirement, but if it's non-testable, then it will be a hardship later. We need to be smart about this. Before you type MUST, the collective "you" must have a clear idea how it will be tested.
Garret: This is wording that Chris had added, which says the keywords will not appear in uppercase throughout the specification.
myles: i kind of like not having to capitalize MUST. We can just use different language, or specifically add text saying "this section is non normative"
Garret: Okay. Let's do that. I'll do a quick audit to make sure everywhere we say "must" we mean it.
Garret: I'm going to try to get more sections this week. It shouldn't be too long before we have most of it done.
Vlad: What about the part where we interchangeably talk about "codepoints" and "indices"
Garret: On first request, the client requests codepoints. The server will reply with a mapping of codepoints to indices. I call Unicode codepoints "codepoints" and for the remapping, I use "indices"
Garret: It's an overloaded term, though, for things like glyph indices.
Garret: We may want a different word instead, that isn't overloaded, and is not "codepoints"
Vlad: When you introduced "indices" as a field in patch request, you explain that this is a set of code points.
Garret: That's a mistake.
Garret: I should update the wording to be consistent.
Garret: THESE two fields should always be "indices"
Garret: That's my bad, then.
Garret: I'll think about a different name for "indices" that isn't an overloaded term.
Garret: I'm going to keep working away, trying to get the full draft written. Then I'll send it out for more thorough review.
AtypI
Vlad: Did you get a form from AtypI regarding your talk?
Garret: yes.
Garret: I think they actually forgot about me because I had to ping them to get it.
Vlad: Yes, that same thing happened to me in the past, too.
Garret: It's all sorted out, now.
Meeting planning
Garret: I hope to have a full first draft 2 weeks from now.
Vlad: Next week is the MPEG meeting. The plan session will happen at 1pm eastern time next week.
Vlad: The week after that is AtypI tech talks, which will likely overlap as well.
Vlad: So we should come back on May 11
Garret: ok