Re: Question about subset/mapping intersection

If we change that so that only one of the subset definition sets needs to
intersect then that prevents an IFT font from expressing a mapping where
you do want two or more of the sets to match (eg. a patch which adds
support for a feature to a specific set of codepoints). I expect this to be
a common pattern so we'll want to support it. The case you mentioned, where
you want a patch to match if at least one of the subset definition sets
intersects can be expressed in the current framework by using multiple
entries. For your example:

Entry 1: codepoints: {}, features: {dlig} -> patch i
Entry 2: codepoints: {a, b, c}, features: {} -> patch i

Would behave the same way as a single entry:

codepoints: {a, b, c}, features: {dlig} -> patch i

where the matching logic was changed to only require at least one
intersection.

On Mon, Apr 29, 2024 at 6:02 PM Skef Iterum <siterum@adobe.com> wrote:

> 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
>