diff --git a/Overview.bs b/Overview.bs
index bb3ee2a..2a444df 100644
--- a/Overview.bs
+++ b/Overview.bs
@@ -758,7 +758,7 @@ If the error occurred during [$Load patch file$], then the client may continue t
If an invalidation group is non empty and being selected from, but only contains failed patches then extension has failed and cannot
continue.
-In the case of all other errors the client must not attempt to further extend the font subset.
+In the case of all other errors the client must not attempt to further extend the font subset.
Selecting Invalidating Patches {#invalidating-patch-selection}
--------------------------------------------------------------
@@ -768,8 +768,8 @@ patch entry from a list of candidate entries. The selection criteria used has a
perform the extension. Round trips are costly so for maximum performance patches should be selected in a way that minimizes the total number of needed
round trips.
-The following selection criteria minimizes round trips and must be used by the client when selecting a single partial or full invalidation patch in step 8
-of [$Extend an Incremental Font Subset$]:
+The following selection criteria minimizes round trips and must be used by the client when selecting a single partial or full invalidation patch in step 8
+of [$Extend an Incremental Font Subset$]:
1. If one or more candidate entries have previously had their associated patch file loaded by step 9 of [$Extend an Incremental Font Subset$],
then in the following steps only consider candidate entries whose patch file is already loaded or is currently being loaded. Otherwise consider all
@@ -935,7 +935,7 @@ Extensions to the Font Format {#font-format-extensions}
An [=incremental font=] follows the existing [[open-type|OpenType]] format, but includes two new
[[open-type/otff#table-directory|tables]] identified by the 4-byte tags 'IFT ' and 'IFTX'. These new tables are both
-[=patch map|patch maps=]. All incremental fonts must contain the 'IFT ' table. The 'IFTX' table is optional. When both tables are
+[=patch map|patch maps=]. All incremental fonts must contain the 'IFT ' table. The 'IFTX' table is optional. When both tables are
present, the mapping of the font as a whole is the union of the mappings of the two tables. The two new tables are used only in this
specification and are not being added to the [[open-type|Open-Type]] specification.
@@ -975,16 +975,16 @@ CFF and CFF2 Incremental Fonts {#cff}
For incremental fonts that contain glyph outlines stored in a [[open-type/cff|CFF]] or [[open-type/cff2|CFF2]] table there are some
additional restrictions:
-* CFF and CFF2 tables in an incremental font must have the CharStrings INDEX data structure be last element of the
- table (followed only by 0 padding to a four-byte word boundary).
+* CFF and CFF2 tables in an incremental font must have the CharStrings INDEX data structure be last element of the
+ table (followed only by 0 padding to a four-byte word boundary).
-* CFF and CFF2 tables in an incremental font must not have any other data elements that overlap the CharStrings INDEX data
- structure.
+* CFF and CFF2 tables in an incremental font must not have any other data elements that overlap the CharStrings INDEX data
+ structure.
-* The 'IFT ' [=patch map=] table must contain an offset
+* The 'IFT ' [=patch map=] table must contain an offset
([=Format 1 Patch Map/cffCharStringsOffset=], [=Format 1 Patch Map/cff2CharStringsOffset=]
[=Format 2 Patch Map/cffCharStringsOffset=], or [=Format 2 Patch Map/cff2CharStringsOffset=])
- to the start of the CharStrings INDEX data for the CFF and/or CFF2 table.
+ to the start of the CharStrings INDEX data for the CFF and/or CFF2 table.
These three requirements allow for the glyph keyed patch application implementation on CFF and CFF2 tables to be significantly
simplified. They allow glyph data to be inserted into CFF/CFF2 tables without changing the offsets to any other data elements
@@ -1059,13 +1059,13 @@ the encoded bytes at the start of every iteration to pick up any changes made in
| uint16 |
maxGlyphMapEntryIndex |
- The largest [=Glyph Map=] entry index encoded in this table. Must be less than or equal to maxEntryIndex. |
+ The largest [=Glyph Map=] entry index encoded in this table. Must be less than or equal to maxEntryIndex. |
| uint24 |
glyphCount |
- Number of glyphs that mappings are provided for.
- Must match the number of glyphs in the the font file.
+ | Number of glyphs that mappings are provided for.
+ Must match the number of glyphs in the the font file.
Note: the number of glyphs in the font is encoded in the font file. At the time of writing, this value is listed in the
[[open-type/maxp|maxp]] table; however, future font format extensions may use alternate tables to encode the value for number of
@@ -1109,7 +1109,7 @@ the encoded bytes at the start of every iteration to pick up any changes made in
| patchFormat |
Specifies the format of the patches linked to by urlTemplate.
- Must be set to one of the format numbers from the [[#font-patch-formats-summary]] table.
+ Must be set to one of the format numbers from the [[#font-patch-formats-summary]] table.
|
@@ -1415,7 +1415,7 @@ The algorithm:
| defaultPatchFormat |
Specifies the format of the patches linked to by urlTemplate (unless overridden by an entry).
- Must be set to one of the format numbers from the [[#font-patch-formats-summary]] table.
+ Must be set to one of the format numbers from the [[#font-patch-formats-summary]] table.
|
@@ -1639,7 +1639,7 @@ being requested.
| Fixed |
end |
- End (inclusive) of the segment. Must be greater than or equal to start. This value uses the user axis scale:
+ End (inclusive) of the segment. Must be greater than or equal to start. This value uses the user axis scale:
[[open-type/otvaroverview#coordinate-scales-and-normalization]].
|
@@ -2125,8 +2125,8 @@ The algorithm:
id32 |
The input entry ID encoded as a [[rfc4648#section-7|base32hex]] string (using the digits 0-9, A-V) with padding
- omitted. When entry ID is an unsigned integer it must first be converted to a big endian 32 bit unsigned integer,
- but then all leading bytes that are equal to 0 are removed before encoding. (For example, when the
+ omitted. When entry ID is an unsigned integer it must first be converted to a big endian 32 bit unsigned integer,
+ but then all leading bytes that are equal to 0 are removed before encoding. (For example, when the
integer is less than 256 only one byte is encoded.) If entry ID is 0 then one zero byte is encoded. When
entry ID is a string the raw bytes are encoded as base32hex.
|
@@ -2163,9 +2163,9 @@ The algorithm:
id64 |
The input entry ID encoded as a [[rfc4648#section-5|base64url]] string (using the digits A-Z, a-z, 0-9, -
- (minus) and _ (underline)) with padding included. Because the padding character is '=', it must
- be URL-encoded as '%3D'. When entry ID is an unsigned integer it must first be converted to a big
- endian 32 bit unsigned integer, but then all leading bytes that are equal to 0 are removed before encoding.
+ (minus) and _ (underline)) with padding included. Because the padding character is '=', it must
+ be URL-encoded as '%3D'. When entry ID is an unsigned integer it must first be converted to a big
+ endian 32 bit unsigned integer, but then all leading bytes that are equal to 0 are removed before encoding.
(For example, when the integer is less than 256 only one byte is encoded.) If the entry ID is 0 then one
zero byte is encoded. When the entry ID is a string its raw bytes are encoded as
[[rfc4648#section-5|base64url]].
@@ -2343,7 +2343,7 @@ or remove tables in a [=font subset=].
|
| Tag |
format |
- Identifies the format as table keyed, must be set to 'iftk' |
+ Identifies the format as table keyed, must be set to 'iftk' |
| uint32 |
@@ -2363,7 +2363,7 @@ or remove tables in a [=font subset=].
| Offset32 |
patches[patchesCount+1] |
- Each entry is an offset from the start of this table to a [=TablePatch=]. Offsets must be sorted in ascending order. |
+ Each entry is an offset from the start of this table to a [=TablePatch=]. Offsets must be sorted in ascending order. |
@@ -2480,7 +2480,7 @@ A glyph keyed patch contains a collection of data chunks that are each associate
| Tag |
format |
- Identifies the format as glyph keyed, must be set to 'ifgk' |
+ Identifies the format as glyph keyed, must be set to 'ifgk' |
| uint32 |
@@ -2531,15 +2531,15 @@ A glyph keyed patch contains a collection of data chunks that are each associate
glyphIds[glyphCount] |
An array of glyph indices included in the patch. Elements are uint24's if bit 0 (least significant bit) of
- [=Glyph keyed patch/flags=] is set, otherwise elements are uint16's. Must be in ascending sorted order and must not
- contain any duplicate values.
+ [=Glyph keyed patch/flags=] is set, otherwise elements are uint16's. Must be in ascending sorted order and must not
+ contain any duplicate values.
|
| Tag |
tables[tableCount] |
- An array of [[open-type/otff#table-directory|tables]] (by tag) included in the patch. Must be in ascending sorted
- order and must not contain any duplicate values. For sorting tag values are interpreted as a 4 byte big endian
+ | An array of [[open-type/otff#table-directory|tables]] (by tag) included in the patch. Must be in ascending sorted
+ order and must not contain any duplicate values. For sorting tag values are interpreted as a 4 byte big endian
unsigned integer and sorted by the integer value. |
@@ -2549,7 +2549,7 @@ A glyph keyed patch contains a collection of data chunks that are each associate
An array of offsets of to glyph data for each table. The first [=GlyphPatches/glyphCount=] offsets corresponding to
[=GlyphPatches/tables|tables[0]=], the next [=GlyphPatches/glyphCount=] offsets (if present) corresponding to
[=GlyphPatches/tables|tables[1]=], and so on. All offsets are from the start of the [=GlyphPatches=] table.
- Offsets must be sorted in ascending order.
+ Offsets must be sorted in ascending order.
@@ -2614,9 +2614,9 @@ The algorithm:
* The specific process for synthesizing the new table, depends on the specified format of the
[[open-type/otff#table-directory|table]]. Any non-glyph associated data should be copied from the table in
base font subset. Tables of the type [[open-type/glyf|glyf]],
- [[open-type/gvar|gvar]], [[open-type/cff|CFF]], or [[open-type/cff2|CFF2]] are supported. Entries for tables
- of any other types must be ignored. When updating [[open-type/glyf|glyf]] the [[open-type/loca|loca]] table must be updated as
- well. No other tables in the font can be modified as a result of this step. Notably this means that a patch cannot add glyphs
+ [[open-type/gvar|gvar]], [[open-type/cff|CFF]], or [[open-type/cff2|CFF2]] are supported. Entries for tables
+ of any other types must be ignored. When updating [[open-type/glyf|glyf]] the [[open-type/loca|loca]] table must be updated as
+ well. No other tables in the font can be modified as a result of this step. Notably this means that a patch cannot add glyphs
with indices beyond the numGlyphs specified in [[open-type/maxp|maxp]].
[[open-type/cff|CFF]], [[open-type/cff2|CFF2]], and [[open-type/gvar|gvar]] have variable sized offsets to per glyph data. If
@@ -2649,15 +2649,15 @@ process of using an encoder, including whatever parameters an encoder requires o
case.
The [=incremental font=] and associated patches produced by a compliant encoder:
-1. Must meet all of the requirements in [[#font-format-extensions]] and [[#font-patch-formats]].
+1. Must meet all of the requirements in [[#font-format-extensions]] and [[#font-patch-formats]].
-2. Must be consistent, that is: for any possible [=font subset definition=] the result of invoking [$Extend an Incremental Font Subset$]
+2. Must be consistent, that is: for any possible [=font subset definition=] the result of invoking [$Extend an Incremental Font Subset$]
with that subset definition and the [=incremental font=] must always be the same regardless of the particular order
- of patch selection chosen in step 8 of [$Extend an Incremental Font Subset$].
+ of patch selection chosen in step 8 of [$Extend an Incremental Font Subset$].
-3. Must respect patch invalidation criteria. Any patch which is part of an IFT encoding when applied to a compatible [=font subset=]
+3. Must respect patch invalidation criteria. Any patch which is part of an IFT encoding when applied to a compatible [=font subset=]
must only make changes to the [=patch map=] compatibility IDs which are compliant with the [[#font-patch-invalidations]] criteria
- for the invalidation mode declared by the associated [=patch map entries=].
+ for the invalidation mode declared by the associated [=patch map entries=].
4. When an encoder is used to transform an existing font into an [=incremental font=] the associated
[$Fully Expand a Font Subset|fully expanded font$] should be equivalent to the existing font. An equivalent fully expanded font
@@ -3071,16 +3071,16 @@ take privacy into account when encoding their own fonts or obtaining already-enc
As required by [[!css-fonts-4]]:
- "A Web Font must not be accessible in any other Document from the one which either is associated with
- the @font-face rule or owns the FontFaceSet. Other applications on the device must not be able to access
- Web Fonts." - [[css-fonts-4#web-fonts]]
+ "A Web Font must not be accessible in any other Document from the one which either is associated with
+ the @font-face rule or owns the FontFaceSet. Other applications on the device must not be able to access
+ Web Fonts." - [[css-fonts-4#web-fonts]]
Since IFT fonts are treated the same as regular fonts in CSS ([[#opt-in]]) these requirements apply and avoid information leaking across
origins.
Similar requirements apply to font palette values:
- "An author-defined font color palette must only be available to the documents that reference it. Using an author-defined color palette
+ "An author-defined font color palette must only be available to the documents that reference it. Using an author-defined color palette
outside of the documents that reference it would constitute a security leak since the contents of one page would be able to
affect other pages, something an attacker could use as an attack vector." - [[css-fonts-4#font-palette-values]]
@@ -3190,7 +3190,7 @@ path: feature-registry.html
Appendix B: Extension Algorithm Example Execution
-This appendix provides examples of how a typical IFT font would be processed by the [[#extend-font-subset]] algorithm.
+This appendix is not normative. It provides examples of how a typical IFT font would be processed by the [[#extend-font-subset]] algorithm.
Example 1: Table and Glyph Keyed Patches {#appendix-b-example-1}
----------------------------------------------------------------
@@ -3555,4 +3555,4 @@ Iteration 2:
Iteration 3:
* Steps 2 through 6 - there are no remaining intersecting entries so the algorithm terminates. The font subset is returned and now ready to render any
- content covered by the target subset definition.
+ content covered by the target subset definition.
\ No newline at end of file