[HarfBuzz] Kerning issue with Linux Libertine smallcaps

[Jonathan Kew]

FWIW, testing LinLibertine in IE10 on Win8, I see the same behavior as 
in Firefox (using harfbuzz): the <V, a.sc> and <T, hyphen.sc> pairs are 
NOT kerned.

So I believe this supports the interpretation that this is a font bug, 
and we should -not- special-case Class0 as per the experimental harfbuzz 
patch.

(In principle, a font could have real kerning values specified for 
<classN, class0>, although it's most likely that class0 will always be 
used for the default do-nothing case.)

On 4/8/13 12:02, Jonathan Kew wrote:
> 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
>>
>