Re: Should we Drop Patch Map Format 1?

Hey Garret,

Agreed, I think we should drop format 1 from the spec.

That said, running the eligibility check across the font collection sounds worthwhile before we finalize. It'll give us concrete numbers to point to.

Regards,
Scott



 
Scott Treude
Principal Software Engineer
Monotype
Monotype Imaging Inc
New York, New York 
10018
Phone 
Mobile 
Monotype.com
 
 
From: Garret Rieger <grieger@google.com>
Date: Thursday, July 23, 2026 at 6:01 PM
To: w3c-webfonts-wg (public-webfonts-wg@w3.org) <public-webfonts-wg@w3.org>
Subject: Should we Drop Patch Map Format 1?

A quick refresher for some context:

  *   The patch map in an IFT font tells the client which patches to download based on the content present. We currently have two formats.
  *   Format 2: general purpose, capable of representing arbitrary mappings, including those with composite boolean conditions.
  *   Format 1: A limited but more compact representation. Each codepoint maps to exactly one patch. No composite boolean conditions.

I've started implementing format 1 encoding support and realized that due to the format's restrictive nature, the vast majority of fonts would be unable to utilize it with the current segmenter implementation.

Since the segmenter by default produces segmentations based on conditions per glyph any fonts with any sort of complexity (eg. composite glyphs, layout substitution features, UVS) will almost always produce patch mappings incompatible with format 1. On the table keyed side the use of "jump ahead" and prefetch lists (the default settings) precludes format 1.

Including format 1 in the spec adds complexity to both the encoder and client implementations (also requires additional conformance tests). If format 1 is unlikely to be used in practice, I'm not sure the additional complexity is justified.

The main advantage to keeping format 1 around is that where it can be used it provides more compact patch map encodings. Otherwise it provides no functionality not present in format 2 (for example current ift encoder does not utilize format 1 at all). If it's rarely used in practice, this benefit is not very impactful.

Given this, should we just remove format 1 from the specification? Gathering concrete data might help inform the decision, if needed. I'm thinking I might set up a format 1 eligibility check in the segmenter and then run that across the open source font collection to determine what % of fonts could utilize format 1.