Meeting minutes
Garret: I don't have too much today. I'll do a quick overview of the doc I sent out on Friday about the encoding of the patch subset protocol. We can also talk about backwards compatibility.
Garret: Refresher: You may remember that when I designed the patch subset protocol, I used protobufs, which is Google-specific. It's open source and public knowledge, but there isn't a published standard for this. Unless we want to get it standardized .... it would need to be standardized for this effort.
Garret: It's gonna be problematic.
Garret: So, with that in mind I have this proposal for how that could work. So this is in the repo under v2 for the protocol doc.
Garret: The encoding is a few basic data types. Most of these should be familiar. UInt128 was taken out of the WOFF2 spec. There are 2 bit sets. The first bitset basically works the same as uint128. The sparse bitset is more complicated. If you remember the work I did for compressed sets, this is one of the data structures that came out of that. I think I explained these previously.
ned: Do you have to know what the maximum value is in the tree before encoding it?
Garret: Yes. You would have to know the full set ahead of time. Once it's encoded, you can completely decode it without knowing anything about the set. It's not random access. Its characteristics are just for encoding/decoding. It's a terrible data structure for interacting with the set.
ned: How do you know know ... it's a fully balanced tree I guess? How do you know how many layers there are
Garret: It's not a fully balanced tree. The first layer is 1 byte. You count the number of bits set, that's the number of bytes in the next layer. And repeat for further layers.
ned: I must be missing something
ned: There has to be some tradeoff between breadth and depth. How do you know if a bit is a leaf or a continuation
Garret: I think I explained that wrong. The number of layers is dependent on the maximum value.
Garret: Basically you need to break, in the last layer, the full number range between 0 and the max value is broken into chunks of 8 numbers. The branches allow you to efficiently encode
chris: Adding that to the doc would be useful
ned: When it comes to an exmaple, please don't use palendromes
ned: You have to read to the end to know if it's LSB or MSB
Garret: Another quick word about the sparse bit set, this came out as one of the best ways to represent sets, in combination with using ranges if there are large runs. So there's a data structure later that combines them.
Garret: And there's uint64 that uses 8 bytes
We also have two variable length integers
These are just pulled from WOFF2
these work like Pascal strings
Same with ArrayOf<Type> which starts with a count
ArrayOf<Type> might not have uniformly sized items, so you can't randomly access them
Garret: An object is a set of keys and values. We want the fields to be optional, which gives us flexibility for future extension. Also it allows us to use the same message in different contexts. So the way I've decided to do that is to use a bitset at the front to represent the presence of fields. Then you just concatenate the fields.
Garret: For each object, there is a description of the types. Nothing has a specified length anywhere.
Garret: This is designed to work like font tables today where objects are versioned. New versions will add fields to the end. Because fields are optional, we could stop using old fields.
Myles: I wish there was some set of required objects, so readers don't have to interpret any arbitrary set
Garret: I will add it. I haven't gotten around to it.
Garret: But none of this stuff will change from the previous version.
Garret: this is just an encoding change.
Garret: There's a type that's a union with a range and a bitset
Garret: You choose to encode a range as either a range or a bitset, whichever is smaller.
chris: The bit of justification would be good to add too.
Garret: Probably what I will do, if we are all in agreement, I'd like to start the spec document, and we can convert it to the spec document.
Garret: Once we're on agreement on the basic approach I can fill it out in the spec itself
chris: We've got 2 repos, one is tools and one is for the spec. You have access to that?
Garret: nope
chris: I'll send a mail to the list.
chris: I'm happy to help you with Bikeshed if you want.
Garret: I'll start looking into it this week.
<chris> Repo is https://
myles: why not json?
Garret: Size is really important, so we want a compact encoding. Text-based RPC encodings fail. JSON for example. If we can show that JSON.... <cuts off>
Garret: The bulk of data in any request is going to be raw bytes of an encoding. So a binary encoding is important. Then that means we'd have to look at existing binary encodings. Like protobuf, but it's not standardized.
<chris> https://
<chris> The name "BSON" is based on the term JSON and stands for "Binary JSON".[2] It is a binary form for representing simple or complex data structures including associative arrays (also known as name-value pairs), integer indexed arrays, and a suite of fundamental scalar types.
myles: Also, a range request method doesn't need any of this complexity at all
Garret: Yes, but it doesn't work as well.
myles: I just want to make sure everyone is okay with the editor being the same person as the chair?
chris: It's concerning but not a dealbreaker. Hopefully Vlad will step back in as co-chair
Vlad: I did it before with WOFF2 and it worked out. I think we can make it happen
chris: Please add me as co-editor.
Garret: OK.
Garret: Next steps for encoding is to research existing solutions.
Action: Garret: See if we can re-use some existing encoding technology
<trackbot> Created ACTION-229 - See if we can re-use some existing encoding technology [on Garret Rieger - due 2021-02-01].
Garret: I'll also start working on the process of stubbing out a spec on another repo.
backwards compatibility
chris: what about "supports"?
myles: <describes "supports">
jpamental: This is how we wanted color fonts to work, right
jpamental: I had started listing "supports" for variations too.
myles: we should use "supports".
jpamental: I agree.
Garret: I got fallback working in a codepen.
myles: fallback works differently if we use a new descriptor in @font-face
chris: The server might respond with a different font for the same URL
Garret: The incremental transfer will point to OTF or TTF. But for legacy clients, you want them to download WOFF2. So you'll need a new URL.
Garret: Also we don't need to modify CSS much.
chris/myles: We might want to push the "supports" thing to CSS fonts level 5
chris: The TR publication has "supports" as well.
<chris> https://
myles: naming? "streaming" "progressive"?
Vlad: "augmentation"?
chris: "enrichment"?
Garret: internal google people thing "streaming" means like streaming video
Garret: Which matches the range request method
Vlad: Streaming indicates you discard the data after downloading it
chris: I like "progressive"
jpamental: I'm torn. I think CSS has been bitten by not thinking through naming things well. Like font-stretch. So naming it accurately as a concept is 2 different things
<chris> progressive like progressive image download. You get more, it gets better. You don't discard.
jpamental: "streaming" is a really understandable word for people who don't know what's going on under the hood. but the objections are reasonable. It's hard. I think this is going to be with us for a long time. It matters for us to pick the right answer
jpamental: I don't think streaming is right
Garret: "streaming" doesn't imply accumulation
Vlad: I agree. I've grown to dislike "streaming"
<chris> This is why Ilike both progressive and enrichment in the name
jpamental: I think I lean toward incremental. You're building upon things.
jpamental: Is there anything wrong with calling this "incremental" instead of "progressive"
myles: let's give this another week.
Garret: we can collect up suggestions.
Vlad: We should consider whether "enrichment" is part of the name.
Vlad: My personal taste: "enrichment" doesn't sound right
Vlad: I like "augmentation"
myles: to me, "enrichment" means your text will start looking like a ransom note, and the paths slowly form
Vlad: in the banking world and chemistry world, enrichment means different things
Garret: We want to say the font works just like it would otherwise
myles: ... except for loading
Garret: yes
ned: How about "partial"
Garret: is okay
jpamental: "Incremental" font transfer seems to describe what's happening pretty well.
Vlad: I would not guess that "incremental" means what we're doing
chris: incremental implies serial, and implies asymptotic
Vlad: Incremental means "you start with something, then build on it"
Vlad: If we do away with "progressive" and use "incremental" we might want to consider not using "enrichment"
myles: We should use just one of these fancy words. "incremental font loading"
jpamental: what you just said is direct and clear
this is precisely what we're trying to get across.
Vlad: what I hear "incremental font loading" what i hear is "intermediate steps may not be usable"
jpamental: why?
usually, when you load something, you wait for it to be loaded before it can be used
Garret: I'll start a thread with suggestions. We'll come back next week.
chris: let's ask the wider world
<chris> hexafont
jpamental: We're really inside this. People who know us will be somewhat inside. Maybe that's enough to balance our own biases.
Garret: I think it would be good to get opinions from other people
<chris> adjourned
Garret: are you still around?