- From: Skef Iterum <siterum@adobe.com>
- Date: Tue, 30 Apr 2024 00:02:46 +0000
- To: "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
- Message-ID: <CH3PR02MB91395A8EAA9677E55AD0A2AFB91B2@CH3PR02MB9139.namprd02.prod.outlook.com>
On this: 1. For each set in <var>subset definition</var> (codepoints, feature tags, design space) check if the set intersects the corresponding set from <var>mapping entry</var>. A set intersects when: <table> <tr> <th></th><th>subset definition set is empty</th><th>subset definition set is not empty</th> </tr> <tr> <th>mapping entry set is empty</th><td>true</td><td>true</td> </tr> <tr> <th>mapping entry set is not empty</th><td>false</td><td>true if the two sets intersect</td> </tr> </table> 2. If all sets checked in step 1 intersect, then return true for <var>intersects</var> otherwise false. Suppose I have an IFTB-style chunk that adds a certain list of code points and then also some codepoints associated with those for some feature. (This may be impossible with the prototype IFTB encoding, but that's a limitation I was intending to remove down the line.) Say that there are some discretionary ligatures the encoder decides to throw in. If the client isn't looking for dlig, and the patch only lists dlig, then the intersection for feature tags is false. And then, according to step 2, the intersection generally is false. One can imagine analogous circumstances with design spaces. Maybe only a certain subset of glyphs "use" an axis, and the first patch that adds any of those glyphs may add that axis. Are there reasons we are intentionally precluding those options with this algorithm? If rule 2 read "If any sets..." rather than "If all sets...", what would go poorly? Is the idea that there may be multiple patches covering the same set members and also others, and we want the most specific patch? (In which case this algorithm would effectively require a span of patches such that there was always one with the right, matching specificity?) Are we sure that's the right trade-off? Skef
Received on Tuesday, 30 April 2024 00:02:51 UTC