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