Comments (1)
- There is an
accept_patch_format
field in the request but the guidance just says "set to the list of Patch Formats that this client is capable of decoding". Seems like if we have this field it should also be used to ensure the server sends a (genuine) patch that matches the previous subset or patch. So maybe once one patch has been downloaded the content of the field should be reduced to the type sent by the server the first time.- On the other hand, that may be overly constraining, as I can imagine wanting the subset and patch formats to be different. (We have this idea that "a subset is a patch of an empty file" but I'm not sure why we need to enforce that.) It seems like the server can easily distinguish between a subset request and a patch request based on the parameters (at least), so maybe this field should mean "what the client can decode" on the initial request and then "what the server sent last" on subsequent patch requests.
I think it's perfectly valid to have subsequent requests use different patch formats. Since we are patching against an opaque font subset each patch application is unaffected by the patch format used previously. Consider a case where we had a format that was really good at encoding the initial non-patch response, and a second format that really excelled and encoding patches. Then it may be desirable to use a different patch format on the initial and follow up responses. If for some reason the client desires to continue using the same patch format across all requests it is allowed to set the accept patch format to a single value. The only must level requirement in the text currently is that the field contains at least one format.
- The "font subset" of section 4.4.1 seems to have two roles. First, it is the file that gets "patched", and thus is the file that gets cached. Second, (I think) it is the file the client uses as a font. This strikes me as restrictive and maybe not how things tend to work in existing browsers for other formats.For example, when a browser downloads a WOFF2 does it typically cache that file or the file extracted from it? (I would guess the former but I may be wrong.)We talked about how you can't really "patch" a WOFF2 but the problems with doing so seem to relate to our particular model of what it means to patch something. If you can deterministically unpack an SFNT from a WOFF2 then you can patch it. Or maybe WOFF2 is unworkable but some similar format wouldn't be. Wouldn't it be more general if the "font subset" part of the client state were just one of the valid "Patch Formats", which can then be unpacked into an SFNT (or whatever other end-use format)? Or, less specifically, wouldn't it be more general if what is cached need not be the end-use format?
Yes, to me the "font subset" is an opaque binary asset that the browser can use as a font. This theoretically could be anything that the browser can currently handle for a font format (eg. TTF, OTF, WOFF, WOFF2). Now of course some of those formats won't be great candidates for use in IFT (eg. a compressed WOFF2 doesn't patch very efficiently, but it would still fundamentally work).
If I understand correctly the main thing you're asking for here is to have the option to have the patch implementation have the option to store an "intermediate" format in the state that could be different from the format we pass off to the browser. For the two existing patch formats in the spec this isn't necessary since they are both generic binary patchers, but I can see this possibly being useful for a more specialized patch format. That said I'm inclined to leave the spec as is for now since adding this would introduce complexity that isn't currently required, but I'd be happy to reconsider in the future if we are considering the inclusion of additional patch formats which would require this.
- Alternatively, if the end-use format will always be sole output representation of the patching process, why are we requiring a further checksum when SFNT (which is the only relevant underlying filetype for the foreseeable future) is already thoroughly check-summed? Are we saying that clients are relieved of checking those sums? (Do the clients not do those checks now?) Maybe to the extent that maybe you don't have to patch up
head
to have the rightcheckSumAdjustment
? Or that the patch checksum and the SFNT checksums play different roles somehow? (Seems like we're proving our work over and over compared with, say, downloading a javascript file. Isn't this all TCP?)If the cached file can be something other than the end-use font file then an intermediate checksum makes more sense to me.
We discussed this in the last wg call and if I remember correctly the outcome of that discussion was to remove the patched checksum from the response. I'll look into doing that.
from ift.
Related Issues (20)
- Add QUERY as a HTTP method type used for patch subset. HOT 1
- IFT and offline reading HOT 3
- Privacy Considerations says checksum is for error correction
- Condisderation HOT 1
- Can't generate html HOT 5
- Compremised
- Rewrite explainer HOT 6
- Different URL ID encoding HOT 13
- Encoder requirements questions/issues HOT 2
- Partial invalidation brotli patches? HOT 1
- Mixing patch types and GID "management" HOT 2
- Aspects of streamed decoding on the client side
- Possible "all other codepoints" semantic? HOT 4
- Wide Review of 9 July WD of IFT HOT 8
- Security self-review answers for 9 July 2024 WD of IFT
- I18n checklist answers for 9 July WD of IFT
- Document serializing/caching of patched font HOT 3
- Should we require Erroring on Validation Requirements for Format 1 Patch Map? HOT 6
- Consistently use `code point` instead of sometimes saying `codepoint` HOT 2
- Considerations for "desiccated" initial font files HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ift.