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 -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex