Update IFT Client to version w/o Format 1

MODULE.bazel

@@ -79,10 +79,10 @@ http_archive(
 # Fontations
 http_archive(
     name = "fontations",
-    urls = ["https://github.com/googlefonts/fontations/archive/1a8baba89aa129a899bc83b0b610881190f8bbad.zip"],
-    strip_prefix = "fontations-1a8baba89aa129a899bc83b0b610881190f8bbad",
+    urls = ["https://github.com/googlefonts/fontations/archive/f95a2db5b2367ddbe752884c39e13b62a2ea39bd.zip"],
+    strip_prefix = "fontations-f95a2db5b2367ddbe752884c39e13b62a2ea39bd",
     build_file = "//third_party:fontations.BUILD",
-    integrity = "sha256-vyDtQ7LJHdb+l0dz8IYs2jvw9bnQxNvhaZgyRLfnlTA=",
+    integrity = "sha256-ge23kFnixCUiaDdsgf2SZ1v9sqPdduEjss5rjrgUbUs=",
 )
 
 
@@ -101,7 +101,7 @@ crate.from_cargo(
      "@fontations//:font-types/Cargo.toml",
      "@fontations//:fuzz/Cargo.toml",
      "@fontations//:incremental-font-transfer/Cargo.toml",
-     "@fontations//:klippa/Cargo.toml",
+     "@fontations//:skera/Cargo.toml",
      "@fontations//:otexplorer/Cargo.toml",
      "@fontations//:read-fonts/Cargo.toml",
      "@fontations//:shared-brotli-patch-decoder/Cargo.toml",

README.md

@@ -12,7 +12,6 @@ found [here](https://w3c.github.io/IFT/Overview.html).
 The current implementation is capable of producing a spec-compliant encoding, but does not
 yet fully support all aspects of the specification. Notably:
 
-*  Format 1 patch maps are not generated.
 *  Not all encoder config options are supported yet. These are marked as unimplemented in the schema.
 
 Additionally, the produced encodings may not be fully optimized for minimal size yet.

docs/experimental/compiler.md

@@ -137,33 +137,33 @@ Process:
    glyph ids each one contains. Patch sets are cached using design space as a key. The patches are formed by first
    instancing the original font to the patch set's design space and then collecting the specified per glyph data into
    each patch. Lastly, each patch set is assigned a unique compatibility ID.
-   
+
 2. Generate a unique compatibility id for this node. Will be included in all table keyed patches that apply to this node.
-   
+
 3. Generate the list of outgoing edges and jumps. Find the set of segments that are not included in the current node and
    generate an edge for each. Additionally generate any multi segment edges required by the encoder config jump ahead
    and use prefetch list settings. Each edge is described by a subset definition that it adds plus one or more jumps as
    described in the concepts section.
-   
+
 4. If in mixed mode, then generate the glyph keyed patch map using the list of patches from step 1. The encoder config
    specifies the specific conditions for each mapping entry.
-   
+
 5. Using the list of edges from step 3 generate the table keyed patch map with one mapping entry per edge.
 
 6. Construct the font binary for this node. First subset the original font to the base subset definition and then add the
    mapping tables from steps 4 and 5.
-   
+
 7. Cache the node font binary using the base subset definition as the key.
 
 8. For each jump in each edge generate the font binary that would result in following that jump by recursively invoking
    this process where the new base subset definition is the union of this base subset definition and the jumps target
    subset definition. Once we have the jumps font binary, diff the new font binary against the previous one to produce
    the table keyed patch for that jump.
-   
+
    Note: each patch is assigned a unique ID and as an optimization we cache the patch binary by patch id to prevent
    recreating the same patch multiple times. ID's are assigned sequentially as new patches are encountered during
    recursion.
-    
+
 With this recursive process the complete encoding can then be generated by invoking the algorithm on the initial font
 subset definition. From there the complete graph will be traversed and all required patches will be generated.
 
@@ -192,10 +192,10 @@ To keep the shared tuples correct we subset gvar in two steps (note: this is spe
 
 1. Run instancing only, keeping everything else, this matches the processing done while populating glyph keyed
    patches and will result in the same shared tuples.
-    
+
 2. Subset to the initial subset, with no instancing specified. If there is no specified instancing then harfbuzz will not
    modify shared tuples.
-   
+
 #### CFF/CFF2 special casing
 
 A similar issue exists with CFF/CFF2, which also contains common outline data that can't be modified by
@@ -239,10 +239,10 @@ extension various properties of the extension and extended font are tested to en
 * cmap, glyph data presence, and equality is used to ensure the encoded font adds the appropriate glyphs after extension.
 * Number of round trips and total patch loads are checked to ensure the encodings are working efficiently (number of
   round trips being the most important).
-  
+
 These tests are designed to prove that the encoder can produce IFT encodings which can be correctly interpreted and
 extended by a client and result in the desired outcomes in terms of extension and network transfer behaviour.
-  
+
 For future improvements it would be a good idea to also incorporate rendering and/or shaping tests into the integration
 test suite.  A properly encoded IFT font should have the same shaping and rendering behaviour as the original font. It
 should be possible to test for this.
@@ -257,17 +257,14 @@ non-exhaustive list of some possibilities:
 * Finish implementing support for all options in the encoder config schema. There's several options which we do not yet
   have support for.
 
-* Improved patch map compilation to reduce encoded size. The format2 patch map has several tools at it's disposal to
-  produce compact encodings which we are not yet fully leveraging.
-
 * Additionally, some smaller size reductions could be realized by smartly picking entry ids that reduce the total number
   of entry deltas needed in the encoding.
-  
+
 * Correct ordering of table keyed patch map entries. For selecting invalidating patches the spec expects that table
   keyed entries are ordered by the size of the referenced patch. We do not currently do this in produced
   encodings. Following the spec expectation will result in better client behaviour when selecting between multiple
   invalidating patches.
-  
+
 * For patch map entries that represent multiple segments we construct a disjunctive condition (eg. match if A or B is
   needed); however, these entries are guaranteed to always be a super set of the single segment entries so it would be
   better to use conjunctive matching as the multi segment entries should only ever be selected when all included
@@ -277,9 +274,9 @@ non-exhaustive list of some possibilities:
   (for example caching expensive operations). However, there are likely some remaining performance improvement
   opportunities. Some time should be taken to profile the current execution and identify if there are any easy
   performance wins.
-  
+
 * At a higher level, we currently have a two step process for getting an IFT font. 1. Generate segmentation
   plan, 2. Compile the plan into a font. Ultimately, we would like to have a single tool that would automatically
   execute these two steps to produce an IFT font given nothing more than an input font. This would include automatically
   configuring the segmenter so that little to no configuration needs to be provided.
-  
+