Comments (2)
Deciding whether or not to use incxfer is going to depend on many factors, some beyond just the characteristics of the font. Such as what content is expected to be encountered on the current and/or future page views. So I think the decision to use/not use incxfer would be best made by the content author who can analyze the full circumstances decide whether to opt-in or not for incremental loading on each font file.
Once incremental transfer has been opted into the browser could use some heurestics (and probably should) to try and maximize performance. For example by requesting additional characters that are likely to be needed in order to reduce the need for additional requests.
- What would be the characters used in the document that should be requested? Ideally that would be something the browser knows before the entire HTML is parsed.
Not sure if this is what you meant, but in patch subset the first response from a server includes a complete list of codepoints supported by the font. The client can use that to avoid making requests for characters the font does not support. Likewise for range request the client will load the font's cmap table on the first request which allows it to know what codepoints are supported. This actually turned out to be a pretty important optimization in the simulations we ran. Additionally the content author can provide additional guidance to the browser by adding "unicode-range: ..." to the font face which will help avoid the first requests where the font contains no relevant characters.
from ift.
Deciding whether or not to use incxfer is going to depend on many factors, some beyond just the characteristics of the font. Such as what content is expected to be encountered on the current and/or future page views. So I think the decision to use/not use incxfer would be best made by the content author who can analyze the full circumstances decide whether to opt-in or not for incremental loading on each font file.
Agreed.
But once an author has opted in, we ideally want the browser to make a single, early and as-complete-as-possible request for the glyphs and shapes that it needs for the initial render. The information to enable sending such a request won't be available to the browser until rather late in the game (after HTML parsing & layout). So some heuristics are in order to automatically make that process faster, but maybe we want/need to enable authors and tools to provide hints that would help the browser make the right call.
Not sure if this is what you meant, but in patch subset the first response from a server includes a complete list of codepoints supported by the font.
That's useful for followup requests (e.g. for parts of the font that are needed for out-of-viewport content), but doesn't help the initial request. I was thinking more along the lines of markup annotations (e.g. preload attribute, etc).
from ift.
Related Issues (20)
- Transfer coding for compression won't work HOT 4
- Novel, NIH things HOT 10
- Ease of font re-ordering for performance HOT 5
- Optimize for one page, many pages, or both? HOT 6
- Poor cacheing properties HOT 19
- Why do we have two methods HOT 6
- Questions about section 4.4: Client HOT 1
- Consider placing client state as a table in the font. HOT 2
- Create an explainer for the IFT Patch Subset specification. HOT 6
- Client conformance tests
- 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
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.