Meeting minutes
<Garret> garret+
<mayasse> present
Update on Harfbuzz
Garret: Harfbuzz subsetting is in development. It's a key part to this whole subsetting thing. As of last week, we're at a 1.0 point. Full subsetting support for all lookup types. That was the last thing that was remaining to be done. Exciting!
Garret: There will be some further development, but the core subsetting is in place.
Garret: The next big project is variable font instancing.
mayasse: Subsetting along an axis
Garret: In the end implementation, you'll fix a set of axes to a specific point. Also, we want to reduce the range that an axis supports. So you can reduce the set of masters. We might not want to support the whole range, so we can clamp down the variable space.
Should we allow the client to indicate a specific variable design space they're interested in?
Garret: The server could use this to narrow down the design space of the variable font it sends to the client.
Garret: Maybe the client only needs the normal weight, so the server could drop all the delta information.
Garret: At some point, later, if the client needs weight 300, the server could send weight 300.
Garret: So the variable information could be built up over time
Garret: To support this in the protocol would be simple. Just additional fields. The server would need an instancer, similar to a subsetter
Garret: Do we want to do this?
mayasse: Generally, I like the idea
mayasse: Trying to think through what's the friendly way to handle it. I like the idea.
mayasse: What about glyphs in subsetting?
mayasse: unicode-range doesn't match glyphs exactly
Garret: The client will send a set of code points. The server will derive the set of glyphs of interest from that. It's a little bit complicated. You get the initial set out of the cmap table, and you need to expand it via GSUB, etc.
mayasse: Where can I learn more?
Garret: I can paste a link
<Garret> https://
Garret: This is the message definition for the request the client would send. Codepoints have, and codepoints needed.
Garret: The server will make subsets: one that matches the client's current state, plus one more with the union of all the codepoints, and then will create a binary diff. With this variable thing, there will be additional fields to describe which range of the design space is being requested. The server will use that when it creates its subset
Garret: If the default outline is at 400, and the client wants 700, you don't want to instance to 700, because patching later won't work well. So this will be limited in what it can do.
Vlad: There's a concept of "named instances" in a variable font. You can define multiple points in your design space where you can assign labels. You get there by implementing variability on more than one axis sometimes. So if you have wdth and wght and you have a named instance that's bold-condensed, it requires variations on both axes.
Vlad: Trying to satisfy a request by creating a subset that is specific to one instance may not be the most efficient way of doing it. We can probably be more efficient if client requests just base design (no variability) or if they want to add base design + 1 variation axis, etc. Doing that would be A) easier and foolproof
Vlad: If someone knows the page design that's variable, someone might say "i want to use this variable font but only a particular set of axes"
Vlad: We need to consider different possibilities for different implementations. Trying to be generic and support any instance involves applying variations in more than one axis may not be effective
Garret: We wouldn't move the default outline. We would subset just the delta information. If you think that you only need 400-700, we can leave out 100-399
mayasse: What happens if you're out of range for an axis?
Garret: If you load one thing, then the page changes what's needed later, you'd have to wait for more to load in. That's a reason to send whole axes at a time.
Vlad: How much data, if someone requests a particular axis to be included or excluded, vs a portion of that axis (e.g. only 400 - 999) how much data we're saving by not including the other side of the deltas.
Garret: I might actually have data on this. We support a form of this in the Google Fonts API. We'll try to send you less than the whole font if you request it. We did a small-scale study on this. We'll see if we can publish that.
Garret: We looked at multi-axis fonts. Because the cross-product of the axes can get big
Garret: It makes a big difference if you don't have to send the whole thing
Vlad: We'll have to see whether the benefit outweighs the complexity. I think it would increase complexity and diminish the benefit
Garret: My thought is that it would be an optional feature. A compliant implementation wouldn't have to do this, but could.
Garret: This would help with complexity
Vlad: Makes sense.
mayasse: My experience with variable fonts is so many axes are not design-wise to my untrained eye they aren't useful except for a few values along the axis
mayasse: In some cases the axis is a boolean.
mayasse: The difference between 350 and 325 is no difference for the average user.
mayasse: For namable values, is it always the case that there's a default value for every axis?
Garret: Yes.
Garret: You have the glyf table which specifies the default outline, and then you have a bunch of deltas which move that around.
mayasse: Are there other namable combos as well?
Vlad: Yes. Fonts have a STAT table that's part of the variation table structure. It allows you to specific, for example, if you have wght and wdth, you have 1 set of glyphs gives you regular, normal, and just a regular font within the family. But you can specify multiple different sets of axis values to say "apply these values to achieve something that I want to call medium weight or bold or bold-condensed or light-extra-condensed"
Bianca: I would like to see subsetting happening - either dropping a whole axis or part of an axis. If, in the CSS, the user says "please go from the normal width to more condensed", in this case, if we dropped the wdth axis in the beginning, there would be a new download. Can we link them together somehow? To tell the browser not to request a subset
Garret: Yes, we'll need to do something like this. We might also want to know about additional codepoints that are coming in the future.
myles: it would be difficult for browsers to just guess what is necessary. There might need to be more input from the author
Garret: The author would be responsible for specifying the axis to include or not include. Not the client.
Garret: In chrome, you can say "font-weight: start end" but that only acts for 3 axes.
Garret: Maybe we could add something like that for other axes?
Vlad: We don't have a mechanism to define which code points are included. The mechanisms could be similar for both
sergeym: weight, width, slope are special because they affect font selection. Everything else is just decoration.
sergeym: font-optical-sizing will select different instances of Sitka. Sitka isn't a variable font
Garret: We can integrate this into the CSS Font Loading API.
myles: we should see if we can re-use unicode-range.
myles: it may not work, but we should try it.
Bianca: If we did this by unicode-range, what happens to non-unicode encoded characters? Say proportional numbers as default and tabular numbers as alternative
Bianca: or stylistic set
Garret: We could also allow the set of features to be specified by the client, as another axis we can increment on
Garret: By default, we wouldn't send these, but the client could add in the features
Garret: But it might not be helpful in terms of size savings
Vlad: So we're including every glyph that may or may not be used from a particular unicode code point.
Garret: The range-request method works on glyphs, so it will request just the stylistic sets that are in use. But patch-subset downloads all the glyphs which is reachable from a code point
Bianca: The reason I'm supporting trying to subset this is to make it easier for the user. I'm seeing hesitancy to use variable fonts. My clients are saying "we're not sure we want to use variable fonts, and package it in 3 different ways, because maybe they don't need all these axes, and it's complex, and I'd like to make it easier for people"
Garret: We found with large multi-axis font, it's prohibitive to send the whole thing, so we'll aggressively send instances or subsets. So doing this makes sense to me.
Vlad: Do you see challenges with this approach?
myles: Using this idea in the range request idea would require a new file format.
Vlad: It can be implemented on a per-table basis, to include or exclude a table.
Garret: We don't necessarily need to support this in range request. RR will be most useful for CJK.
Garret: It seems fine as something that's supported on one method but not the other.
Vlad: The reason I made this comment "CJK fonts are not YET variable" most of the time the problem with variability is overlapping contours not being handled well, but COLRv1 table allows layers to be defined. There's a conversation about using that same mechanism for overlapping layers
Vlad: That will make it much easier to deal with overlaps and dropouts. If you can just paint layers, and each layer is variable, then that naturally solves the problem
Vlad: Say you have a composite glyph that's combined from multiple simple glyphs. The variability causes overlap between different contours. It will not handle each layer as a separate paint layer, it will try to render them, and overlaps will create holes.
There's no easy way around that in the existing design. The current design, overlaps are excluded by design
Bianca: The individual strokes in a Chinese glyph are <missed>
Vlad: If variability causes the two sides of a Chinese glyph to overlap, then that's a problem.
Garret: We're currently working on a demo with an emoji font for the draft COLRv1 table
Garret: That will be another interesting use case for the technology
end
<Vlad> zalim, list attendees
<Bianca> Bianca