Range Request Incremental Font Transfer

W3C Discontinued Draft,

More details about this document
This version:
https://www.w3.org/TR/2024/DISC-RangeRequest-20241210/
Latest published version:
https://www.w3.org/TR/RangeRequest/
History:
https://www.w3.org/standards/history/RangeRequest
Feedback:
[email protected] with subject line “[RangeRequest] … message topic …” (archives)
GitHub
Inline In Spec
Editors:
Chris Lilley (W3C)
(Google Inc.)
Former Editor:
(Formerly of Apple Inc.)

Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

Abstract

This specification defines the range request variant of incremental font transfer. Incremental transfer allows clients to load only the portions of the font they actually need which speeds up font loads and reduces data transfer needed to load the fonts. A font can be loaded over multiple requests where each request incrementally adds additional data.

Status of this document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document has been discontinued because the current Incremental Font Transfer specification has similar ease-of-deployment properties while also providing superior performance.

This document was published by the Web Fonts Working Group as a Discontinued Draft using the Recommendation track.

Publication as a Discontinued Draft implies that this document is no longer intended to advance or to be maintained. It is inappropriate to cite this document as other than abandoned work.

If you wish to make comments regarding this document, please file an issue on the specification repository.

Publication as a Working Draft does not imply endorsement by W3C and its Members. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

1. Range Request Incremental Transfer

1.1. Introduction to Range Request

This section is not normative.

The Range Request method is a very simple method of incremental font transfer, and has no server-side requirements (other than the server should be able to respond to byte-based range requests). The browser simply makes range requests to the server for the specific bytes in the font file that it needs. In order to know which bytes are necessary, the browser makes one initial special request for the beginning of the file.

In order for the range request method to be as effective as possible, the font file itself should be internally arranged in a particular way, in order to decrease the number of requests the browser needs to make. Therefore, it is expected that web developers wishing to use the range request method will use font files that have had their contents already arranged optimally.

This method was modelled after video playback on the web, where seeking in a video causes the browser to send a range request to the server.

1.2. Font organization

1.2.1. Background

This section is not normative.

A particular organization of font files is beneficial for improving the performance of the range-request IFT method. The range-request IFT method only works with [TRUETYPE], [OPENTYPE], [WOFF], or [WOFF2] files. All of these file formats use an sfnt wrapper which provides a directory of tables inside the font file. A sfnt-based font file is mainly composed of a collection of independent tables.

Using WOFF2 files with range-request mechanism doesn’t seem to be a viable option

1.2.2. Introduction

The term range-request optimized font is used to describe a font file organized for use with the range-request IFT method. Optimizing a font for the range-request IFT method does not change the file format of the font.

Note: Because optimizing a font does not change its file format, no new additional tooling is necessary to interact with these optimized fonts. They are still valid fonts, but with a particular internal organization.

The result of optimizing an OpenType font for the range-request IFT method is still a valid OpenType font. The resulting file may be larger (by byte count) than it was before optimizing it, but fewer of those bytes should be necessary for a client to download in order to render a target text.

Note: There are no MUST-level requirements on the organization of a range-request optimized font. Any arbitrary font file may be considered to be a range-request optimized font. However, additional optimizations should increase the performance of loading in a browser via the range-request IFT method. Font creators are encouraged to enact as many of the optimizations listed in this section as are reasonable for the fonts they create.

1.2.3. Compression

Servers supporting the range-request IFT method should support compression via the Content-Encoding header (HTTP Semantics § 8.4 Content-Encoding), rather than having the font file itself be statically compressed.

A range-request optimized font file (the file itself) should not use any kind of compression other than [RFC7932] (commonly referred to as "Brotli") compression.

If Brotli compression is used in a range-request optimized font, it should use only one meta-block.

If Brotli compression is used in a range-request optimized font, its one meta-block should have the ISUNCOMPRESSED bit set to 1.

Static file compression compatibility with range-request method

