[HarfBuzz] Kerning issue with Linux Libertine smallcaps

[Khaled Hosny]

Great, thanks Jonathan.

Regards,
Khaled

On Sun, Aug 04, 2013 at 12:41:47PM +0100, Jonathan Kew wrote:
> 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
> >>
> >