Skip to content

Added conformance span tags to Overview.bs #291

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 23 commits into from
Aug 11, 2025
Merged

Added conformance span tags to Overview.bs #291

Changes from all commits
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
876ffd0
initial comformance tagging
streude Jul 30, 2025
60ca7c7
adding more conformance span tags
streude Jul 30, 2025
5ab15f0
adding more conformance span tags
streude Jul 30, 2025
9f04d16
adding more conformance span tags
streude Jul 30, 2025
9c9bcad
adding more conformance span tags
streude Jul 30, 2025
093f0a4
adding more conformance span tags
streude Jul 30, 2025
3e3c772
adding more conformance span tags
streude Jul 30, 2025
370b179
adding more conformance span tags
streude Jul 30, 2025
a72fba1
added some id values
streude Jul 30, 2025
468e9b8
reverting addition of conformance tags
streude Jul 31, 2025
23e0954
pulled in 'not normative' text
streude Jul 31, 2025
decd96d
adding tags
streude Aug 1, 2025
ab8ac86
adding tags
streude Aug 1, 2025
d9b6881
adding tags
streude Aug 1, 2025
b87e7f5
adding tags
streude Aug 1, 2025
1582cb7
adding tags
streude Aug 1, 2025
e5e8ad8
adding tags
streude Aug 1, 2025
9a5542f
adding tags
streude Aug 1, 2025
29dfa34
adding ids to tags
streude Aug 1, 2025
8c1c984
adding ids to tags
streude Aug 1, 2025
a963855
adding ids to tags
streude Aug 1, 2025
117d987
Fixed duplicate span id
streude Aug 1, 2025
05b8240
Added section designations for repeated variables
streude Aug 6, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 43 additions & 43 deletions Overview.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
<span class="conform" id="conform-stop-extend-after-errors">In the case of all other errors the client must not attempt to further extend the font subset.</span>

Selecting Invalidating Patches {#invalidating-patch-selection}
--------------------------------------------------------------
Expand All @@ -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$]:
<span class="conform" id="conform-required-selection-criteria">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$]</span>:

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
Expand Down Expand Up @@ -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=]. <span class="conform" id="conform-require-ift-table">All incremental fonts must contain the 'IFT ' table.</span> 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.

Expand Down Expand Up @@ -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).
* <span class="conform" id="conform-charstrings-location">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).</span>

* CFF and CFF2 tables in an incremental font must not have any other data elements that overlap the CharStrings INDEX data
structure.
* <span class="conform" id="conform-cff-tables-no-overlap">CFF and CFF2 tables in an incremental font must not have any other data elements that overlap the CharStrings INDEX data
structure.</span>