1.2.4. Table Ordering

The term outline table is used to describe these three tables, which carry different types of glyph outlines:

A range-request optimized font should have only one outline table.

No two tables in a range-request optimized font should share a tag name.

The outline table data in a range-request optimized font should lie at the end of the file.

If a CFF table exists, the CharString data should lie at the end of the CFF table.

If a CFF2 table exists, the CharString data should lie at the end of the CFF2 table.

Font Collections support

1.2.5. Glyph Independence

Note: The goal of this section is to make every glyph independent from each other.

A range-request optimized font should not use Compound glyphs.

Supporting fonts with composite glyphs via range-request

Note: Compound glyphs can be flattened by inlining their component glyphs to become additional contours.

A range-request optimized font should not use Subroutines.

Note: CFF glyph CharStrings can be flattened by inlining subroutines to become additional CharString bytes.

1.2.6. Glyph Order

Glyphs inside a range-request optimized font should be sorted in the file to keep glyphs often used in the same documents close together in the file.

Note: Putting the most frequently used glyphs together in the font increases the likelihood that the browser can download a contiguous sequence of necessary glyphs in a single range-request, thereby minimizing overhead.

Note: Reordering glyphs in a font is the same conceptual operation as renaming glyphs to have different glyph IDs. Therefore, this operation cannot be completed if glyph IDs must be preserved. Because glyph IDs are internal to text processing procedures and are not persisted, this requirement is not expected to be particularly burdensome.

One suggested method of sorting the glyphs in the file is by usage document frequency inside a relevant corpus.

A corpus is defined to be a collection of documents, where a documents includes a collection of glyphs necessary to render some textual content.

Note: For a particular website, a corpus might be defined to be individual page loads of pages on that website.

The usage document frequency of a particular glyph inside a corpus is defined by the number of documents in the corpus which use that glyph, divided by the number of documents in the corpus.

Note: This is distinct, but similar, to the number of times the glyph is used throughout the entire corpus.

The usage document frequency of the glyphs in a range-request optimized font should be decreasing throughout the font; that is, the most frequently used glyphs should have the lowest glyph IDs.

Note: Glyph ID 0 cannot be renamed in OpenType, TrueType, WOFF, and WOFF 2 fonts. All other glyphs can be renamed.

Note: Because the goal is simply to minimize overhead by placing similarly-used glyphs together, it may actually be possible to do better than ordering by simple frequency for a particular corpus. For example, some corpuses may have cliques of glyphs which have different frequencies but which nevertheless always seem to be used together.

A suggested ordering is included in Appendix A below.

1.3. Browser Behaviors

1.3.1. First Request

When a browser encounters the CSS opt-in mechanism, it is instructed to use IFT to load the fonts. First, it follows the steps from IFT method selection. If those steps result in using the range-request method, the rest of this section applies.

The IFT method selection involves a single round-trip to the server, and if the range-request method is being used, the server’s response starts sending the font file to the browser. The browser should start parsing the partial font data as it is being loaded from the server. The browser should not wait until the entire file has been received before parsing its contents.

There is a certain amount of data from the beginning of the font file which the browser should unconditionally download. The boundary at the end of this data is called the range-request threshold.

Note: The first request does not have to be a range request. If the browser expects the range-request threshold to lie within the first n bytes of the font, the first request may be a range request for the first n bytes of the font. However, a browser may instead make a non-range request, parse the data as it is being streamed from the server, and discover that it has reached the range-request threshold while data is still being streamed.

Once all the data before the range-request threshold has been loaded by the browser, the browser may either close this connection to the server, or it may choose to leave the connection open and let the font data continue loading in the background.

A browser may choose to add a Range header (HTTP Semantics § 14.2 Range) to the initial request during the IFT method selection if it has reason to believe the range it requests will be large enough and it prefers to not close this connection to the server.

