Meeting minutes
Vlad: It's desirable to allow composite fonts to be used without flattening. This can be something that's supported by HTTP range request mechanism and the smart server as well.
Vlad: This can be achieved by having the range request server understand the details of the font, and when the client requests one range, reply with a larger range that includes the components of anything that's included in that byte range
Vlad: I didn't add this to agenda.
Vlad: myles, it sounds like you have an idea of what spec changes are necessary?
myles: yes. Vlad, can I ask you to open an issue about it?
Vlad: yes.
Range request issues
Garret: Issue 56 and 57?
Vlad: No, issue 48.
Garret: I thought there was consensus to do 1 spec. Chris was going to do some research to see if that was an option
Vlad: I wanted to record that as a group consensus.
Vlad: Should we maintain 2 separate documents, or merge them? Or somehow identify a 3rd document which would be the overarching top level document which would reference the 2 documents. As that discussion progressed, everyone agreed that merging everything into a single document is the way to go
Vlad: We need to figure out how to deal with it b/c the first document has been published as a FPWD
Vlad: Chris says we cannot re-publish FPWD
Vlad: We need to make sure we give equal opportunities for patent exposures. Once we pass that procedural step, we all agree that merging into a single document is the way to go
Garret: Yes.
myles: Yes.
Issue 56: Method negotiation
Vlad: Right now, as drafted, method negotiation allows the server to make suggestions. Client may ask for one thing, and server may respond with something different.
Vlad: I'm referring to portion of myles's document
Vlad: ... that is chapter 3.
<Garret> myles: a few months ago the group decided that all servers which support patch subset must also support range request.
<Garret> myles: that leads to a natural behaviour where if a server supports both. The one the client supports use.
<Garret> myles: if the client supports one and the server supports one, then it must be range request since that's common.
<Garret> vlad: what happens duringthe client implementation is a seperate issue.
Vlad: regarding what happens on the client, that's a separate issue that I raised that's part of the agenda. It's unrelated to specific parts of the document. We can discuss it now.
Vlad: I think, if we step back and look at what happened when we developed WOFF2, WOFF2 had multiple different mechanisms in place that may or may not be used when font is compressed, and therefore it gives flexibility on the server, if you don't want to implemetn complex mechanism to prepare WOFF2, you could avoid optimizations and just have brotli compressed font file and would still be compliant
Vlad: But to give choice to the author, we agreed that client must be able to use whatever data it gets from the server. The logic was that clients should not limits authors in what they want to do. If author wants to choose a particular option that's more complex, clients must allow that to happen.
Vlad: That same logic would apply here. As far as client is concerned, it's logical to request that logical must support both methods. Server may or may not support both. But clients must. If server chooses to support range request only, if server chooses to support range request then it must support patch subset as well. I want to enable the choice to be in author's hand, not in implementor's hand. Implementations should not limit authors about
what to do and why
<Garret> myles: I think I disagree the browser is working on behalf of the user and they should be the ones having the choice.
Vlad: If the client doesn't support patch-subset, you're penalizing the user by diminishing user experience
<Garret> myles: I'm imagining a sort of situation were a browser has a preference.
Vlad: The user clicks a link. If I want to open a website of my choice that uses only patch subset to optimize my experience, then the browser would be in the way of my optimal using that content
<Garret> myles: so the user is the one deciding which of these two things are occuring. ie. the user has expressed a preference.
<Garret> myles: that preference should be honoured.
<Garret> myles: so if the browser has the code to support patch subset, and the user asks for it, it should be used.
<Garret> vlad: if user agent doesn't have the code that limits user choice.
<Garret> myles: different user agents ship different features at different times. I don't think it's reasonable to ask browsers ship the two features together.
<Garret> vlad: I think we should. I think for the purpose of user experience the user agents should support both.
<Garret> myles: can I take some time to think about this.
<Garret> vlad: sure
<Garret> vlad: don't need a final decision at this moment, but wanted to raise it for discussion.
Vlad: We don't have to make a final decision right at this moment, but I want to discuss. It seems like it's a small price to pay for something that will truly be user choice and author opt-in. For UAs to support both options
Vlad: We have issue 57. We can continue on GitHub. It's good to have this F2F discussion to jump-start the continued conversation. it can happen on GitHub, it doesn't have to be limited to the call itself.
Vlad: Going back to issue 56, it's logical for server to support patch subset to be mandated to support range request as well. As part of the proposed mechanism for method negotiation, section 3 of the range request draft, there's an enumerated list of steps. Step 3 currently allows, when the server receives request for patch subset, the server can say "you know what? you'll be better off using range request in this case" and replies with a
different approach. This is useful, but it should not be binary. If server supports both, and client supports both, the server should be able to do exactly the same, and say "you're asking for range request but I believe you'll be better served using patch/subset"
Garret: For patch subset, the request sends all the information for both requests. But if the client only sends a range request, that's not sufficient for the server to reply with info. If the client could use either, it will send the combined first request, and then the server would reply one way or another. If the client could only use range request, that will work on all servers
Garret: So then yes we do have the mechanism for the server to choose, as long as the client accepts either method. And we avoid an extra round-trip
Vlad: I'm not sure I understand. There was a reference to the older implementation...?
Garret: ???
Vlad: When client sends range request only, if the client sends a range request only because it only supports older method ....?
Garret: The client can do 1 of 2 things. If the client has no preference for which method, then it sends both requests, and it lets the server decide. If it specifically prefers range requests, it will send the range request header, and we know that it will be supported by all IFT servers.
Vlad: We don't have IFT servers yet. I believe, to have user preferences in mind, and to serve users well, we need to require clients to support both methods.
Garret: Yes, we have that. Alls IFT servers will have to support both
Garret: It sounds like you're asking for a way for, if a client only supports range request, that the server would auto upgrade them to patch subset. This would require a round trip
myles: You're thinking of a new HTTP header saying "please try again with patch subset?"
Garret: I don't think we should do that. But it would be necessary if we did issue 56.
Vlad: <reads from spec, the part where the client supports both>
Vlad: I would imagine that similar situation where the client asks for a range request, and if we reach an agreement that clients must support both methods all the time, and there might be a user preference to support range request, but if the website supports patch subset as well, it might be in the user's best interest to use it.
<Garret> myles: if there's a disagreement the client must win.
Vlad: That's not what specificed in list item 2 in the spec
Garret: When client sends patch subset parameter, that means "i'm fine with either"
Garret: Maybe we could add a new parameter that expresses client's preference for the method
Garret: The other option the client can do is, if the client for sure wants to use range request, then it would omit the patch subset part
<Garret> myles: range request is an existing technology so itwould be a big problem if an existing browser made a range request and got back something non-standard.
Garret: that's a good point. That's another argumetn why there should be an upgrade/downgrade option on the request itself.
<Garret> Vlad: ok yeah, let's continue this discussion on the issue.
<Garret> myles: not on the agenda, but had another topic. In the range request spec there's no must level requirements. That's intentional to make it easy for websites to adopt it.
<Garret> myles: technically according to the spec websites don't have to do anything.
<Garret> myles: they don't have to do preprocessing, it's not must level.
Vlad: We need to have a more elaborate discussion. There's a section of the spec where you reference WOFF, WOFF2. Those parts of the spec needs to be discsussed and amended.
<Garret> garret: I think there's one must level requirement, taht the implementation support range request.
<Garret> myles: browser implementations have two steps, 1. download font, 2. pass to the renderer. Something I want to be possible is where step 1 doesn't happen. A virtual file system passes results to step 2. When it tries to look at bytes in a file it causes range requests.
<Garret> myles: so then if that's the cause it doesn't matter what the compression format is.
<Garret> myles: was hoping when writing the spec that would be a valid implementation.
<Garret> Vlad: thinking about range request, in order to be able to send a range request. Need something to determine what range request should be. So if you have a partial font file that gives you loca information.
<Garret> Vlad: so you know what data range to ask for.
<Garret> Myles: the solution is more range request. So say you have a fully compressed font. The client gets the beginning which says this is a compressed woff2. So then it needs to support brotli compression. It'll begin to compress the brotli data. Then it will get enough of the header to know which macro block to request.
<Garret> Vlad: there's multi data streams that you need to get all of the data.
<Garret> Myles: that's right, it won't necessarily be fast. If you allow yourself to make a million range requests it can be done.
<Garret> Vlad: you need to recompose multi font data streams into the font file. Which means you'll end up with the whole font downloaded.
<Garret> Vlad: so the only way to amend it is with patch subset.
<Garret> Myles: someone could make a font where to read a font you need the last byte, then the second to last, and so on. I think I disagree with the claim that all woff2 files are like that.
<Garret> Vlad: I think making woff2 as part of incxfer probably needs to be a separate discussion.