* The 'IFT ' [=patch map=] table must contain an offset
* <span class="conform" id="conform-ift-table-contians-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.</span>

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
Expand Down Expand Up @@ -1059,13 +1059,13 @@ the encoded bytes at the start of every iteration to pick up any changes made in
<tr>
<td>uint16</td>
<td><dfn for="Format 1 Patch Map">maxGlyphMapEntryIndex</dfn></td>
<td>The largest [=Glyph Map=] entry index encoded in this table. Must be less than or equal to maxEntryIndex.</td>
<td><span class="conform" id="conform-format1-entry-index-maximum">The largest [=Glyph Map=] entry index encoded in this table. Must be less than or equal to maxEntryIndex.</span></td>
</tr>
<tr>
<td>uint24</td>
<td><dfn for="Format 1 Patch Map">glyphCount</dfn></td>
<td>Number of glyphs that mappings are provided for.
Must match the number of glyphs in the the font file.
<td><span class="conform" id="conform-format1-glyph-count-matches">Number of glyphs that mappings are provided for.
Must match the number of glyphs in the the font file.</span>

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
Expand Down Expand Up @@ -1109,7 +1109,7 @@ the encoded bytes at the start of every iteration to pick up any changes made in
<td><dfn for="Format 1 Patch Map">patchFormat</dfn></td>
<td>
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.
<span class="conform" id="conform-format1-valid-format-number">Must be set to one of the format numbers from the [[#font-patch-formats-summary]] table.</span>
</td>
</tr>
<tr>
Expand Down Expand Up @@ -1415,7 +1415,7 @@ The algorithm:
<td><dfn for="Format 2 Patch Map">defaultPatchFormat</dfn></td>
<td>
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.
<span class="conform" id="conform-format2-valid-format-number">Must be set to one of the format numbers from the [[#font-patch-formats-summary]] table.</span>
</td>
</tr>
<tr>
Expand Down Expand Up @@ -1639,7 +1639,7 @@ being requested.
<td>Fixed</td>
<td><dfn for="Design Space Segment">end</dfn></td>
<td>
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. <span class="conform" id="conform-design-space-segment-end-valid-value">Must be greater than or equal to start.</span> This value uses the user axis scale:
[[open-type/otvaroverview#coordinate-scales-and-normalization]].
</td>
</tr>
Expand Down Expand Up @@ -2125,8 +2125,8 @@ The algorithm:
<td><var>id32</var></td>
<td>
The input <var>entry ID</var> encoded as a [[rfc4648#section-7|base32hex]] string (using the digits 0-9, A-V) with padding
omitted. When <var>entry ID</var> 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. <span class="conform" id="conform-entry-id-must-be-converted">When <var>entry ID</var> 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.</span> (For example, when the
integer is less than 256 only one byte is encoded.) If <var>entry ID</var> is 0 then one zero byte is encoded. When
<var>entry ID</var> is a string the raw bytes are encoded as base32hex.
</td>
Expand Down Expand Up @@ -2163,9 +2163,9 @@ The algorithm:
<td><var>id64</var></td>
<td>
The input <var>entry ID</var> 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 <var>entry ID</var> 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. <span class="conform" id="conform-equal-sign-encoded">Because the padding character is '=', it must
be URL-encoded as '%3D'.</span> <span class="conform" id="conform-entry-id-converted">When <var>entry ID</var> 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.</span>
(For example, when the integer is less than 256 only one byte is encoded.) If the <var>entry ID</var> is 0 then one
zero byte is encoded. When the <var>entry ID</var> is a string its raw bytes are encoded as
[[rfc4648#section-5|base64url]].
Expand Down Expand Up @@ -2343,7 +2343,7 @@ or remove tables in a [=font subset=].
<tr>
<td>Tag</td>
<td>format</td>
<td>Identifies the format as table keyed, must be set to 'iftk'</td>
<td><span class="conform" id="conform-table-keyed-format-equals-iftk">Identifies the format as table keyed, must be set to 'iftk'</span></td>
</tr>
<tr>
<td>uint32</td>
Expand All @@ -2363,7 +2363,7 @@ or remove tables in a [=font subset=].
<tr>
<td>Offset32</td>
<td><dfn for="Table keyed patch">patches</dfn>[patchesCount+1]</td>
<td>Each entry is an offset from the start of this table to a [=TablePatch=]. Offsets must be sorted in ascending order.</td>
<td>Each entry is an offset from the start of this table to a [=TablePatch=]. <span class="conform" id="conform-table-keyed-patches-sort-ascending">Offsets must be sorted in ascending order.</span></td>
</tr>
</table>

Expand Down Expand Up @@ -2480,7 +2480,7 @@ A glyph keyed patch contains a collection of data chunks that are each associate
<tr>
<td>Tag</td>
<td>format</td>
<td>Identifies the format as glyph keyed, must be set to 'ifgk'</td>
<td><span class="conform" id="conform-conform-glyph-keyed-format-equals-ifgk"">Identifies the format as glyph keyed, must be set to 'ifgk'</span></td>
</tr>
<tr>
<td>uint32</td>
Expand Down Expand Up @@ -2531,15 +2531,15 @@ A glyph keyed patch contains a collection of data chunks that are each associate
<td><dfn for="GlyphPatches">glyphIds</dfn>[glyphCount]</td>
<td>
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. <span class="conform" id="conform-glyph-keyed-glyph-ids-sort-ascending-unique">Must be in ascending sorted order and must not
contain any duplicate values.</span>
</td>
</tr>
<tr>
<td>Tag</td>
<td><dfn for="GlyphPatches">tables</dfn>[tableCount]</td>
<td>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
<td>An array of [[open-type/otff#table-directory|tables]] (by tag) included in the patch. <span class="conform" id="conform-glyph-keyed-tables-sort-ascending-unique">Must be in ascending sorted
order and must not contain any duplicate values.</span> For sorting tag values are interpreted as a 4 byte big endian
unsigned integer and sorted by the integer value.</td>
</tr>
<tr>
Expand All @@ -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.
<span class="conform" id="conform-glyph-keyed-glyph-data-offsets-sort-ascending">Offsets must be sorted in ascending order.</span>
</td>
</tr>
<tr>
Expand Down Expand Up @@ -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
<var>base font subset</var>. 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. <span class="conform" id="conform-table-entries-ignore-others">Entries for tables
of any other types must be ignored.</span> <span class="conform" id="conform-updating-glyf-updates-loca">When updating [[open-type/glyf|glyf]] the [[open-type/loca|loca]] table must be updated as
well.</span> 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
Expand Down Expand Up @@ -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. <span class="conform" id="conform-encoding-must-meet-extensions-format">Must meet all of the requirements in [[#font-format-extensions]] and [[#font-patch-formats]].</span>

2. Must be consistent, that is: for any possible [=font subset definition=] the result of invoking [$Extend an Incremental Font Subset$]
2. <span class="conform" id="conform-encoding-must-be-consistent">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$].</span>

3. Must respect patch invalidation criteria. Any patch which is part of an IFT encoding when applied to a compatible [=font subset=]
3. <span class="conform" id="conform-encoding-must-respect-patch-invalidation-criteria">Must respect patch invalidation criteria.</span> <span class="conform" id="conform-encoding-only-alter-compatibility-ids">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=].</span>

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
Expand Down Expand Up @@ -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]]
"<span class="conform" id="conform-web-font-not-accessible-from-different-document">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.</span> <span class="conform" id="conform-web-font-not-accessible-from-other-apps">Other applications on the device must not be able to access
Web Fonts.</span>" - [[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
"<span class="conform" id="conform-palette-not-accesible-from-different-documents">An author-defined font color palette must only be available to the documents that reference it.</span> 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]]

Expand Down Expand Up @@ -3190,7 +3190,7 @@ path: feature-registry.html
<h2 id="extension-example">
Appendix B: Extension Algorithm Example Execution</h2>

This appendix provides examples of how a typical IFT font would be processed by the [[#extend-font-subset]] algorithm.
<em>This appendix is not normative.</em> 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}
----------------------------------------------------------------
Expand Down Expand Up @@ -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.