GPOS–2: Coverage in Pair Adjustment Positioning

This test case exercises the handling of the Coverage field in Pair Adjustment Positioning subtables. The font contains a ‘GPOS’ table whose ‘kern’ feature enables a single lookup of type 2. This lookup contains three PairPos format 1 subtables. All three subtables specify ◯ U+25EF LARGE CIRCLE as their Coverage, but no other glyphs.

The first subtable contains a single PairSet for kerning ◯ U+25EF LARGE CIRCLE and U+0020 SPACE. When rendering the string ◯☼, an OpenType implementation should decode this subtable because the first glyph ◯ is in its Coverage. However, because there’s no match for the second glyph ☼, a correct implementation should proceed to the second subtable.
The second subtable has two PairSets, both kerning ◯ U+25EF LARGE CIRCLE and ☼ U+263C WHITE SUN WITH RAYS. The first PairSet applies kerning so that the two symbols will exactly overlap. If the second PairSet was applied, it would add spacing to move the two symbols away from each other. But a correct text rendering engine should walk the PairSets in the order given by the font, and stop processing after finding the first match.
The third subtable has yet another PairSet for kerning ◯ U+25EF LARGE CIRCLE and ☼ U+263C WHITE SUN WITH RAYS. A correct implementation should have found a matching PairSet in the second subtable and then stopped processing. Therefore, the implementation should ignore the pair adjustment positioning data in the third subtable.

If your implementation is correct, the two symbols ◯ and ☼ should exactly overlap when drawn next to each other. If you see two separate symbols in the rightmost column below, your text rendering engine fails to correctly handle Coverage inside GPOS pair adjustment positioning subtables.

	◯	☼	◯☼
Expected
Observed
Conformance