[HarfBuzz] Kerning issue with Linux Libertine smallcaps

[Jonathan Kew]

The problem arises because the first subtable includes the "V" (and "T") 
glyphs in its coverage (as first glyph of the pair), but then the a.sc 
and hyphen.sc glyphs are not included in the ClassDef2 table, so they 
map to class 0, for which the kerning is zero. But harfbuzz still 
considers the subtable to have applied, so it stops iterating over them 
remaining subtables.

The description of ClassDefFormat2 says that "Any glyph not covered by a 
ClassRangeRecord is assumed to belong to Class 0". If that is the case, 
then I think this is a font bug: any first-glyph mentioned in a 
PairPosFormat2 subtable's coverage when ClassDef2 uses format 2 will, in 
effect, "shadow" all subsequent subtables, so the same first-glyph 
cannot be used again.

It may be, however, that (at least for PairPosFormat2 purposes), if the 
second glyph maps to Class 0 it should in fact be treated as "not 
covered by the subtable", and so we should continue with the subsequent 
subtables. If we do this (see attached patch) then those pairs do indeed 
kern. But we should test this in Uniscribe to see whether this 
interpretation holds.

JK

On 4/8/13 11:35, Khaled Hosny wrote:
> Interesting. One obvious difference is that 5.1.3 has one lookup in the
> kern feature, but 5.3.0 splits it into four.
>
> Now if I reorder the lookups so that the one involving smallcaps comes
> first, “Va” and “T-” get kerned, but “VA” gets unkerned. If I move the
> small caps lookup to a separate feature, all kerning is applied
> (regardless of the order).
>
> Not sure if this is a font bug or HarfBuzz bug (just if the Uniscribe
> backednd supported user features…).
>
> Regards,
> Khaled
>
> On Sun, Aug 04, 2013 at 10:36:13AM +0100, Jonathan Kew wrote:
>> Hi Khaled,
>>
>> Interestingly, it kerns as expected when using a somewhat older
>> LinLibertine release (5.1.3) that I happen to have on hand. But with
>> 5.3.0, I see the problem as reported.
>>
>> I haven't yet inspected the fonts to see what changed in the kern
>> feature between these versions, but understanding that change might
>> help pinpoint what's going wrong.
>>
>> JK
>>
>>
>> On 4/8/13 08:25, Khaled Hosny wrote:
>>> Hi Behdad,
>>>
>>> People are reporting kerning issues with Linux Libertine smallcaps,
>>> for example, there is no kerning between smallcap “Va” and “T-” in the
>>> example below, though “ata” and “VA” are kerned (the font’s class
>>> kerning lookups seems to cover all of them):
>>>
>>> hb-view LinLibertine_R.otf "VataT-VA" --features="+smcp"
>>>
>>> Regards,
>>> Khaled
>>>
>>>
>>>
>>> _______________________________________________
>>> HarfBuzz mailing list
>>> HarfBuzz at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>>>
>>
>> _______________________________________________
>> HarfBuzz mailing list
>> HarfBuzz at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>

-------------- next part --------------
diff --git a/src/hb-ot-layout-gpos-table.hh b/src/hb-ot-layout-gpos-table.hh
index 2cf90b7..0340f6c 100644
--- a/src/hb-ot-layout-gpos-table.hh
+++ b/src/hb-ot-layout-gpos-table.hh
@@ -744,6 +744,7 @@ struct PairPosFormat2
     unsigned int klass1 = (this+classDef1).get_class (c->buffer->cur().codepoint);
     unsigned int klass2 = (this+classDef2).get_class (c->buffer->info[skippy_iter.idx].codepoint);
     if (unlikely (klass1 >= class1Count || klass2 >= class2Count)) return TRACE_RETURN (false);
+    if (klass2 == 0) return TRACE_RETURN (false);
 
     const Value *v = &values[record_len * (klass1 * class2Count + klass2)];
     valueFormat1.apply_value (c->font, c->direction, this,