1languagesystem DFLT dflt;
2
3@sevenEightNine = [seven eight nine];
4
5feature kern {
6    pos zero 0;
7
8    pos [one two three] <-80 0 -160 0>;
9    pos A <1 2 3 4 <device 11 111, 12 112> <device 13 113, 14 114> <device 16 116> <device NULL>>;
10    pos B <1 2 3 4 <device 11 111, 12 112> <device 13 113, 14 114> <device 16 116> <device NULL>>;
11    pos C <1 2 3 4 <device 11 -2, 14 1> <device 13 -3, 15 1> <device 11 -8, 14 7> <device 13 8, 15 1>>;
12    pos four 400;
13    pos four.oldstyle 401;
14    pos five <-80 0 -160 0>;
15    pos six -200;
16    pos @sevenEightNine -100;
17
18    pos P <1 0 800 0>;
19    pos Q <1 0 801 0>;
20    pos R <1 0 802 0>;
21    pos S <1 1 803 0>;
22    pos T <1 1 804 0>;
23    pos U <1 1 805 0>;
24
25    # The AFDKO makeotf tool accepts re-definitions of previously defined
26    # single adjustment positionings, provided the re-definition is using
27    # the same value.  We replicate this behavior.
28    pos four 400;
29    pos four <0 0 400 0>;
30    pos nine -100;
31} kern;
32
33# According to the OpenType Feature File specification section 2.e.iv,
34# the following should be interpreted as vertical advance adjustment
35# because -100 (a value record format A) appears within a ‘vkrn’ feature.
36# However, the AFDKO makeotf tool v2.0.90 (built on Nov 19, 2015) still
37# makes it a horizontal advance adjustment.  In our implementation,
38# we follow the specification, so we produce different output than makeotf.
39# https://github.com/adobe-type-tools/afdko/issues/85
40feature vkrn {
41    pos A -100;
42} vkrn;
43