16:58:03 RRSAgent has joined #webfonts 16:58:03 logging to https://www.w3.org/2021/01/25-webfonts-irc 16:58:05 RRSAgent, make logs public 16:58:05 Zakim has joined #webfonts 16:58:07 Meeting: Web Fonts Working Group Teleconference 16:58:07 Date: 25 January 2021 17:00:19 Garret has joined #webfonts 17:01:51 myles has joined #webfonts 17:03:15 chris has joined #webfonts 17:03:21 present+ 17:03:30 present+ 17:03:54 present+ 17:05:59 present+ 17:06:28 ScribeNick: myles 17:06:46 Chair: Garret 17:07:27 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. 17:08:14 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. 17:08:20 Garret: It's gonna be problematic. 17:08:45 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. 17:09:54 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. 17:10:13 ned: Do you have to know what the maximum value is in the tree before encoding it? 17:10:45 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. 17:10:58 ned: How do you know know ... it's a fully balanced tree I guess? How do you know how many layers there are 17:11:19 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. 17:11:34 ned: I must be missing something 17:12:12 ned: There has to be some tradeoff between breadth and depth. How do you know if a bit is a leaf or a continuation 17:12:12 Garret: I think I explained that wrong. The number of layers is dependent on the maximum value. 17:12:52 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 17:13:01 chris: Adding that to the doc would be useful 17:13:37 ned: When it comes to an exmaple, please don't use palendromes 17:13:51 ned: You have to read to the end to know if it's LSB or MSB 17:15:08 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. 17:15:20 Garret: And there's uint64 that uses 8 bytes 17:15:29 We also have two variable length integers 17:15:35 These are just pulled from WOFF2 17:16:12 these work like Pascal strings 17:16:12 Same with ArrayOf which starts with a count 17:16:27 ArrayOf might not have uniformly sized items, so you can't randomly access them 17:17:23 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. 17:17:41 Garret: For each object, there is a description of the types. Nothing has a specified length anywhere. 17:18:12 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. 17:19:21 Myles: I wish there was some set of required objects, so readers don't have to interpret any arbitrary set 17:19:29 Garret: I will add it. I haven't gotten around to it. 17:20:12 Garret: But none of this stuff will change from the previous version. 17:20:12 Garret: this is just an encoding change. 17:20:15 Garret: There's a type that's a union with a range and a bitset 17:20:31 Garret: You choose to encode a range as either a range or a bitset, whichever is smaller. 17:20:46 chris: The bit of justification would be good to add too. 17:21:11 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. 17:21:23 Garret: Once we're on agreement on the basic approach I can fill it out in the spec itself 17:21:41 chris: We've got 2 repos, one is tools and one is for the spec. You have access to that? 17:22:28 Garret: nope 17:22:32 chris: I'll send a mail to the list. 17:22:50 chris: I'm happy to help you with Bikeshed if you want. 17:22:59 Garret: I'll start looking into it this week. 17:23:40 Repo is https://github.com/w3c/PFE 17:24:11 myles: why not json? 17:24:21 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.... 17:25:25 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. 17:27:02 https://en.wikipedia.org/wiki/BSON 17:27:21 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. 17:27:27 myles: Also, a range request method doesn't need any of this complexity at all 17:27:31 Garret: Yes, but it doesn't work as well. 17:30:25 myles: I just want to make sure everyone is okay with the editor being the same person as the chair? 17:30:41 chris: It's concerning but not a dealbreaker. Hopefully Vlad will step back in as co-chair 17:30:53 Vlad: I did it before with WOFF2 and it worked out. I think we can make it happen 17:32:26 chris: Please add me as co-editor. 17:32:28 Garret: OK. 17:32:44 Garret: Next steps for encoding is to research existing solutions. 17:32:58 ACTION: Garret: See if we can re-use some existing encoding technology 17:32:58 Created ACTION-229 - See if we can re-use some existing encoding technology [on Garret Rieger - due 2021-02-01]. 17:33:26 Garret: I'll also start working on the process of stubbing out a spec on another repo. 17:33:42 Topic: backwards compatibility 17:34:10 chris: what about "supports"? 17:35:42 myles: 17:36:16 jpamental: This is how we wanted color fonts to work, right 17:36:27 jpamental: I had started listing "supports" for variations too. 17:37:34 myles: we should use "supports". 17:37:36 jpamental: I agree. 17:38:11 Garret: I got fallback working in a codepen. 17:40:21 myles: fallback works differently if we use a new descriptor in @font-face 17:40:29 chris: The server might respond with a different font for the same URL 17:41:00 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. 17:43:04 Garret: Also we don't need to modify CSS much. 17:43:21 chris/myles: We might want to push the "supports" thing to CSS fonts level 5 17:43:38 chris: The TR publication has "supports" as well. 17:43:44 https://www.w3.org/TR/css-fonts-4/#font-face-src-parsing 17:45:29 myles: naming? "streaming" "progressive"? 17:45:34 Vlad: "augmentation"? 17:45:41 chris: "enrichment"? 17:46:18 Garret: internal google people thing "streaming" means like streaming video 17:46:38 Garret: Which matches the range request method 17:46:47 Vlad: Streaming indicates you discard the data after downloading it 17:46:54 chris: I like "progressive" 17:48:15 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 17:48:45 progressive like progressive image download. You get more, it gets better. You don't discard. 17:49:33 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 17:49:38 jpamental: I don't think streaming is right 17:50:12 Garret: "streaming" doesn't imply accumulation 17:50:12 Vlad: I agree. I've grown to dislike "streaming" 17:50:21 This is why Ilike both progressive and enrichment in the name 17:50:31 jpamental: I think I lean toward incremental. You're building upon things. 17:50:43 jpamental: Is there anything wrong with calling this "incremental" instead of "progressive" 17:51:01 myles: let's give this another week. 17:51:08 Garret: we can collect up suggestions. 17:51:25 Vlad: We should consider whether "enrichment" is part of the name. 17:51:36 Vlad: My personal taste: "enrichment" doesn't sound right 17:51:39 Vlad: I like "augmentation" 17:52:32 myles: to me, "enrichment" means your text will start looking like a ransom note, and the paths slowly form 17:52:48 Vlad: in the banking world and chemistry world, enrichment means different things 17:53:05 Garret: We want to say the font works just like it would otherwise 17:53:16 myles: ... except for loading 17:53:22 Garret: yes 17:53:26 ned: How about "partial" 17:53:44 Garret: is okay 17:54:12 jpamental: "Incremental" font transfer seems to describe what's happening pretty well. 17:54:13 Vlad: I would not guess that "incremental" means what we're doing 17:54:57 chris: incremental implies serial, and implies asymptotic 17:55:27 Vlad: Incremental means "you start with something, then build on it" 17:55:49 Vlad: If we do away with "progressive" and use "incremental" we might want to consider not using "enrichment" 17:56:22 myles: We should use just one of these fancy words. "incremental font loading" 17:56:31 jpamental: what you just said is direct and clear 17:56:42 this is precisely what we're trying to get across. 17:57:07 Vlad: what I hear "incremental font loading" what i hear is "intermediate steps may not be usable" 17:57:14 jpamental: why? 17:57:29 usually, when you load something, you wait for it to be loaded before it can be used 17:58:41 Garret: I'll start a thread with suggestions. We'll come back next week. 17:59:06 chris: let's ask the wider world 17:59:09 hexafont 17:59:48 jpamental: We're really inside this. People who know us will be somewhat inside. Maybe that's enough to balance our own biases. 18:00:12 Garret: I think it would be good to get opinions from other people 18:01:05 adjourned 18:01:12 rrsagent, make minutes 18:01:12 I have made the request to generate https://www.w3.org/2021/01/25-webfonts-minutes.html chris 18:03:03 present+ Ned 18:03:36 Garret: are you still around? 18:03:40 present+ myles 18:03:47 rrsagent, make minutes 18:03:47 I have made the request to generate https://www.w3.org/2021/01/25-webfonts-minutes.html chris