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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
_______________________________________________
HarfBuzz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
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,
_______________________________________________
HarfBuzz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/harfbuzz
