[XeTeX] Kerning flaw with MinionPro & XeTex

[Adam Twardoch (List)]

I have identified this issue as a serious bug in XeTeX.

In MinionPro-Regular.otf (version 2.068 is the one I have, but it's
likely that it applies to all versions), the relevant kerning definition
excerpt looks like the following:

feature kern {
  lookup kern1 {
      pos uni0423 uni0431.ital -53;
    subtable;
      pos [uni040E uni0423 uni0474] [uni0435 uni043E uni0441
      uni0444 uni0451 uni0454 uni0473 uni0431.ital] -118;
   } kern1;
} kern;

This means that there is an individual kern value between uni0423
uni0431.ital with the value of -53, then a subtable break, then a
class-based value for the same pair of -118.

Adobe InDesign CS5 correctly identifies the pair in the first subtable
(-53) as the one that it should apply, and ignores the second value. So
the kern comes out as -53.

It very much looks like XeTeX *incorrectly* parses *both* subtables, and
applies a sum of both the individual and the class value (-53-118 =
-171), which results in a very deep kern, and therefore an overlap.

This seems to be a serious, systematic bug in the way XeTeX (or its
underlying ICU Layout library) processes the GPOS table.

I've made an isolated test case that confirmes it.

I've created a test OpenType font. It defines a kerning pair A B -300, a
subtable break, and again the same pair. InDesign correctly applies only
the first value (-300), which is shown in the
SubtableKernTest-InDesign.pdf file. XeTeX applies both values
consecutively, which is shown in SubtableKernTest-XeTeX.pdf

All the test files (.ttf, .fea feature definitions, .tex and two PDFs)
are available at
http://www.twardoch.com/tmp/SubtableKernTest.zip

I've also sent the test files offline to Jonathan Kew.

Many thanks to Alessandro Ceschini for raising the issue.

Regards,
Adam