Note: Different browsers may choose different range-request thresholds. Some browsers may treat this threshold as occuring at the end of the sfnt tableDirectory. Other browsers may treat this threshold as occurring just before any outline data, provided the outline data appears at the end of the font. Other browsers may place this threshold at the very beginning of the file, thereby treating the whole file as able to be downloaded with range-requests.

1.3.2. Subsequent Requests

After all the data before the range-request threshold has been loaded by the browser, the browser will determine which additional byte ranges in the file are necessary to load. It will then issue HTTP Range Requests (HTTP Semantics §  14. Range Requests) for at least those ranges.

Note: Browsers are encouraged to coalesce range requests for nearby areas of the file, to minimize the amount of range-request overhead required. Browsers are encouraged to inform these coalescing decisions from network configuration parameters and bandwidth / latency observations.

Note: If the font file has followed all of the organization guidelines above, all information required for laying out content and performing shaping will lie before any of the outline data in the file, and every glyph’s outline will be independent from every other glyph. Therefore, the browser can treat the range-request threshold as being just before outline data begins, and once it has loaded up to that threshold, it can lay out page content. After laying out the page, downloading all the necessary outlines can be done with a collection of independent and parallel range requests. This works particularly well for Chinese, Japanese, and Korean fonts, where 90% or more of the font data is outline data.

Note: Another valid alternative is to treat the entire font as residing on an asynchronous virtual filesystem, and have the browser track which ranges of the font it ended up reading during its normal operation. The browser could then request those regions in range requests.

1.4. Server Behaviors

Servers supporting the range-request IFT method must support range requests (HTTP Semantics §  14. Range Requests).

Servers supporting the range-request IFT method should support compression via the Content-Encoding (HTTP Semantics § 8.4 Content-Encoding) header or the Transfer-Encoding header (HTTP/1.1 § 6.1 Transfer-Encoding), rather than having the font file itself be statically compressed.

Privacy Considerations

Please see Privacy Considerations in the main IFT document.

Security Considerations

No Security issues have been raised against this document

Changes

Since the Working Draft of 30 May 2023:

Since the Working Draft of 28 June 2022 (see commit history):

Appendix A: Suggested glyph/character ordering

Note: This section describes ordering of characters, not glyph IDs, because the meaning of glyph IDs are not consistent across different fonts. To optimize a particular font according to the ordering listed here, the characters will have to be mapped to glyph IDs inside the font. This approach of mapping characters to glyphs for ordering purposes works particularly well for ideographic languages with large character sets.

Populate suggested character ordering for range-request method

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

References

Normative References

[IFT]
Chris Lilley; Myles Maxfield; Garret Rieger. Incremental Font Transfer. 28 June 2022. WD. URL: https://www.w3.org/TR/IFT/
[OPENTYPE]
OpenType specification. URL: http://www.microsoft.com/typography/otspec/default.htm
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC7932]
J. Alakuijala; Z. Szabadka. Brotli Compressed Data Format. July 2016. Informational. URL: https://www.rfc-editor.org/rfc/rfc7932
[RFC9110]
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. HTTP Semantics. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9110
[RFC9112]
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. HTTP/1.1. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9112
[TRUETYPE]
TrueType™ Reference Manual. URL: https://developer.apple.com/fonts/TrueType-Reference-Manual/
[WOFF]
Jonathan Kew; Tal Leming; Erik van Blokland. WOFF File Format 1.0. 13 December 2012. REC. URL: https://www.w3.org/TR/WOFF/
[WOFF2]
Vladimir Levantovsky; Raph Levien. WOFF File Format 2.0. 10 March 2022. REC. URL: https://www.w3.org/TR/WOFF2/

Issues Index

Using WOFF2 files with range-request mechanism doesn’t seem to be a viable option ↵
Static file compression compatibility with range-request method ↵
Font Collections support ↵
Supporting fonts with composite glyphs via range-request ↵
Populate suggested character ordering for range-request method ↵