17:15:56 <RRSAgent> RRSAgent has joined #webfonts
17:15:56 <RRSAgent> logging to https://www.w3.org/2022/09/13-webfonts-irc
17:15:59 <emilio> emilio has joined #webfonts
17:16:04 <Vlad> zakim, start meeting
17:16:22 <Zakim> Zakim has joined #webfonts
17:16:27 <Vlad> zakim, start meeting
17:16:27 <Zakim> RRSAgent, make logs Public
17:16:29 <Zakim> Meeting: Web Fonts Working Group Teleconference
17:16:38 <Vlad> present+
17:16:55 <skef> skef has joined #webfonts
17:17:02 <grieger> grieger has joined #webfonts
17:17:04 <Vlad> Regrets: Bianca Berning
17:17:07 <grieger> present+
17:17:10 <skef> +present
17:17:17 <skef> present+
17:18:22 <drott> drott has joined #webfonts
17:19:07 <drott> present+
17:23:29 <emilio> present+
17:25:05 <Vlad> zakim, pick a victim
17:25:05 <Zakim> Not knowing who is chairing or who scribed recently, I propose emilio
17:25:36 <emilio> Scribenick: emilio, reluctantly
17:25:44 <Vlad> scribenick: emilio
17:26:09 <emilio> skef: fonts are cached on the client side, is that just the font, or the incremental state of the font?
17:26:40 <Vlad> Topic: Data production, transmission & Ncaching
17:26:42 <emilio> grieger: not only the font but also the state of the incremental download
17:26:55 <Vlad> s/Ncaching/caching/
17:27:06 <emilio> skef: so we get a patch sent over, do a bunch of stuff to make a useful end client thing, what specifically gets cached and at what granularity?
17:27:44 <emilio> grieger: spec talks about this, not normatively, there's the current subset of the font, a few checks to check that everything lines up, and the code points that are in the original font
17:28:06 <emilio> ... the first response from the server returns a full list of code points of the original font
17:28:33 <emilio> jhudson: original font as in?
17:28:45 <emilio> grieger: the full font with all the code points, that's the term in the spec
17:29:09 <emilio> skef: if you think of it as client state it makes sense but if you want to package it in let's say a zip file...
17:29:21 <emilio> ... I'm wondering the benefits of putting the state on its own table
17:29:39 <emilio> grieger: so the subset font would have an extra table?
17:29:54 <emilio> skef: yeah, I wonder why we don't do that
17:30:04 <emilio> grieger: the spec doesn't specify the binary storage format
17:30:11 <emilio> ... because it doesn't affect the protocol
17:30:22 <emilio> ... but it's an interesting idea, I think Adobe does something like that?
17:30:49 <emilio> skef: we do, but it seems more incidental on our case, but as I go through I came up w/ different arguments
17:31:05 <emilio> grieger: I think the tricky bits is the binary patches
17:31:12 <emilio> ... need to think about it a bit
17:31:28 <emilio> ... there might be extra state that the client might want to track
17:31:33 <emilio> skef: that's also a think with woff
17:32:08 <emilio> skef: the other thing is that the patch format and also the subset format (which we've left open, we just say "the subset is a font")
17:32:23 <emilio> ... I'm not sure the dual subsetting and patching is the only way of producing our binaries
17:32:57 <emilio> ... not a fan of the server side relying on total information where the font has to be completely known
17:33:08 <emilio> ... I'd be interested in a table-based exchange
17:33:30 <emilio> chris: you'd send all the tables together right?
17:34:15 <emilio> skef: yes, no extra roundtrips. IF we take a table-based patching approach, the client side would need to reconstruct the head table adjustments
17:34:28 <emilio> grieger: why it'd be better to general binary diffs?
17:34:47 <chris> chris has joined #webfonts
17:35:14 <emilio> skef: this would apply binary diffs on each table, I don't know why we'd need to calculate lengths and checksums for tables we don't care about
17:35:30 <emilio> grieger: isn't it a no-op with the brotli patching?
17:35:38 <emilio> skef: def. not a no-op, I mean offsets in the file I'm patching
17:35:53 <emilio> grieger: feels pretty minor, but maybe this is the thing where we make a proof of concept
17:36:06 <chris> present+
17:36:11 <chris> rrsagent, here
17:36:11 <RRSAgent> See https://www.w3.org/2022/09/13-webfonts-irc#T17-36-11
17:36:21 <emilio> skef: it might make a difference depending on how the server is constructed
17:37:04 <emilio> ... for the subset file (which we haven't talked about much) there's potential benefit to know that some tables don't change if you're doing GID preservation
17:37:16 <emilio> ... you could pre-compress those
17:37:30 <emilio> ... if there's a format that could be a version of the subsetting format if it's table specific
17:38:03 <emilio> ... another idea is, stare t woff for a while, including what we want for transferring of the subset of the font
17:38:28 <emilio> grieger: we had thought about running glyph transform of the font and it made a meaningful difference
17:38:42 <emilio> skef: you can still do that in the stream right?
17:39:01 <emilio> grieger: yeah, I wouldn't rule out table-specific encoding
17:39:33 <emilio> skef: woff2 allows you to compress tables e.g., if you have a gsub
17:39:40 <emilio> ... think of it of woff2.5i
17:39:45 <emilio> ... mostly like woff
17:39:58 <emilio> ... tables encoded with separate strings and different levels
17:40:13 <emilio> ... then you could use the same format for the patch set
17:40:23 <emilio> ... it'd just say this is a patch vs. a replacement
17:41:02 <emilio> grieger: in woff we had a per-table compression, but in the end woff2 we moved to the entire stream
17:41:27 <emilio> chris: it was more efficient to compress the whole stream, nobody did that
17:41:38 <emilio> Vlad: woff1 was thought with that request in mind
17:41:46 <emilio> skef: that shows there's a rationale for some of these things
17:41:52 <emilio> grieger: my main concern is complicating the protocol
17:42:09 <emilio> ... and if we do that we want it to be justified by metrics like performance
17:42:22 <emilio> ... specially with patch subset most tables are subjects to change
17:42:33 <chris> s/did that/did the per-table requests on woff1/
17:42:33 <emilio> ... even gsub and gpos will get trimmed down
17:43:01 <emilio> skef: you might do that intentionally, you might want to send the whole table
17:43:23 <emilio> ... when we put images on the web we don't always optimize for the min amount of transmission
17:43:40 <emilio> ... we put a lot of compute load on the server
17:43:52 <emilio> ... and we want to reduce it
17:44:12 <emilio> Vlad: I want to make sure to also consider complications in the client side, it should remain easy to use
17:44:27 <emilio> skef: protocol might look complex
17:44:39 <emilio> grieger: the protocol allows different patch types to be added
17:44:50 <emilio> ... maybe we could have a separate patch type
17:44:55 <emilio> ... that is aware of the per-table things
17:45:22 <emilio> Vlad: let's not forget, if we're talking about brotli we end up talking about woff2
17:46:05 <emilio> skef: I'm assuming the diff subset relative to the sfont
17:46:09 <emilio> sfnt*
17:46:35 <emilio> Vlad: first request will end up being a subset that would be converted to woff2 and sent
17:46:54 <emilio> skef: my understanding is that woff2 requires a level of brotli that we might not want
17:47:00 <emilio> grieger: there's no requirement on brotli level
17:47:22 <emilio> ... we trade off filesize and compute when doing dynamic subsetting
17:47:40 <emilio> skef: It'd be my preference to be able to store tables pre-compressed in the server
17:47:47 <emilio> ... woff2 doesn't give you that
17:48:00 <emilio> grieger: first request is brotli-compressed only, not woff2, just binary data
17:48:10 <emilio> ... might want to bring back some of those transforms
17:48:24 <emilio> skef: it seemed to me the font format on the subset was left open
17:48:31 <emilio> ... so you could send it down as opentype
17:48:46 <emilio> jhudson: at the moment,  what lives on the server is opentype right?
17:48:59 <emilio> grieger: reality dictates it because trying to patch woff2 would generate massive diffs
17:49:31 <emilio> skef: I was assuming that how it'd work is that you're sending subset as a woff but the woff specifies a reconstructed sfnt
17:49:41 <emilio> ... that tells you how to construct the opentype sfnt file
17:49:55 <emilio> ... so even if the download is transferred as a woff
17:50:06 <emilio> grieger: in the spec right now the patch is relative to the binary
17:50:14 <emilio> skef: so that precludes woff effectively
17:50:22 <emilio> grieger: does woff allow you to skip brotli compression?
17:50:33 <emilio> Vlad: I think there's a brotli thing to bypass it
17:50:45 <emilio> grieger: one option would be to use an uncompressed woff
17:51:33 <emilio> skef: the small confusion points to the fact that there's these different formats, and if you think of them as containers for tables then it all works, because we know what a table is, so you can go woff -> sfnt or the other way around or what not
17:51:47 <emilio> ... if you think of fonts, then it's probably an sfnt
17:52:01 <emilio> Vlad: if you think in terms of tables does it mean that you need to patch each table separately?
17:52:12 <emilio> ... would you need multiple requests?
17:52:40 <emilio> skef: no, it'd look a lot like woff, woff is a format that knows information about tables. The stream is compressed but the header has tables and offsets
17:53:25 <emilio> ... if you ignore my desires about precompression, then the format could be woff, and the subset would have a slightly more information (if we're replacing the table, or extending the previous version, etc)
17:53:48 <emilio> jhudson: so woff gets decompressed to sfnt, then your new woff-like thing gets decompressed and you patch the sfnt
17:54:11 <emilio> ... so that is more work in the client side, you're not diffing the woff
17:54:17 <emilio> skef: you're never diffing the woff
17:54:39 <emilio> ... if the client is going to uncompress the woff into an sfnt
17:54:44 <emilio> ... then you can patch relative to that
17:54:54 <emilio> ... woff2 does specify an sfnt in the end
17:55:47 <emilio> jhudson: what woff2 does to a font is very different to woff1, you have sfnt, gets woff2'd to a subset, then you presumably unpack that woff2 in order to you're going to uncompress the woff2 into an sfnt to know what you're diffing against
17:56:05 <emilio> chris: woff1 gives you a bitwise identical to the sfnt
17:56:10 <emilio> ... woff2 doesn't make that guarantee
17:56:34 <emilio> jhudson: so would it make sense to store a decompressed woff2 in the server and patch against that?
17:56:41 <emilio> grieger: yeah we were discussing that earlier
17:56:51 <emilio> jhudson: might apply to font families as well
17:56:55 <chris> woff2 gives you a font that will render the same but may be structured differently
17:57:19 <emilio> grieger: I want to make sure that decompressed woff2 is feasible
17:57:41 <emilio> skef: if we do table-based patching then the guarantee we need is that tables are bit-for-bit identical, not locations
17:58:03 <emilio> grieger: a complication there is that checksums need to be done per table and storage increases
17:58:14 <emilio> ... for me it feels a lot of extra complication
17:58:38 <emilio> ... efficiency and savings from per-table diffing I want to test
17:58:47 <emilio> ... because brotli doesn't work like other patching mechanisms
17:59:22 <emilio> skef: the other thing I want to push is not pushing client for a dual production diff, leave more up to the client
17:59:49 <emilio> ... if I'm the server I don't want to know all the checksums of all tables to produce a binary patch
18:00:08 <emilio> ... there's assumptions in the protocol of always saving the whole thing
18:00:40 <emilio> grieger: the intention is that server is stateless and client describes the state it has and the one it wants and produces it on demand
18:00:51 <emilio> skef: right and there are other ways to approach this
18:01:08 <emilio> grieger: typesetting is usually extremely fast, bottleneck is patch generation
18:01:13 <emilio> ... so we should look into optimizing that
18:01:24 <emilio> ... a third patch type more specific to the format might be a way to do this
18:01:57 <emilio> skef: in practice it puts the complexity we are arguing about into a box that's not very well integrated with the rest of the system
18:02:16 <emilio> grieger: with custom patch you could do a lot of things, in the server you could focus on generating a patch for the tables that do change
18:02:37 <emilio> ... the model where you just generate two subsets is very simple
18:02:48 <emilio> jhudson: a lot of this discussion is presuming gid retention
18:03:06 <emilio> grieger: yeah without it (and subsetting done in a way that it doesn't change tables)
18:03:20 <emilio> jhudson: We could define a protocol where specific tables doesn't change
18:03:29 <emilio> skef: that doesn't help with the binary diff
18:04:02 <emilio> grieger: since brotli is a bit of this black box, it'd be useful to know whether having the tables that don't change makes a meaningful difference
18:04:08 <emilio> skef: well you have to look at the bits
18:04:29 <emilio> grieger: yeah, at minimum, but I don't know how brotli works deep enough
18:04:39 <emilio> ... that's why it should be tested
18:04:59 <emilio> jhudson: That's why I was talking about a customized patcher that could skip those tables
18:05:24 <emilio> Vlad: I don't want to make a blunt assumption that GID retention guarantees tables not changing
18:05:49 <emilio> skef: if you want to only change the glyph table you might want to go towards range requests instead
18:06:01 <emilio> s/skef:/grieger:
18:06:27 <emilio> skef: I think that's an overstatement, in practice you're going to look at gsub, if its <= 300k, then gid retention and not compress it
18:07:11 <emilio> ... it's a very specific number of fonts where gsub/gpos are worth compressing (mostly emoji / cjk fonts)
18:07:42 <emilio> jhudson: I can imagine multi-script font with complex scripts and someone using one, the whole gsub relative to what's used could be quite large
18:07:49 <emilio> grieger: that's one of the cases we want to use this for
18:08:19 <emilio> jhudson: IF we want to go table-level format for the patch subsets, does woff as currently spec'd work for that or are we looking at another format for this use
18:08:39 <emilio> skef: there's the subset and patch subset. For patch we need something new
18:08:53 <emilio> ... haven't looked at woff1, seems like it'd be closer to what we'd want
18:09:07 <emilio> ... either to have a table-centered patch format or pre-compressed bits put together
18:09:20 <emilio> ... so maybe with woff1+ you could do some of this stuff
18:09:46 <emilio> jhudson: woff1 is basically zipping, we could consider woff3, which would be woff1, but maybe with different compression on those tables
18:09:59 <emilio> chris: do you mean compression or also reconstructing / removing stuff?
18:10:29 <emilio> jhudson: we are assuming already that what we diff against is either the original sfnt or the decompressed woff2 output of the original font
18:11:11 <emilio> skef: if you have a table-level philosophy, then you decompress woff2 and get a patch relative to those table units
18:11:28 <emilio> ... server needs to know what was there, you might still be reconstructing the checksums in the head table, but there's no global reconstruction of the file
18:11:54 <emilio> chris: do we know if you take sfnt -> woff2 -> sfnt -> woff2 -> ..., is it actually stable?
18:12:02 <emilio> jhudson: wouldn't put money on it
18:12:24 <emilio> chris: It seems that's a bit of the assumption
18:12:36 <emilio> grieger: woff2 doesn't enter the picture in the spec
18:13:03 <emilio> skef: I thought people thought you could woff2 the patch
18:13:22 <emilio> grieger: no, needs only way of doing woff2 needs to be uncompressed
18:13:31 <emilio> skef: so that means you can't use any compression right?
18:13:36 <emilio> grieger: brotli
18:13:46 <emilio> jhudson: so server knows what it has sent
18:13:50 <emilio> grieger: server is stateless
18:14:02 <emilio> ... knows nothing about what happens in the past
18:14:12 <emilio> chris: all state is in the client, gets sent to the server every time
18:15:11 <emilio> skef: the assumption is that the server would be able to get a bit-for-bit identical state using the client's state
18:15:33 <emilio> jhudson: Is this really quicker than sending the whole font?
18:15:46 <emilio> grieger: surprisingly, subsetters are pretty fast this days
18:15:52 <emilio> skef: but binary diffing isn't
18:16:03 <emilio> grieger: that's where there could be some innovation here
18:16:15 <emilio> skef: so skyline does diffing for each table spec
18:16:36 <emilio> ... sometimes it does a poor job, you end up sending more data for this patch that it'd take to replace the table with the subset, but it's fast
18:16:51 <emilio> ... because when binary-diffing you don't know what data is the same
18:17:52 <emilio> ... if you're not looking for potentially-advantageous similarities and the only thing you're interested is a particular spot in the table changes, is fast but very complicated
18:18:07 <emilio> ... it has the opposite qualities of the simplicity but the computational price
18:18:39 <emilio> ... so in past meetings I've mentioned one of the things we might be looking at is an assisted binary diffing, where you get offsets
18:18:57 <emilio> ... which would not be brotli compatible
18:19:05 <emilio> ... but could be much faster
18:19:15 <emilio> ... we don't think binary diffing would hit our perf requirements
18:19:36 <emilio> grieger: I think I'd propose a third patch format before rewriting the protocol to be table-based
18:19:54 <emilio> skef: you'd lose the precompression
18:20:06 <emilio> grieger: I think you could do that, as long as it ends up being a valid font
18:20:18 <emilio> skef: precompression would be only important for the subset, not for the patch
18:20:25 <emilio> grieger: can you clarify what you mean?
18:20:39 <emilio> skef: let's say you are doing GID preservation, and gsub / gpos don't change
18:20:52 <emilio> ... you might want them to pre-compress them at a high level on the server
18:20:59 <emilio> ... and send them on the server
18:21:21 <emilio> grieger: we could make this patch algorithm that takes a list of tables
18:21:40 <emilio> skef: but how does this apply to the subset?
18:22:13 <emilio> grieger: first request always uses the patch algorithm
18:22:55 <emilio> ... you're always sending something in the patch format, in the first patch format it's always the brotli-compressed ttf
18:23:29 <emilio> ... your custom patch format could do that, server would be aware of it and can decide not to send gsub in other patches
18:23:51 <emilio> skef: so all the assumptions I'm worried about are built into the brotli format
18:24:07 <emilio> ... if we develop this other thing, we could just decenter the brotli approach
18:24:22 <emilio> ... e.g., here's two approaches, brotli and this other thing
18:24:29 <emilio> grieger: the spec currently defines two patch formats
18:24:47 <emilio> ... would be easy to define a third patch format in the spec
18:24:56 <emilio> ... provides a good path to extensibility
18:25:04 <emilio> ... I think you brought up a lot of good points
18:25:24 <emilio> ... my feeling is we should try to work within the framework we currently have
18:25:36 <emilio> skef: I can agree for the stuff we're talking about
18:25:53 <emilio> ... I'd like to consider the benefits of storing the state as a table
18:26:02 <emilio> grieger: I need to think a bit about it
18:26:07 <emilio> jhudson: what's the benefit of that?
18:26:40 <emilio> skef: when you cache something, if the subset state is not in the font you're juggling with two pieces of information, when that information is conceptually part of the font, so it's much cleaner if it can be a file
18:26:56 <emilio> jhudson: So when the client tells the state to the server, what does it sent?
18:27:30 <emilio> grieger: that's the protocol, but we're talking about how we store it on disk, which the spec doesn't mention that
18:28:19 <emilio> skef: so the state you send is always going to be different that what you store, and it's right it'd need to extract some of that from the table
18:28:46 <emilio> grieger: we want to look at this when looking at integrating it in chrome
18:28:50 <emilio> heycam: Does the state stored in a table complicate the diffing?
18:29:20 <emilio> grieger: it'd be diff'd with everything else, but a large part of it is the list of codepoints
18:29:31 <emilio> which will never change
18:30:24 <emilio> jhudson: so client comes along, requests state, and server decides that it's not worth caching and sends the whole font
18:30:37 <emilio> grieger: the protocol allows to reply with the whole font
18:31:37 <emilio> skef: but if it doesn't you'd send the list of codepoints it includes and the codepoints that the font has, so client can know it doesn't need to ask again about it
18:33:53 <emilio> skef: google has talked about the 80/20 rule, so you make a subset with the 20% of the glyphs that covers the 80% of your cases, so with this you can have a clever subset of the font
18:35:53 <emilio> ACTIONS: Look into woff2 glyph transform
18:36:02 <emilio> ACTIONS: Track client state as a table in the font
18:36:20 <emilio> ACTIONS: investigating alternative patch format
18:39:31 <emilio> Topic: Revisiting Method Negotiation
18:40:01 <emilio> grieger: common issue in a variety of issues
18:40:44 <emilio> ... if we don't know the formats that the server supports, we need a first request that works for every format
18:40:52 <emilio> ... we thought of using the query parameter
18:41:06 <emilio> ... but that's not great
18:41:28 <emilio> ... custom header is an alternative but might trigger a roundtrip because it triggers CORS preflight
18:41:55 <emilio> ... proposal is instead of having the method negotiation we use the CSS tech() to specify server support
18:43:16 <emilio> Vlad: there was a clear benefit when we tested on choosing the preferred format for different applications
18:43:51 <emilio> grieger: so we'd have `incremental-patch`, `incremental-range` and `incremental-auto`
18:44:19 <emilio> ... `auto` would be easier to use, and uses method negotiation
18:45:08 <emilio> skef: let me try to describe the situation, `incremental-{patch,range}` are optimizations to avoid roundtrips until `query` http method
18:45:18 <emilio> grieger: that's right
18:46:19 <emilio> Vlad: even in the long-term there might be worth it
18:46:29 <emilio> grieger: only missing thing is updating the css fonts spec
18:46:50 <emilio> chris: only question would be incremental-auto vs. incremental, I don't feel strongly
18:46:57 <emilio> grieger: I have a slight preference for -auto
18:47:03 <emilio> ... because it's clearer what's going on
18:47:48 <emilio> grieger: there's also alps to avoid the roundtrip, we could potentially use that
18:48:02 <emilio> ... there's some downsides to that which is that it works at the domain level
18:48:14 <emilio> ... which may be tricky for cdns
18:48:32 <emilio> skef: I've already got an internal question about this about CSS
18:48:40 <Vlad> Co-chairs: Grieger, Vlad
18:48:45 <emilio> chris: what is the concern?
18:49:07 <emilio> skef: I think it's just that this mechanism is not designed for what we're doing
18:49:12 <emilio> chris: yes it is, I designed it
18:50:00 <emilio> grieger: you can read through the specifics, but eventually for not-supported things you end up with some roundtrips and the full font
18:50:22 <emilio> heycam: In the long term will it be needed to use tech()?
18:50:39 <emilio> grieger: tech() will be needed because not all fonts can be incremental
18:51:20 <emilio> heycam: Can you not specify tech() and if the font doesn't support it get the whole font from the server
18:51:28 <emilio> grieger: I think you always need an opt-in
18:51:42 <emilio> chris: tech() is also used for other things like colorv1 etc
18:51:58 <emilio> jhudson: what kind optimization are you thinking about for patches
18:52:10 <emilio> grieger: mostly flattening glyph ids
18:52:34 <emilio> jhudson: where is that expected to happen? Before uploading the font?
18:52:48 <emilio> grieger: yes, you'd run the font through an utility before
18:53:01 <emilio> ... other opt is having the glyph table at the end rather than middle
18:53:46 <emilio> ... the other one is a good idea to reorder the glyphs so that common glyphs are contiguous
18:54:10 <emilio> ... myles already has an utility
18:54:27 <emilio> ... if you don't do this it will work but be slower and potentially transfer more data
18:55:31 <emilio> ... myles' utility is not still fully ready but it's already opensource, should be part of the whole font compilation process
18:56:16 <emilio> TOPIC: Incorporating HTTP QUERY Method / https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html without blocking the progress of the IFT Rec.
18:56:46 <emilio> Vlad: would formal communication telling them we want to use it be useful?
18:56:57 <emilio> chris: yeah why not, can't hurt
18:57:17 <emilio> ACTION: Check with the http wg
19:41:09 <Zakim> Zakim has left #webfonts
20:52:38 <hakan> hakan has joined #webfonts
20:58:25 <grieger> grieger has joined #webfonts
21:07:19 <Vlad> Vlad has joined #webfonts
21:07:33 <Vlad> zakim, who is here?
21:08:28 <Zakim> Zakim has joined #webfonts
21:08:50 <Vlad> zakim, who is here?
21:08:50 <Zakim> Present: (no one)
21:08:52 <Zakim> On IRC I see Vlad, grieger, hakan, drott, emilio, RRSAgent, sergeym, Mike5Matrix, MariaAngelaPileri, Github
21:08:57 <sef> sef has joined #webfonts
21:08:58 <Vlad> present+
21:09:11 <skef> skef has joined #webfonts
21:11:57 <heycam> heycam has joined #webfonts
21:13:07 <skef> present+
21:13:10 <heycam> Scribe: Cameron
21:13:12 <heycam> ScribeNick: heycam
21:13:49 <heycam> Topic: QUERY
21:14:00 <heycam> grieger: I think we want to clarify somethings with the authors
21:14:10 <heycam> skef: it would solve a lot of problems
21:14:17 <heycam> Vlad: when I put this on the agenda my main goal was to make sure we didn't forget it
21:14:28 <heycam> ... and if needed to be able to have an official communication saying Web Fonts WG discussed this, we want to use it
21:14:35 <heycam> ... recognize it's not yet a spec, what's your timeline?
21:14:56 <heycam> grieger: next steps, make some text changes to specify this as optional
21:15:10 <heycam> Vlad: just saying it's a blocking issue for us, it's too much of an uncertainty
21:15:17 <Vlad> Topic: Open issues
21:15:36 <Vlad> https://github.com/w3c/IFT/issues
21:15:51 <chris> chris has joined #webfonts
21:17:04 <heycam> grieger: #32 and #33 nothing to do, filed as specific issues later on
21:17:21 <heycam> ... there are some issues that are range request specific, not sure what to do with them without Myles
21:17:43 <heycam> Vlad: at the end of the meeting we should consider discussing them as a separate topic, see if we should revert and moving it to a separate document
21:17:58 <heycam> ... if we're keeping it as a merged document with no progress on part of it, it'll hold up indefinitely
21:18:03 <heycam> grieger: so we'll skip over the range request specific ones
21:18:34 <heycam> https://github.com/w3c/IFT/issues/42
21:18:39 <heycam> chris: I think we're done on this issue, but didn't get a response
21:18:55 <heycam> skef: what does it mean that they not be preserved?
21:19:08 <heycam> grieger: this other one that's closed, if you have the font cached for one domain you shouldn't be able to see that partially transferred font on the other domain
21:19:16 <heycam> ... which will be enforced by the browser, since they do the origin keyed caching
21:19:31 <heycam> skef: I don't understand the "not be preserved" thing
21:19:42 <heycam> chris: it's just different wording for the same thing
21:20:02 <heycam> jh: is that true of all browsers?
21:20:06 <heycam> grieger: not sure, but that's the behavior that's been required
21:20:21 <heycam> ... I do know the Chrome situation, and that's fully implemented and enforced
21:20:58 <heycam> jh: if a font hasn't flattened composites ahead of time
21:21:11 <heycam> grieger: the client will need to go back to the server again for them
21:21:21 <heycam> ... as with other optimization issues, it will work, it'll just be slower
21:21:34 <heycam> ... and there are some interesting tradeoffs. you've got composite glyphs reusing lots of other glyphs, significant size savings
21:21:39 <heycam> ... it might be worth having another round trip for that
21:22:01 <heycam> jh: there's also some possible hinting implications in that you can hint component positions, so you'll actually get a different bitmap if you flatten it
21:22:28 <heycam> https://github.com/w3c/IFT/issues/50
21:22:33 <heycam> grieger: I think we're just waiting on this issue too
21:22:52 <heycam> chris: no they came back to say we didn't address their comment
21:23:17 <heycam> grieger: I think we want to say something about the client fuzzing what it sends to the server
21:23:38 <heycam> chris: I'm not sure if any other specs talk about fuzzing, and requiring the browser to do it
21:23:47 <heycam> jh: or if there's any kind of standard of what consistutes good fuzzing
21:24:01 <heycam> grieger: it's very script specific. how do we give general guidance?
21:24:14 <heycam> ... just send X number of extra codepoints? might be overkill for some scripts, not enough for others
21:24:28 <heycam> ... I'll spend some time thinking about solutions for this
21:24:32 <heycam> chris: can you comment that on the issue?
21:24:56 <heycam> jh: my suspicion is we probably need some input from CJK specialists, posing the problem, how would you go about concealing what someone is looking for?
21:25:10 <heycam> chris: we did ask the Chinese web interest group about this whole problem of you can tell what type of material is being read
21:25:29 <heycam> ... they said no you can't, didn't want to take part in investigations into that
21:25:51 <heycam> grieger: we have privacy WGs internally at Google, they might have some ideas
21:26:09 <heycam> chris: it's the intersection of this plus CJK (well, C)
21:26:52 <heycam> skef: client side prefetching intelligence, where you're looking at what's been selected, then make intelligent guesses about what's next, making the request coarser grained, that would have its own benefits but also address this somewhat
21:26:59 <heycam> ... smearing code points into larger groups
21:27:11 <heycam> grieger: if we're going to requests extra codepoints, they should be useful
21:27:22 <heycam> jh: if the stuff your'e grabbing are obscure historical characters, that's not useful
21:27:47 <heycam> grieger: I'll update that issue then spend some time to think about this further
21:27:59 <heycam> https://github.com/w3c/IFT/issues/57
21:28:05 <heycam> grieger: my position is that we probably shouldn't
21:28:13 <heycam> ... can we just close this?
21:28:24 <heycam> ... the argument for not requiring both, is that most browsers will implement one or the other
21:28:29 <heycam> ... both implementations won't share much
21:28:51 <heycam> jh: do we leave it in the spec as a should?
21:28:51 <heycam> grieger: yes
21:30:03 <heycam> https://github.com/w3c/IFT/issues/58
21:30:38 <heycam> skef: is this not a subproblem of the glyph ordering?
21:30:40 <heycam> grieger: I think it's related
21:30:50 <heycam> ... one approach is where you don't have compostie glyphs, you just flatten everything
21:30:53 <heycam> skef: but not everything has a codepoint
21:31:06 <heycam> grieger: shaping happens on the client, then the client works entirely in glyph IDs in the range request world
21:31:22 <heycam> ... for composite glyphs, the client would fetch the glyph, notice it's composite, then go fetch all those glyphs that it references
21:31:29 <heycam> skef: I'm a little fuzzy on the glyf stuff
21:31:33 <heycam> ... this is not CSS
21:31:33 <heycam> grieger: no
21:31:43 <heycam> ... it's analagous to subroutines
21:31:47 <heycam> ... in CFF
21:32:16 <heycam> Vlad: my working assumption is on patch subset sites, we won't have this problem
21:33:04 <heycam> grieger: one out there suggestion, add an additional table to the font, which just specifies the composite relationships? just to aid range requests
21:33:10 <heycam> Vlad: this is a suggestion for the server to do something
21:33:19 <heycam> ... when you ask for a composite glyph, I'll throw in the actual components as well
21:33:36 <heycam> grieger: can range requests respond with ranges you didn't ask for?
21:37:35 <heycam> Vlad: re #59, the simple solution that issue is to call things the way they are
21:38:27 <heycam> ... Myles when he was drafting the first range request spec, he was trying to cover as many use cases as he could, and he was using WOFF2 as long as not compressed, but that's a new format [...]
21:38:40 <heycam> ... I want to remove the reference in the spec to say range requests can be used for WOFF2 files, since it cannot
21:38:55 <heycam> skef: for #60 it's worth saying how compression would be supported, like real time compression on the server
21:39:11 <heycam> grieger: Myles had some ideas, a different type of Content encoding that would be more amenable to range requests, but I don't think anything concrete came out of that
21:39:28 <heycam> skef: with range requests, is there a bottom level assumption that the servers have no IFT specific information?
21:39:29 <heycam> grieger: yes
21:39:35 <heycam> skef: then yes there's no way to use WOFF2
21:39:48 <heycam> jh: you can use a WOFF2 upstream, and then decompress it on the server, then that gives you ...
21:39:59 <heycam> skef: that's what I was going to say. if it's a hard requirement to have no IFT specific logic on the server ...
21:40:11 <heycam> grieger: should be able to fire up an Apache server out of the box and it works, or drop it on to a CDN
21:40:22 <heycam> chris: therefore you can't expect the server to decompress the WOFF2 then start using the result of that
21:40:30 <heycam> grieger: so should we close this issue?
21:40:38 <heycam> Vlad: I don't want to close it without making any changes in the spec
21:40:46 <heycam> ... if we make a change that removes WOFF2 as the range request target, then it's fine
21:40:51 <heycam> grieger: I'll note that
21:41:05 <heycam> jh: WOFF2 also doesn't work with patch subset?
21:41:06 <heycam> grieger: right
21:41:38 <heycam_> heycam_ has joined #webfonts
21:42:34 <heycam__> heycam__ has joined #webfonts
21:43:32 <heycam____> heycam____ has joined #webfonts
21:43:40 <heycam____> grieger: 67 that's a good change
21:43:59 <heycam____> grieger: 74, we'll wait for Myles
21:44:04 <heycam____> ... or whoever takes over from Myles
21:44:22 <heycam____> Vlad: I'd consider grouping the range requests in a separate discussion
21:44:29 <heycam____> ... if it's going into a separate document, we won't be blocked
21:44:50 <heycam____> grieger: #93. we've talked about this a lot.
21:45:13 <heycam____> skef: query is the main thing. there's some interactions with other stuff. but I think it's been addressed.
21:45:25 <heycam____> Vlad: if there are any other changes that would benefit the spec, just file a PR
21:45:33 <heycam____> skef: I hope to continue paying attention to the spec
21:45:45 <heycam____> grieger: #94, redunant feature detection.
21:46:04 <heycam____> skef: we've discussed some ideas about this. not sure how important it is. as COLR comes online -- the idea here is that the client will have certain capabilities
21:46:22 <heycam____> ... the author may have certain preferences, and the question is how these things interact with redundant information in the font
21:46:30 <heycam____> ... let's say you have COLRv0 and COLRv1 tables
21:46:47 <heycam____> ... it would be desriable to reason about this without needing to have redunant information when subsetting
21:47:09 <heycam____> grieger: the existing solution to this it to lean on the tech stuff. in this case, you have one URL that's tech(colorv0) and tech(incremental),
21:47:15 <heycam____> ... we're launching color fonts today
21:47:29 <heycam____> ... this is how we're doing it. not with tech() right now, but with UA
21:47:36 <heycam____> skef: are the servers making these decisions out of band?
21:47:45 <heycam____> grieger: we've made multiple versions of the font put them on the CDN
21:48:06 <heycam____> skef: in the spirit of subsetting, there could be one font, you could do it in real time. then it's a question of how to communicate the preference
21:48:31 <heycam____> grieger: instead of a new mechanism. the server sees a request for a subset, it sees it's Chrome on this OS, I'll subset out the COLRv0 tables
21:48:36 <heycam____> skef: that takes CSS out of the picture
21:48:43 <heycam____> grieger: other option is to do it with tech()
21:48:59 <heycam____> ... there's some flexibility for server. could take a parameter in the URL
21:49:06 <heycam____> ... that might trigger the subsetting to happen
21:49:13 <heycam____> skef: the URLs could be synthetic
21:49:13 <heycam____> grieger: yes
21:49:17 <heycam____> ... that's all valid in the spec
21:49:28 <heycam____> skef: it's a little pasted on, but I don't have a stronger objection than that
21:49:35 <heycam____> grieger: there are mechanisms for dealing with this, don't want to add a new one
21:49:54 <heycam____> skef: maybe a brief section on there are these other mechanisms, if you want to do this in real time, you could organize things this way
21:50:05 <heycam____> grieger: I'll add a comment here to provide some clarification
21:51:09 <heycam> grieger: #101, I'm overdue to look into this
21:51:19 <heycam> chris: these are all 6 months. if the authors don't have much to change, it just expires
21:51:25 <heycam> ... what's supposed to happen is it becomes an RFC
21:51:36 <heycam> ... because there's no WG, it's not clear how to move to an informational RFC
21:51:41 <heycam> grieger: afaik it's in a stable state
21:52:10 <heycam_> heycam_ has joined #webfonts
21:52:13 <heycam_> grieger: next, #103 a la carte
21:52:24 <heycam_> skef: we have a reference implementation, would eventually move into browsers
21:52:41 <heycam_> ... at the point where browsers start implementing this stuff natively, I don't think we want to end up in this situation where all the interactions are hard coded
21:52:49 <heycam_> ... you might want to influence prefetching at a content level
21:52:58 <heycam_> ... right now, we don't have any interfaces
21:53:07 <heycam_> ... at some point you'll want to hook into this for different purposes, that's what this is about
21:53:12 <heycam_> ... not sure we're there yet, we don't have an API
21:53:17 <heycam_> ... this is about what the API will be
21:53:27 <heycam_> grieger: eventually want a JS API that integrates with this, beyond what's currently available for font loading
21:53:38 <heycam_> skef: in here is a list of the points of interaction that Adobe would be nervous not having
21:54:09 <heycam__> heycam__ has joined #webfonts
21:54:36 <heycam__> grieger: we'll leave this issue open
21:54:48 <heycam__> grieger: #104, Chris can we close this one now?
21:54:53 <heycam__> ... explaining why there's two methods
21:54:56 <heycam__> chris: I think we can
21:55:00 <heycam__> ... we have made some changes
21:55:06 <heycam__> ... we should wait to get a thumbs up on it
21:55:14 <heycam__> grieger: this was feedback over email
21:55:16 <heycam__> ... we can leave it open
21:55:26 <heycam__> chris: I'll get back to the original author
21:56:02 <heycam__> chris: Martin Thomson
21:56:08 <heycam__> grieger: few issues from him
21:56:22 <heycam__> grieger: #106, don't think there's a ton to discuss here
21:56:29 <heycam__> ... some changes to the way we present the text
21:57:19 <heycam__> grieger: #108, I believe the bulk of this is addressed by the perf considerations section I added
21:58:55 <heycam> heycam has joined #webfonts
21:59:00 <heycam> grieger: #109
21:59:09 <heycam> skef: in my mind this is a server thing, it would use its own out of spec decision making
21:59:20 <heycam> ... so we might just mark this as range request specific, not sure we need that information on the client side
21:59:33 <heycam> Vlad: if you don't need anything speced for this, can just close it
21:59:38 <heycam> skef: none of this is needed for patch subset
21:59:43 <heycam> ... it could be needed for range requests
21:59:56 <heycam> grieger: some indicators could be added to CSS @font-face
22:00:10 <heycam> jh: is range requests taking into account discretionary OpenType layout features applied by CSS?
22:00:15 <heycam> grieger: it's post shaping, so that's already happened
22:00:26 <heycam> ... let's say some text was viewed, didn't have the optional features enabled, we fetch the glyphs
22:00:34 <heycam> ... later we turn on this features, then you'd grab more glyphs at that point
22:00:39 <heycam> ... because the glyph requests happen after shaping happens
22:00:56 <heycam> jh: there is the possibility a client could do a subset like glyph closure, and over request glyphs? for features that might be turned on
22:01:04 <heycam> s/jh/griger/
22:01:13 <heycam> jh: in the patch subset scenario...
22:01:22 <heycam> grieger: recently I added teh ability for the client to say which features it's interested in
22:01:42 <heycam_> heycam_ has joined #webfonts
22:02:15 <heycam_> grieger: #110, not much to do on this issue. just asking for the spec talking about how to optimize. might be better to have an open source reference. which we have started.
22:02:46 <heycam_> grieger: #115, range requests says the server must support transfer encoding over content encoding
22:02:53 <heycam_> ... in reality only HTTP 1.1 supports transfer encoding
22:02:59 <heycam_> ... whereas content encoding works across the board
22:03:06 <heycam_> ... I think the spec should say at least content encoding
22:03:15 <heycam_> ... if you only did transfer encoding, it's not going to work with some HTTP clients
22:03:27 <heycam_> ... there was an actual different in the semantics
22:03:34 <heycam_> ... this is about how the request is compressed over teh wire
22:04:12 <heycam_> grieger: #116, I provided a long answer here
22:04:17 <heycam_> ... had good existing docs in the design doc
22:04:31 <heycam_> ... I think we have a strong case for why we're doing the custom encoding
22:05:10 <heycam_> grieger: #117
22:05:15 <heycam_> skef: is this a dupe?
22:05:16 <heycam_> grieger: yes
22:05:18 <heycam_> ... of #110
22:06:17 <heycam_> grieger: #118, not sure what's directl actionable out of this one
22:06:38 <heycam_> skef: I think there's a bucnh of optimization strategies we're assuming, that would happen on the server side, and are part of the spec
22:07:05 <heycam__> heycam__ has joined #webfonts
22:07:21 <heycam__> skef: all of these server side optimizations are encompassed in being able to return more data
22:07:27 <heycam__> ... but it's not clear in the spec because we're not calling that out
22:07:31 <heycam__> grieger: I thought we did mention that
22:07:39 <heycam__> skef: it's subtle
22:07:58 <heycam__> ... I think that's what "one page vs many pages" must mean this
22:08:02 <heycam__> s/mean this/mean/
22:09:05 <heycam__> skef: we started intelligent prefetching because we were tied to GET for caching, so we had to get the bundle of information down to fix in a GET request, so we were forced to do that
22:09:11 <heycam__> grieger: to fit in a URL
22:09:44 <heycam> heycam has joined #webfonts
22:09:57 <heycam> grieger: #119, this is a dupe of regional caching
22:10:18 <heycam> grieger: #120, I thought we already had an issue for this
22:10:25 <heycam> jh: dupe of #104
22:10:40 <heycam> grieger: that's the end of the issues
22:11:00 <heycam> Topic: range requests
22:11:10 <heycam> Vlad: when we started the spec, we had 2 separate documents
22:11:20 <heycam> ... each had redundant sections
22:11:51 <heycam___> heycam___ has joined #webfonts
22:12:02 <heycam___> grieger: until we have a replacement for Myles
22:12:12 <heycam___> skef: can we have the range requests spec depend on the other one? to avoid duplication?
22:12:14 <heycam___> grieger: yes
22:12:28 <heycam___> chris: on the main document, we had "section 4 range requests", described in a separate doc
22:12:44 <heycam___> ... but then the separate doc did have some duplication, so there was a benefit from merging
22:13:00 <heycam___> ... if it's split out, it should just be the range requests part of it
22:13:12 <heycam___> ... so section 5 into a new document with a brief introduction, and a link back to the main spec
22:14:03 <heycam___> RESOLUTION: Split out section 5 range requests into a separate document, linked from the main spec
22:14:45 <heycam___> skef: we're thinking about things in terms of patch formats. might be able to morph the sky type layer into a conformant patch format, which we wouldn't want to use going on forever, but would be an interesting exercise. I'll think about that.
22:14:53 <heycam___> grieger: and to see if you have all the information you need
22:17:57 <heycam___> Topic: Conformance tests
22:18:04 <heycam___> grieger: I implemented a full server conformance test suite
22:18:15 <heycam___> ... it treats the server as a black box, here's a URL for a server, here's a patch for a font
22:18:22 <heycam___> ... the test acts as a client and interacts with it
22:18:37 <heycam___> chris: these are linked to bits of the spec?
22:18:46 <heycam___> grieger: yes, we've marked up the conformance statements in the spec, linked from the tests
22:19:07 <heycam___> ... the tests are a bit outdated, I'll have to do a round of syncing things up again
22:19:16 <heycam___> ... the new feature list stuff isn't tested at all
22:19:33 <heycam___> skef: the video for this conference, simultaneously showed results for subsetting and range requests?
22:19:35 <heycam___> grieger: no unicode-range
22:19:42 <heycam___> ... comparing to what Google would do today
22:20:00 <heycam___> skef: range requests is still up in the air?
22:20:04 <heycam___> grieger: yes
22:20:18 <heycam___> ... i have concerns about implementing in the browser, since you're inserting between shaping and rendering
22:20:42 <heycam___> chris: good thing about range request is that it doesn't need anything special on the server, but it does on the client
22:20:52 <heycam___> jh: is range request a thing that might not happen?
22:21:02 <heycam___> grieger: I want it to happen, but it needs someone to take it to the finish line
22:21:08 <heycam___> jh: are clients going to be interested in implementing?
22:21:32 <heycam___> grieger: I've spent some time looking into Chrome code for patch subset, haven't done that for range requests. feel it wouldn't be easy but not impossible
22:21:49 <heycam___> grieger: I don't have the bandwidth to look at both
22:22:10 <heycam___> grieger: the server tests are in good shape, just needs some updates
22:22:18 <heycam___> ... pretty thorough
22:22:24 <heycam___> ... client tests, haven't spent time thinking about what they'd look like
22:22:47 <heycam___> skef: in order to more fully communciate the potential optimizations, even if they're not conformance test specific, could we build some of that into our basic playground?
22:22:53 <heycam___> ... server side supersetting?
22:22:56 <heycam___> grieger: the demo?
22:23:01 <heycam___> skef: yeah
22:23:07 <heycam___> grieger: the demo does do prediction, you can check a box for that
22:23:18 <heycam___> ... it's not a smart implementation, just uses codepoint frequency
22:23:21 <heycam___> ... based on the script it thinks you're using
22:23:34 <heycam___> ... we did the simulations, included the predictions in the simulations, and it was definitely a positive effect
22:24:01 <heycam___> skef: how do we use the demo to make it clear what the broader picture is, beyond the spec?
22:24:06 <heycam___> ... in order to make adoption more attractive
22:24:18 <heycam___> grieger: one thing I want to do on the demo, once you referesh the page it loses state
22:24:29 <heycam___> ... could do with a service worker, or indexed db, so you could have a multipage example, and show it off
22:24:32 <heycam___> ... maybe also with some real content
22:24:46 <heycam___> ... let's say an example of a news site, or a blog, using incremental transfer throughout
22:25:03 <heycam___> skef: that works for people who see the demo
22:25:21 <heycam___> ... the spec should be focused just on the spec stuff, but we might be losing the larger picture
22:25:36 <heycam___> heycam___: explainer?
22:25:42 <heycam___> grieger: another thing is the evaluation report
22:25:52 <heycam___> ... that gives you the whole context, some details
22:25:57 <heycam___> chris: that's long and detailed
22:26:06 <heycam___> ... when doing horizontal review, the TAG will first ask where's the explainer
22:26:20 <heycam___> ... so we should have one for people who are slightly interested and who want to know more
22:26:36 <heycam___> ... I'd love to see some code we could give to font foundries, and run it on fonts, and get performance data from them
22:26:44 <heycam___> ... that will also show them they can save XX bandwidth
22:26:56 <heycam___> ... thinking particular for CJK foundries. showing this is what you could actually save, get them interested.
22:27:09 <heycam___> ... at the end of the day, they only sell print licenses, because there's no web market in their area
22:27:20 <heycam___> grieger: good starting point might be to distill the evaluation report?
22:27:26 <heycam___> chris: that ties into adoption and success aspect
22:27:42 <heycam___> ... the wider variety of foundries / fonts we can test with, the better
22:27:55 <heycam___> grieger: maybe something that a font could be fed into it, a mini simulation
22:28:40 <heycam___> heycam___: use wikipedia as a demo?
22:28:46 <heycam___> grieger: that's what we did for our first simulation
22:28:56 <heycam___> jh: the whole benefit of this model is that you can load the fonts faster
22:29:10 <heycam___> ... presumanly there still might be some occasions with lag, if you find the patch needs to get a whole bunch of stuff
22:29:26 <heycam___> ... are people going to be still getting weird momentary displays, flashes of semi formatted text?
22:29:29 <heycam___> grieger: ransom note effect
22:29:38 <heycam___> ... it's a good point. it's about improving the worst case performance.
22:29:45 <heycam___> ... that's what came out of the simulations
22:29:59 <heycam___> ... the better cases might get a bit slower, whereas previously you had a cache hit, you'll now get a small load
22:30:09 <heycam___> ... but bringing down the worst case is [...]
22:30:19 <heycam___> chris: in a testing package, should be able to simulate different network conditions
22:30:33 <heycam___> grieger: sounds like we just want to take the existing simulation tool and make a package where you can feed in your own font
22:31:01 <heycam___> chris: I'm seeing that partly as validation, partly as getting various regional actors on board
22:31:13 <heycam___> grieger: another area we never really covered was emoji and icon fonts
22:31:25 <heycam___> .. if we have a similar demo, or this tool, give us your emoji font to test it
22:31:31 <heycam___> skef: we might affect that system
22:31:39 <heycam___> ... they might be staying within a certain number due to size constraints
22:31:50 <heycam___> ... but if this were available, that might unconstrain them
22:31:59 <heycam___> grieger: an emoji font that covers everything is going to be multi-megabytes
22:32:08 <heycam___> ... most clients are not using anywhere close to all of them
22:32:25 <heycam___> ... back to the client tests, I think the approach we took for WOFF2, it's an in browser test, you see pass/fail messages
22:32:30 <heycam___> ... I'm thinking that might be the way to go
22:32:41 <heycam___> ... don't know if we want tests for non browsers?
22:32:48 <heycam___> jh: what would a non browser based client be?
22:32:50 <heycam___> grieger: let's say an OS
22:33:00 <heycam___> ... where they have a bunch of system fonts, a giant pan unicode Noto font e.g.
22:33:12 <heycam___> chris: another example would be a CSS/HTML -> PDF converter, which gives you printed output
22:33:18 <heycam___> ... typically they don't have a JS engine
22:33:26 <heycam___> grieger: we might just have to not have tests for that kind of client
22:33:46 <heycam___> ... so focusing just on browser based tests might be sufficient
22:33:57 <heycam___> ... then following the WOFF2 model makes most sense
22:34:05 <heycam___> ... it'll bundle up a mock of the server
22:34:31 <heycam___> Vlad: I can easily imagine setting up a test that would use as much of your original demo, except every time you ask for the next step, you get a pass/fail response
22:34:34 <heycam___> grieger: very good point
22:34:41 <heycam___> Vlad: step step step
22:35:01 <heycam___> grieger: we can do the same thing as with the server tests, link up to spec conformance statements
22:35:15 <heycam___> ... we could run the existing prototype demo client through it to test it
22:36:51 <heycam___> Topic: WOFF2
22:36:57 <heycam___> chris: we're waiting on a test with a change
22:37:02 <heycam___> grieger: I thought I added a test
22:37:34 <grieger> https://github.com/w3c/woff2-tests/pull/19
22:37:48 <heycam___> grieger: if that's not sufficient I can go back and add more
22:38:09 <heycam___> chris: if we have results for that test, we should be good to go
22:39:09 <heycam___> grieger: I tested this using the WOFF2 library that Chrome uses
22:39:32 <heycam___> chris: once we've done that, we can republish the WOFF2 recommendation
22:39:44 <heycam___> ... we reapplied for our ISO certification, this will be one of them
22:39:55 <heycam___> grieger: I know Chrome does have support in the stable branch for this
22:40:00 <heycam___> ... so this is out there in a real implementation
22:40:06 <heycam___> ... on Google Fonts we're serving it now
22:41:20 <heycam___> RRSAgent: make minutes
22:41:21 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/13-webfonts-minutes.html heycam___
23:31:11 <Zakim> Zakim has left #webfonts