IRC log of webfonts on 2023-09-12

Timestamps are in UTC.

07:49:00 [RRSAgent]
RRSAgent has joined #webfonts
07:49:04 [RRSAgent]
logging to https://www.w3.org/2023/09/12-webfonts-irc
07:49:17 [Zakim]
Zakim has joined #webfonts
07:49:25 [Vlad]
zakim, start meeting
07:49:25 [Zakim]
RRSAgent, make logs Public
07:49:27 [Zakim]
Meeting: Web Fonts Working Group Teleconference
07:49:34 [Garret]
Garret has joined #webfonts
07:52:18 [jimmym]
jimmym has joined #webfonts
07:52:37 [myles]
myles has joined #webfonts
07:54:30 [myles]
hello
07:56:29 [jimmym]
jimmym has joined #webfonts
07:56:51 [jimmym]
testing.
08:00:12 [Vlad]
present+
08:02:56 [Rod_S]
Rod_S has joined #webfonts
08:03:42 [bberning]
present+
08:07:11 [Rod_S]
present+
08:10:47 [Garret]
present+
08:10:48 [RodS]
RodS has joined #webfonts
08:11:10 [myles]
ScribeNick: myles
08:11:49 [chris]
chris has joined #webfonts
08:11:56 [chris]
present+
08:12:01 [RodS]
present+
08:12:06 [chris]
rrsagent, here
08:12:06 [RRSAgent]
See https://www.w3.org/2023/09/12-webfonts-irc#T08-12-06
08:12:33 [drott]
present+
08:12:59 [myles]
Garret: I'll give an overview of what is patch subset. It's relevant.
08:13:13 [myles]
Garret: we have currently proposed: incremental font transfer. Idea is taking a font, transferring parts, then transferring more of it. Slowly building up the font. Goal: Save bytes
08:13:16 [Vlad]
topic: A More Static Friendly version of Patch Subset
08:13:31 [Vlad]
https://lists.w3.org/Archives/Public/public-webfonts-wg/2023Sep/0003.html
08:13:35 [myles]
Garret: There are 2 ways to do this. 1. Patch subset, 2. range request (or perhaps binned)
08:14:15 [myles]
Garret: For patch subset: The browser looks at all the code points. It sends an HTTP message saying please give me a font for these code points." If it needs more, it will send another message, saying "give me a patch - i have these, and i need some other ones"
08:14:32 [myles]
Garret: There is a dynamic server side involved. It will look at this message and produce the appropriate patch on demand
08:15:03 [myles]
Garret: There are repeated concerns raised from different parties about requiring a smart server. Most people want to just stick static files on a server or CDN. A server-side computation makes things complicated and costly
08:15:38 [myles]
Garret: I've been trying to think about improving patch subset so it can work both statically or dynamically if so desired. Can we make it fully compatible with sticking font files on a CDN? And have an option for services that want a dynamic reactive version as well. That's what motivated this proposal.
08:15:57 [myles]
Garret: Let's jump in to the idea. Patch subset works by:
08:16:19 [myles]
Garret: You have a font, and you have a subset to add to the font, and you get a patch that upgrades the font. We'll keep the framework, but focus on the message.
08:16:41 [RodS]
Just in case not everyone has seen it, https://lists.w3.org/Archives/Public/public-webfonts-wg/2023Sep/0003.html is a written description of the proposal Garret is describing
08:17:00 [myles]
Garret: Proposal: The first font file will include a custom table, which will include a map of additional subset patches that are available
08:17:00 [myles]
Garret: ... to a URL which hosts that patch.
08:17:16 [myles]
Garret: This way, you can form a graph the client can walk to get whatever it needs. The graph of patches can be stuck on a server and served statically
08:18:00 [myles]
Garret: The nice thing about this change is it obfuscates that message which normally would have been formed dynamically by the client, and makes that an implementation detail. Dynamic version: The URLs point to URLs the server can respond to dynamically
08:18:04 [drott]
q+
08:18:14 [myles]
Garret: There are 2 main drawbacks we'll have to deal with
08:18:20 [myles]
Garret: 1. We can't download patches in parallel
08:18:59 [myles]
Garret: If you need 2 subsets, you have to get one, resolve it, then get the second one, then resolve it. you can't apply the second patch on top of the first one.
08:19:13 [myles]
Garret: 2. For CJK fonts, if you did any fine-grained segmentation, the graph will result in being enormous. Might not be viable to host in a static context.
08:19:19 [myles]
Garret: I have ideas about how to work around these.
08:19:42 [myles]
drott: Does this change anything about the HTTP wire protocal? Are there headers?
08:19:43 [Vlad]
ack drott
08:20:02 [myles]
Garret: No. It's pure, normal HTTP. No preflights for the custom header. Don't have to use POST (to avoid preflights)
08:20:45 [myles]
chris: So we don't need query any more?
08:20:45 [myles]
Garret: Correct.
08:20:45 [myles]
drott: This is better for proxying, where proxies don't forward the headers right
08:21:17 [myles]
Garret: This makes it much more predictable for caching, since whatever set of files you form, you can do it in a way that's compatible with how you want to cache them
08:21:17 [myles]
Garret: if you want to make sure that some subset is always available, you can do so
08:21:17 [myles]
q+
08:22:22 [myles]
Vlad: Consider a user looking at the page that's dynamically updated. Those dynamic updates generate requests. If a second user joins the page at the same time, can you trace the graph to determine what the state of the incremental font should be?
08:22:22 [myles]
Garret: If you had a dynamic implementation, you could restart someone somewhere else in the graph
08:22:22 [myles]
Vlad: could the server do it in the background?
08:22:22 [myles]
Garret: yes. You'll probably watch what's being requested, and make that available as a static URL. And you could change that over time.
08:22:24 [myles]
Garret: But with a static one you wouldn't do that
08:22:48 [drott]
myles: don't the urls have to be baked into the font?
08:22:58 [myles]
Vlad: If you have the graph generated as you update the font, you could update the static subset to make it larger
08:23:00 [drott]
garret: when you serve the files, you can update them
08:24:30 [horo]
horo has joined #webfonts
08:24:35 [drott]
myles: in the "dumb server" approach - there's the initial request, then following one: what's the sequence relationship?
08:25:05 [drott]
garret: there's a graph: from the first one, you can get to the next layer - the first point will point to the additional fonts
08:25:17 [drott]
myles: I would compute the optimal way through the graph?
08:25:26 [drott]
garret: you only see the next layer
08:25:43 [drott]
myles: what if I need to fetch multiple sets from the next layer?
08:25:55 [drott]
garret: that's the issue of parallel downloads I'll talk about later
08:25:57 [myles]
Garret: one thing I want to point out: for CJK, this is a lot more challenging. But this scheme works well in the non CJK space. Imagine full extended latin font (with diacritics)
08:26:59 [myles]
Garret: You get the initial font which just has ASCII. Beyond that, you probably only need 1 subset. Like, Polish can be one patch, and Vietnamese can be another patch. With a good segmentation, you can probably get what you need in 1 hop, maybe 2
08:26:59 [myles]
Garret: There are ideas of parallel downloads.
08:27:19 [myles]
Garret: Let's talk about the parallel case
08:27:36 [myles]
Garret: The typical non-CJK use cases, the parallel cases are not important. But let's try to solve it for CJK
08:28:14 [drott]
q+
08:28:26 [myles]
Garret: If we have the option to be backed this dynamically, we could have an optional feature to have hte client create a merged url. There could be a URL template, and the client could concatenate multiple identifiers. You'd need a dynamic server. But the client could get X out of Y subsets and get them all in a single patch
08:28:28 [myles]
q-
08:28:46 [drott]
q-
08:29:16 [myles]
Garret: The other approach is more useful for static serving. The way we serve fonts today is we would break them up to actual subsets and use unicode range to have the browser pick the ones it needs. Depending on how you cut that subsets, you can break layout rules between 2 characters. Most fonts can still be split up to some degree without breaking anything. Usually there are independent chunks.
08:30:01 [myles]
Garret: So, before you apply this graph subset thing, you could break up the font as much as possible without affecting layout rules. This has a positive impact on reducing the size of the graph. If you can split the font into 3 pieces, it's a huge divider on the total number of graph nodes you need. This works well for CJK, where most CJK fonts will be fairly aggressively subdivided without breaking anything
08:30:52 [drott]
q+
08:31:00 [myles]
Garret: Especially for the CJK parts. So you could have a hybrid solution where you chunk the font into chunks, then use augmentation within the chunk to get what you need. Ideally it would work better than pure unicode-range. This helps with parallelization. Also, the different chunks can be downloaded in parallel. If you choose chunks intelligently you should get pretty good performance
08:31:41 [Vlad]
ack drott
08:31:44 [myles]
drott: You are suggesting an approach where an element of dynamic generation of the URLs, where you have something like tags, and to form a URL you would combine multiple tags
08:31:56 [myles]
Garret: Yes. That's similar to current patch subset. It's just forming a regular URL. No custom headers.
08:32:02 [myles]
Garret: Purely optional.
08:32:31 [myles]
drott: It depends a little bit how you would define what's in the table and how you navigate from one layer to the next. One approach there is to ... generally that table would be a definition of ranges. or sets of codepoints (how to get from one layer to the next)
08:32:59 [myles]
drott: If the ranges can be overlapping, there would be an argument for choosing which overlapped set to use, you could express the same thing with that
08:33:43 [myles]
Garret: I should have mentioned that. It's legal to have sets that are supersets of other ranges (or overlapping). You might get too many entries, though. 2^n where n == 100
08:33:43 [myles]
Garret: If you have a good idea of what's common, you can stick some common ones in there
08:33:43 [myles]
q+
08:34:16 [myles]
Garret: originally I talked about it as a map from a subset to a URL. But you'll probably have a header saying "here is some number of URL templates, and here is where you can substitute identifiers into it". This is mostly for performance reason. You have a set of URLs with a common prefix, you don't want to repeat that hundreds of times in the font table
08:34:23 [myles]
drott: It's a tradeoff between complexity and granularity.
08:35:21 [drott]
myles: first request must include rules that cover anything in the entire font?
08:36:07 [drott]
Garret: first request doesn't have to give you all layout rules? it gives you a font with a basic set, common CJK set? in a latin oriented font, core ASCII - enough to get you started. As you patch in, you'll get more layout data.
08:36:49 [drott]
Garret: it covers all data, not table- or format- specific.
08:37:34 [chris]
q+ to ask about axis-subsetted variable fonts
08:38:03 [Vlad]
ack myles
08:38:03 [drott]
myles: in the first response - there must be rules for how to fetch the rest of the font?! The font file tells me I need to download two different things.
08:38:13 [drott]
myles: you say, I can don't download them in parallel - but why?
08:38:35 [drott]
myles: I download two things in parallel - now I have to branches, one with 13, one with 17?
08:38:40 [drott]
myles: what do I do?
08:39:11 [jimmym]
jimmym has joined #webfonts
08:39:11 [drott]
Garret: that's why I am saying parallel downloads would be a problem
08:39:18 [drott]
myles: So I download the one that has the 13, and this one would tell me where do I download the next ones?
08:39:18 [drott]
Garret: yes
08:39:35 [drott]
Garret: so that's why I was proposing you start with a set of splits defined by unicode-range
08:40:10 [drott]
myles: and the other option, as I mentioned: forming sets / merged requests
08:40:43 [drott]
^ was Garret:
08:40:43 [Vlad]
ack chris
08:40:43 [Zakim]
chris, you wanted to ask about axis-subsetted variable fonts
08:41:16 [myles]
chris: supposed you had a variable font that was subsetted down. Could you use this mechanism to say "actually i just want a single weight"?
08:41:16 [myles]
Garret: yes. When I say "code points" what i actually mean is general subset. That's a benefit of this: it can deal with the variation stuff.
08:41:16 [myles]
chris: I think that dealing with very large many-axis variable fonts is important
08:41:16 [myles]
Garret: I agree. that needs to work.
08:42:26 [myles]
Garret: Imagine you have a font and you don't even care about the code points - you can use this just to instance
08:42:26 [drott]
q+
08:42:26 [myles]
Vlad: That's something else we need to discuss. If you want to do the same thing with another approach, it has to be specified. You can't expect people to know what the next part of the discussion.
08:42:26 [myles]
Garret: I raised a comment on skef's draft. "What do you want to do with variable fonts? probably something"
08:43:30 [Vlad]
ack drott
08:43:30 [RodS]
q+
08:43:30 [myles]
drott: If I understand right, you're suggesting a new key type for requesting the next url. If you thought about unicode range, there are code points. It's clear to the browser which code points are missing. But for variable fonts, you don't havea that information from the CSS perspective. Initially you'd need to know which axes exist, even if the first font doesn't have support for these axes.
08:43:33 [myles]
drott: Then there has to be a way for the browser to request a range of the present axes
08:43:49 [myles]
drott: So CSS needs something. "What is the active set of axes for this font"
08:43:50 [myles]
drott: So when this interacts with font-variant that uses these axes....
08:45:09 [myles]
Garret: The information that comes back with the first font request, it says "this is what's available of the entire font". We'd need to do something similar here. Variation space is defined in fvar.
08:45:13 [drott]
myles: the initial font doesn't have a full cmap - similarly, it wouldn't have full fvar
08:45:22 [drott]
myles: so we'd need the possible wider fvar in the new table
08:45:34 [myles]
Garret: The browser then says "i'm attempting to render a font at this point in the variation space, so i'm going to request what i need"
08:46:02 [myles]
Garret: Browsers will say "these are the instances that i'm attempting to render at. Go fetch what I need"
08:46:14 [myles]
drott: Consider font synthesis for italics. It's tricky. You don't know what the font has.
08:46:58 [myles]
drott: If you assume every patch subsetted font has all the variations, then you might be wrong, but you won't notice that you're wrong until the request came back
08:47:18 [myles]
drott: The original request will return information about the variation space. You could ship a skeleton fvar table (slimmed down)
08:47:36 [myles]
drott: This is the visibility of transitions of the graph where you can go
08:48:01 [Vlad]
ack RodS
08:48:16 [myles]
RodS: Question: Could you assemble it so that you do have patches which could be applied arbitrarily? If you wanted, it might actually be possible to apply 2 independent patches
08:48:34 [myles]
RodS: You could be able to build something like "i'll ship you a 0d glyph an patch in pieces of it"
08:48:59 [myles]
Garret: You lose properties about not caring about the font format
08:48:59 [myles]
RodS: You'd want it on the table for CJK
08:49:09 [myles]
RodS: It might be possible.
08:49:32 [myles]
Garret: The patch type is a content encoding. There could be more than one. There could be one that annotates itself that is able to apply multiple patches to the same thing
08:49:43 [myles]
Garret: In the CJK case, that actually probably is possible
08:49:49 [myles]
Garret: You'll need a custom patch format
08:50:08 [myles]
RodS: if you don't reference the shared parts, it might be possible
08:50:24 [sergeym]
q+
08:50:28 [myles]
Garret: it relates to the work i did last year about a custom brotli encoder. I limited the dictionary of the window that the encoder could see, to form my own diffing logic
08:50:29 [myles]
q+
08:50:40 [RodS]
I may have misspoke, but ^ should be if you don't modify the shared parts as you apply patches
08:51:19 [Vlad]
ack sergeym
08:51:19 [myles]
Garret: That might be do-able
08:51:23 [myles]
sergeym: I was making sure that patch can be applied independently of everything else. I want to save space. Specifying the patch can be applid universally, you can make it part of the patch, and you can do it without changing the font. This is not what we have, but it's already applied.
08:52:00 [myles]
sergeym: If there is a patch that is applied, and the patches are different, but 2 patches may have a large part big part in common. Outlines are independent, but other parts are different, then you can save on download.
08:52:40 [drott]
myles: the direction this conversation was going: being able to be applicable 2 patchsets independently
08:53:15 [drott]
myles: it would be useful, and similar to something i had in mind with initial proposal / range request
08:53:36 [drott]
myles: the encoder can make flexible decisions - is my claim
08:53:49 [drott]
q+
08:53:56 [drott]
ack myles
08:54:25 [drott]
myles: this is were I experimenting with patch subset - getting to a point where independent patches would work in parallel
08:54:39 [drott]
myles: we are not tied to brotli, if there's a different compressor that can do this
08:55:01 [Vlad]
ack drott
08:55:45 [myles]
drott: If we want to design something where we can apply multiple patches in parallel, assuming we're still on brotli, we'd need to define segment boundaries. There would be only parts visible to the decoder and encoder that the data is based on. In many of these situations we end up defining segments that are dependent on knowledge about the font format. At least on the sfont level, we'd need to define ranges
08:56:03 [myles]
drott: I'm a bit concerned that we shouldn't get into the space where we are closely dependent on the font format
08:56:20 [myles]
drott: I think you need to be aware of at least the loca table. you need to be able to stick glyphs in good places relative to other glyphs. You need the loca table.
08:56:40 [drott]
myles: loca and cmap together - as loca itself woudn't be useful
08:56:59 [myles]
myles: loca and CMAP
08:57:15 [myles]
Garret: If this solves the CJK problem, it might be a better tradeoff. It's worth investigating a fancy encoder. We'd want to look at as few parts of the font format as possible
08:57:21 [myles]
drott: Then we're already in fvar, to an extent
08:57:34 [RodS]
q+
08:57:48 [drott]
myles: if you have a smart server, you can treat it all as bytes
08:58:10 [drott]
myles: if you want a static / pre-computed set - you need make good files by looking at the font format
08:59:24 [drott]
myles: there's two different levels of requirement - "must-level" requirement - and a set of requirements for getting good performance
08:59:25 [myles]
Garret: If we had a font-specific encoding, it could be a separate document
08:59:35 [myles]
myles: or an appendix
08:59:38 [myles]
Garret: yes
09:00:59 [myles]
Vlad: we need to be more generic than that
09:01:22 [myles]
Vlad: if you want to subset along the variation axis, for something that would enable one font out of a colleciton, then you might... these generic recommendations would be appropriate. Anything else about specific subsets guided by content
09:01:41 [drott]
myles: content related things shouldn't be in the set
09:02:09 [drott]
myles: language related things can be in the spec - like a recommendation for which are the most common chinese and where to put them
09:02:59 [myles]
Garret: It may be possible to do this without knowledge of the font format, but i think it's necessary
09:03:39 [myles]
drott: If we break things up by things in the font format that are unlikely to change, or well-established, but that's fine. But if we go to subtable-level of particular tables, then we are creating a dependency which makes it more difficult to evolve the font format
09:03:45 [myles]
drott: loca and CFF are unlikely to chnage
09:03:59 [myles]
s/CFF/CMAP/
09:04:27 [myles]
Garret: behdad is proposing cubic glyphs, but that might not be affected
09:05:06 [myles]
Vlad: to be font-format independent, all we need to do is to say "here is an external document that determines font format. A subsetter should be able to read a font file and produce a subset that is conformant with that document.
09:05:17 [myles]
Vlad: The internal working of the subset would not be in-scope.
09:05:56 [myles]
Garret: If there was a new patch encoding, imagine you have a font and you have inserted some number of glyphs, you don't know which ave been inserted, how do you encode a patch which builds on top of it? it needs to know what's already there.
09:06:03 [jimmym]
jimmym has joined #webfonts
09:07:47 [jimmym]
FYI: TPAC break time is 11-11:30 (started 7 minutes ago). If anyone needs coffee, snack, bathroom it's out the door next to the registration desk on 1st flooe.
09:07:51 [myles]
Vlad: for a client, you have to know what is the original font. When you ask for a font, you don't know what's in there, until it's finished downloading. This concern is about an independent patch. If you have 2 patches, and you want to apply them in either order, the patch decoder needs to have knowledge about "go look in loca, then change the bytes that it points to"
09:08:21 [myles]
RodS: you could go back to tachyfont. You could choose to use it in a model where you say "my initial skeleton has a long empty glyf table, and my patches fill it in"
09:08:38 [myles]
Garret: That would solve the problem
09:08:59 [myles]
RodS: It seems at least possible to do this at the byte-level
09:08:59 [myles]
Garret: If you fix the addresses of all the byte data, it might be possible
09:35:21 [Garret]
Garret has joined #webfonts
09:36:03 [RodS]
RodS has joined #webfonts
09:41:54 [jimmym]
jimmym has joined #webfonts
09:42:17 [myles]
ScribeNick: RodS
09:42:43 [chris]
q?
09:43:17 [Vlad]
q?
09:43:17 [Vlad]
ack RodS
09:43:17 [chris]
ack RodS
09:43:17 [drott]
Rods: I believe we're suggesting serial bootstrapping - root font, + things that you can go and get. that means there'll be two roundtrips
09:43:49 [drott]
RodS: Could we move some of that to CSS - place the initial fan-out there? So we'd avoid the extra roundtrips?
09:44:20 [RodS]
Garret: agrees the mapping could be in CSS, worth exploring
09:44:35 [RodS]
Garret: just declaring what's in subset and a way to get a url
09:45:24 [RodS]
(discussion of filing GH issues, consensus we will)
09:45:35 [RodS]
Garret: Garret will investigate independent patch encoding, brotli or otherwise
09:46:45 [RodS]
Garret: Investigate the map to subset available outside the font, such as CSS, to get the client started quicker
09:46:45 [drott]
q+
09:46:52 [RodS]
Garret: no spec proposal yet so many of these things will come up as we write real specese
09:46:52 [RodS]
drott: perhaps also overlapping ranges vs merged?
09:46:56 [RodS]
Garret: we should at least note it's allowed
09:47:07 [RodS]
Garret: might be useful outside CJK, you need several things together
09:48:19 [RodS]
Garret: we've talked about parallelism, second issue, somewhat related
09:48:24 [RodS]
Garret: we have a graph where at each step you can take multiple paths, it can get big. 10 pieces as a full graph with every possible traversal yields ~300k paths so there is work to do to reduce that.
09:48:38 [RodS]
Garret: independent patching may be useful here, sometimes you can grab in any order
09:48:59 [RodS]
Garret: furthermore, we can pre-split the font at safe points (editorial: where layout isn't damaged)
09:49:06 [chris]
q+
09:49:23 [RodS]
Garret: if you are using dynamic serving you have the option to not pre-generate some
09:49:28 [RodS]
Chris: what's presplitting?
09:49:54 [RodS]
Garret: 10 pieces naively is 9!. If you can cut the initial font in half it's 4! + 4!, which is dramatically smaller.
09:50:17 [RodS]
Garret: For example, a latin+arabic font might be amenable to splitting
09:50:38 [RodS]
Garret: independent patching could be game changing here
09:50:40 [chris]
ack chris
09:51:00 [RodS]
Garret: lastly, why do this vs iftb
09:51:42 [drott]
q- (I had said what I wanted to say)
09:51:45 [drott]
q-
09:51:46 [RodS]
Garret: the key advantage is it's not just outlines that get cut up. Outside CJK outlines are not the dominant user of space. Variable fonts, complex layout (editorial: ex Arabic and Indic), etc
09:52:38 [RodS]
Garret: that's my pitch! Early stages, I think next steps are a more formal proposal. We can adopt much of the patch subset text, dump some, likely reuse sparse bitsets to specify codepoint subsets.
09:52:52 [RodS]
Garret: Nice to keep some of the work we've done to date :)
09:52:59 [myles]
q+
09:53:08 [RodS]
Vlad: does anyone have concerns with the proposed approach?
09:53:39 [RodS]
Garret: +1, reasons to NOT go down this path?
09:54:21 [RodS]
Chris: I understand the goal to have good caching. I worry improving caching means worse perf for the individual users. Instead of getting exactly the bits they want they have to do work. We're making a tradeoff and we shouldn't push it too far.
09:54:21 [RodS]
Chris: if it's too degraded nobody will use it, akin to the conventional wisdom of "No CJK webfonts" (editorial: in the past)
09:55:17 [RodS]
Garret: I think you can still have fine grained segments
09:55:17 [RodS]
Chris: We have a dial to turn, this reduces my concern here
09:55:17 [RodS]
Garret: Agrees, that's a good benefit
09:55:25 [RodS]
Myles: speaking with someone who serves fonts they said cacheability was deal-breaking, if it's bad they cant' use this
09:55:59 [RodS]
drott: if you think about self hosting it's a big step to go static => dynamic, suddenly load spikes, slashdotted etc becomes hard
09:56:32 [RodS]
Myles: we discussed cutting up by characters, or ranges of variation axes (subspaces). Mentioned it's unfortunate to compute glyph closure. Could we have a third way, glyph by glyph.
09:56:49 [RodS]
Garret: worth thinking about. Being able to do subsetting after glyph closure is beneficial for some fonts.
09:56:56 [RodS]
Myles: for some fonts
09:57:04 [RodS]
Garret: indeed, for example icon fonts.
09:57:15 [RodS]
Rod: emoji too
09:57:26 [drott]
q+
09:57:29 [RodS]
Garret: codepoints don't work too well in that case
09:57:38 [myles]
ack myles
09:57:38 [RodS]
Myles: maybe it's not worth the complexity
09:57:50 [RodS]
Garret: worth thinking about, will file another issue
09:58:10 [RodS]
drott: when we break up by axes we need new algorithms to integrate that with the UA, when should it do that?
09:58:22 [RodS]
Myles: ...and glyph ids might shift...
09:58:37 [RodS]
(discussion of fixing glyph ids)
09:58:53 [RodS]
Chris: impact on rendered glyph caching?
09:59:12 [RodS]
drott: a new font probably drops any such cache
09:59:24 [RodS]
drott: perhaps we could optimize that, probably not in a first implementation
09:59:54 [RodS]
Myles: we'd need a new algorithm ... that's true, to do shaping you need the rules but not the glyphs
10:00:14 [drott]
s/we break up by axes/we break up by axes or gid's or new concepts other than codepoints/
10:00:34 [RodS]
Rod: reintroduces serialization
10:00:49 [RodS]
Myles: first horizon agrees on gids
10:01:24 [drott]
RodS: if we declare the initial fan/horizon in CSS - ...
10:01:58 [RodS]
then we don't have to do serial requests on startup
10:02:17 [drott]
myles: it's a little bit scary - as it becomes font-format / technology specific
10:02:42 [RodS]
myles: if they just point to a font and don't turn on the new stuff ... it won't quite work
10:03:02 [Vlad]
ack drott
10:03:25 [RodS]
chris: should we resolve to proceed?
10:03:51 [RodS]
(consensus we do)
10:04:35 [RodS]
garret: suggests a draft PR with updates
10:04:35 [RodS]
vlad: suggests we explicitly accept the proposal and decide to proceed with evaluation, drafting spec changes
10:04:57 [RodS]
vlad: opening vs closing the door
10:05:01 [RodS]
myles: lets be explicit this is *instead* of the prior path
10:05:35 [RodS]
vlad: back when we had iftb initially presented we discussed it replacing range request. We never formalized elimination of range request.
10:05:45 [RodS]
myles: I thought we did
10:06:17 [RodS]
vlad: we didn't capture in writing, so the second resolution I would like to make is that range request is replaced.
10:06:20 [myles]
myles has joined #webfonts
10:06:20 [RodS]
myles: concurs
10:06:46 [RodS]
RESOLUTION: RESOLVED
10:08:49 [RodS]
RESOLVED: replace range request with a more static friendly approach
10:08:54 [RodS]
RESOLVED: draft specification for a static-friendly patch subset mechanism
10:09:42 [RodS]
RESOLVED: Garret shall come up with a cool acronym
10:10:09 [RodS]
Garret: should we move on to next agenda topics? e.g iftb
10:10:20 [RodS]
Vlad: Hard to discuss iftb w/o skef
10:10:38 [RodS]
Garret: should we give an overview, review concerns, etc?
10:10:43 [RodS]
Chris: would find ^ useful
10:11:15 [RodS]
Vlad: can we share the PR on screen?
10:12:19 [RodS]
(discussion veers toward conformance testing)
10:12:35 [RodS]
Garret: perhaps there is no server conformance now
10:12:46 [RodS]
Vlad: maybe just sample responses a client should handle
10:13:43 [RodS]
Garret pulls up a PR!
10:13:59 [Garret]
Link to preview of the IFTB PR: https://pr-preview.s3.amazonaws.com/skef/IFT/pull/151.html
10:14:53 [RodS]
Garret: Skef worked to develop an alternative to range requests that avoids CORS preflight
10:15:43 [RodS]
Garret: also, range request downloads the file up to glyph data then stops the connection. Http and browser people suggest this is not good behavior. IFTB tries to focus instead on static files and take advantage of http/2 efficient multiplexing of many requests on a connection.
10:16:19 [RodS]
Garret: you take the glyphs in the font, bin them, map from glyph id to bin index, and each bin has a file on the server
10:16:36 [RodS]
Garret: uses the old trick of zeroing glyf which then transfers efficiently
10:17:10 [RodS]
Garret: client resolves text to glyph ids, figures out what urls to fetch, then merges the chunks into the font
10:17:57 [RodS]
Garret: introduces a new opentype tag to indicate special handling required, just ordering and the new glyph mapping table. IFTB defines a chunk format, a header in front of glyph data.
10:18:15 [RodS]
Garret: There is also a map from layout features to additional bins, e.g. small caps might have a bin or bins
10:18:26 [RodS]
Garret: (possibly oversimplifying)
10:18:53 [RodS]
Garret: and that's the gist of it! You figure out what chunks you need, fetch, and integrate into the font.
10:19:24 [RodS]
Garret: This is effectively a subset of the proposed mechanism. If we can have independent patches we can fold the ideas together.
10:19:44 [RodS]
Chris: the whole handshaking, how to decide what method, etc business goes away?
10:19:45 [RodS]
Garret: yes
10:19:59 [RodS]
Garret: we would have a format or tech keyword, just one
10:20:29 [RodS]
Garret: we should demonstrate it, but I believe we can match IFTB from a perf perspective
10:20:42 [RodS]
Garret: I worked with Skef to make a demo of IFTB
10:21:09 [RodS]
Garret: no public url but code is on GH
10:22:06 [RodS]
Garret: in demo IFTB is using wide chunks so it performs similarly to unicode-range. Smaller chunks might help. ALso the skeleton has a number of things where you pay per glyph, hmtx, etc.
10:22:48 [RodS]
Garret: There are opportunities to further tune, but I think we would land somewhat better than unicode-range, significantly worse than patch/subset.
10:23:22 [RodS]
Chris: demo shows perf but not impacts on rendering fidelity
10:23:25 [RodS]
Garret: good point
10:23:35 [RodS]
Garret: does show it works, client implementation wasn't too bad
10:24:25 [RodS]
Garret: That's an overview, is there anything we should talk about now? It's a bit difficult w/o Skef
10:24:51 [RodS]
Vlad: it will be helpful to compare side by side with the proposed update, maybe we can reduce to one mechanism
10:25:10 [RodS]
Vlad: important to keep the dial of using finer buckets for higher performance
10:25:31 [RodS]
Vlad: even if that was less cache friendly
10:25:59 [RodS]
Garret: last thing to discuss is conformance
10:26:13 [RodS]
Vlad: Lunch is in 30 minutes, early lunch and then we discuss conformance testing?
10:26:18 [RodS]
(the room is pro-lunch)
10:26:33 [RodS]
(discussion of what to have for lunch)
10:28:11 [jimmym]
FYI: TPAC break time is 11-11:30 (started 7 minutes ago). If anyone needs coffee, snack, bathroom it's out the door next to the registration desk on 1st flooe.*
10:28:14 [jimmym]
oops
10:28:22 [jimmym]
(*dinner) was what I meant to type
10:29:07 [jimmym]
Vlad proposes https://restaurantehummo.com/
10:35:42 [Vlad]
The meeting will resume after lunch break at 14:30 CET
10:38:00 [RodS]
RodS has joined #webfonts
10:40:43 [RodS_]
RodS_ has joined #webfonts
11:35:47 [myles]
myles has joined #webfonts
12:12:40 [Zakim]
Zakim has left #webfonts
12:34:41 [jimmym]
jimmym has joined #webfonts
12:35:34 [Garret]
Garret has joined #webfonts
12:35:55 [RodS]
RodS has joined #webfonts
12:36:49 [Vlad]
Vlad has joined #webfonts
12:37:03 [chris]
chris has joined #webfonts
12:37:10 [chris]
rrsagent, here
12:37:10 [RRSAgent]
See https://www.w3.org/2023/09/12-webfonts-irc#T12-37-10
12:38:11 [chris]
present+
12:42:59 [Vlad]
present+
12:43:02 [RodS]
present+
12:43:27 [RodS]
(some discussion of conformance, use of woff2 test suite or inspiration)
12:43:50 [RodS]
Myles: we need to deal with the css font loading (javascript) API and how it should handle IFT
12:44:06 [myles]
Myles: it is a requirement for the test suite to function
12:45:07 [RodS]
vlad: as we put normative (must/must not) statements into the spec we need to define how to test each one
12:45:46 [myles]
q+
12:46:06 [RodS]
garret: we've already started marking spans with test ids so we can begin to ensure those tests actually exist. Must remember to do this in the modified spec too.
12:47:13 [RodS]
myles: Trying to imagine the test suite. We could make a lot of fonts, constellation of files with links, test suite could verify augmentation goes from file to file and detect sentinel data ... fine. Makes sense. Doesn't test smart server; do we need to?
12:47:41 [RodS]
garret: from the specs perspective it doesn't matter, just urls with responses
12:47:59 [RodS]
myles: test suite is conceptually clear then
12:48:11 [RodS]
garret: no smart server in spec simplifies considerably
12:48:40 [RodS]
vlad: woff2 took ~2 years to completion and then 3 more for conformance test suite
12:48:47 [RodS]
garret: would prefer not to wait that long
12:49:09 [RodS]
vlad: and after conformance of woff2 was done we had to wait for second implementation
12:49:18 [RodS]
garret: hopefully we can be faster
12:49:44 [RodS]
rod: what second implementation?
12:49:54 [RodS]
garret: Chrome and hopefully one more user agent
12:50:09 [RodS]
myles: cannot comment on future products or releases
12:50:16 [RodS]
garret: we will ping Mozilla too
12:50:33 [RodS]
vlad: woff2 had many browsers but they all shipped one library, the Google reference implementation
12:51:06 [RodS]
(discussion of whether an open source implementation that is reused counts; consensus not)
12:51:40 [RodS]
garret: perhaps it's not a browser as the second implementation
12:52:07 [RodS]
rod: for brotli we just paid to have a second implementation written from the spec
12:52:47 [RodS]
chris: Mozilla has a repo where you can ask for standards positions
12:52:59 [myles]
https://github.com/WebKit/standards-positions
12:53:06 [RodS]
(discussion of seeking Mozilla involvement in IFT in general)
12:53:49 [RodS]
garret: we won't seek formal positions quite yet, need to advance new work identified today
12:54:03 [RodS]
garret: testing concerns are DONE
12:54:33 [RodS]
vlad: perhaps we can quickly go through open issues and close range request issues if they no longer apply
12:56:03 [RodS]
Closed https://github.com/w3c/IFT/issues/110
12:56:25 [RodS]
https://github.com/w3c/IFT/issues/109 retained
12:56:50 [RodS]
https://github.com/w3c/IFT/issues/74 closed
12:57:17 [RodS]
https://github.com/w3c/IFT/issues/79 closed
12:57:45 [RodS]
https://github.com/w3c/IFT/issues/67 closed
12:58:23 [RodS]
https://github.com/w3c/IFT/issues/61 closed
12:59:00 [RodS]
https://github.com/w3c/IFT/issues/60 closed
12:59:11 [RodS]
https://github.com/w3c/IFT/issues/59 closed
12:59:46 [RodS]
https://github.com/w3c/IFT/issues/58 closed
13:00:02 [RodS]
https://github.com/w3c/IFT/issues/34 closed
13:01:16 [RodS]
is https://github.com/w3c/IFT/issues/101 Shared Brotli ID is expired still relevant?
13:01:30 [RodS]
garret: it has an incomplete section that may not be complete soon
13:01:53 [RodS]
(compression jokes)
13:02:12 [RodS]
garret: will followup with them about perhaps finishing this and publishing w/o the missing content
13:02:26 [RodS]
(further compression jokes)
13:03:50 [RodS]
https://github.com/w3c/IFT/issues/103 is valid in as much as it covers css font loading but it's not entirely obvious, needs either cleanup or closing in favor of a new issue. Garret will take care of it.
13:04:43 [RodS]
garret: TAG had some discussion, I will update them with new current state. Hopefully some commenters will be pleased.
13:04:59 [RodS]
garret: issues complete!
13:05:34 [RodS]
vlad: and that brings us to the TAG review comments
13:05:43 [RodS]
vlad: two main issues
13:06:01 [RodS]
vlad: 1) making our implementation more cache friendly, which is in flight with Garrets proposal
13:06:56 [RodS]
vlad: 2) font-specific solution shouldn't be a deal breaker, not being generic enough shouldn't block
13:07:32 [RodS]
vlad: woff1 opened the door to web fonts and showed the value of font specific tech, leading to woff2
13:07:32 [RodS]
garret: I see a strong argument for font-specific IFT
13:07:58 [RodS]
vlad: would like to proceed with a cache-friendly model, and not block on need for smart server
13:08:06 [RodS]
garret: spec will no longer require a smart server
13:08:20 [RodS]
garret: also not using custom headers, http extensions
13:08:33 [RodS]
garret: client *does* have to understand fonts and know how to interact with themn
13:09:08 [RodS]
chris: the domain-specific knowledge is key to making it a *lot* smaller
13:09:29 [RodS]
vlad: serving incrementally is about usability. You might server the whole thing but in increments.
13:09:41 [RodS]
garret: broken subsets are common today, this fixes them
13:09:55 [myles]
q+ to ask a tangential question
13:10:35 [RodS]
(See https://github.com/w3ctag/design-reviews/issues/849 discussions)
13:11:57 [RodS]
myles: in the old model the font creator doesn't have to know about serving, just hand it over and it may get chopped up ... it's fine. So, what is the deliverable from creator to the customer who hosts the font?
13:12:41 [RodS]
myles: how do folks make the set of files they need, would the creator establish a set of files?
13:12:49 [RodS]
garret: relative urls help
13:13:06 [drott]
q+
13:13:13 [RodS]
garret: you get a set of files
13:13:26 [RodS]
garret: and you can upload them. Perhaps there's a simple open source cli that does it.
13:14:21 [RodS]
rod: I imagined it with the public cli, you run it and get some files you can uplaod to a cdn or w/e
13:14:21 [RodS]
drott: did you see the responsibility for segmentation falling on the font creator or ...?
13:14:42 [RodS]
drott: if there is a cli tool it's largely a question of licensing, are you allowed to slice and dice
13:15:28 [RodS]
myles: right now font files have no urls, the urls are in css. What if, as brought up earlier, the extra info wasn't in the font, it was in css or on the server on it's own.
13:15:59 [RodS]
(discussion of this, how it might work to avoid baking urls into the font)
13:16:15 [RodS]
myles: we have two populations, one very comfortable with urls and another less so
13:17:17 [RodS]
garret: you could bake identifiers in but not actual urls, those go outside, say a pattern in css
13:18:01 [RodS]
drott: if you consider dynamic generation with urls that might have security implications
13:18:29 [RodS]
chris: we had a notion of overdelivering to reduce fingerprinting and tracking before, how does that fit now?
13:19:13 [RodS]
garret: might need a minimum chunk size on the client side. Maybe it's invalid to declare on single character urls.
13:19:23 [RodS]
myles: or the UA over-fetches
13:19:45 [RodS]
garret: single char per url is probably over-granular
13:20:32 [RodS]
myles: if I need two patches maybe I don't always take the patch with the most codepoints, but that fights against caching.
13:20:45 [RodS]
garret: if we can have independent patches the graph shrinks
13:21:09 [RodS]
myles: it's still not a tremendously satisfying answer
13:22:35 [RodS]
(some discussion of how this compares to unicode-range which also allows specification of url per codepoint)
13:23:02 [RodS]
garret: still thinking in the same general direction, client should reduce granularity. We simulated and this seemed effective.
13:23:40 [RodS]
myles: do you have numbers wrt how many fragments for file?
13:24:14 [RodS]
garret: if the patches are independent ... today we use 100ish for CJK on Google Fonts, maybe you'd go a bit higher but not dramatically.
13:25:16 [RodS]
myles: average chain length would be interesting as well, esp for CJK content
13:25:16 [RodS]
garret: simulation should be able to help here
13:25:16 [RodS]
garret: interesting beyond cjk, if you broke up by say language is the chain often 1
13:25:57 [RodS]
rod: seems like we need to try it
13:26:31 [RodS]
myles: excited about potentially having independent patches, that largely solves CJK
13:26:40 [RodS]
garret: I have an idea for how to do that
13:27:06 [RodS]
myles: glyf full of zeroes isn't necessarily awesome, requires compression to be useful
13:27:11 [RodS]
garret: I think we can do better
13:27:14 [RodS]
(so do Rod and Myles)
13:28:32 [RodS]
garret: as Skef remarked, this is made or broken by a good encoder
13:28:36 [RodS]
rod: hopefully that's a win, we improve the encoder and don't have to update clients, etc
13:28:58 [RodS]
garret: closing remarks?
13:29:19 [chris]
rrsagent, make minutes
13:29:20 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/09/12-webfonts-minutes.html chris
15:36:18 [RodS]
RodS has joined #webfonts
16:12:29 [RodS]
RodS has joined #webfonts