shadowfacts/fonttools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[feaLib] Merge multiple LigatureCaret statements for the same glyph

Browse Source 
The current OpenType Feature File specification is silent about
what the proper behavior should be when a single glyph has multiple
LigatureCaretByPos or LigatureCaretByIndex statements.  After
this change, we match the behavior of Adobe's `makeotf` tool.

Arguably, `makeotf` might not be optimal in its current behavior,
but it seems better to match the existing toolchain than to have
two conflicting interpretations of an ambiguous spec.  Once the
specification gets clarified, we will of course follow.

See https://github.com/adobe-type-tools/afdko/issues/95 for the
spec discussion.
This commit is contained in:
Sascha Brawer 2016-01-08 11:03:46 +01:00
parent 89ac1b2d0d
commit 657a4463f3
5 changed files with 27 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Lib/fontTools/feaLib/builder.py
View File

@ -596,11 +596,11 @@ class Builder(object):
def add_ligatureCaretByIndex_(self, location, glyphs, carets):
for glyph in glyphs:
self.ligatureCaretByIndex_[glyph] = carets
self.ligatureCaretByIndex_.setdefault(glyph, set()).update(carets)
def add_ligatureCaretByPos_(self, location, glyphs, carets):
for glyph in glyphs:
self.ligatureCaretByPos_[glyph] = carets
self.ligatureCaretByPos_.setdefault(glyph, set()).update(carets)
def _makeOpenTypeDeviceTable(deviceTable, device):

8
Lib/fontTools/feaLib/testdata/LigatureCaretByIndex.fea vendored
View File

@ -1,4 +1,10 @@
table GDEF {
LigatureCaretByIndex [c_t s_t] 11;
LigatureCaretByIndex f_f_i 66 33;
# The OpenType Feature File specification does not define what should
# happen when there are multiple LigatureCaretByPos statements for
# the same glyph. Our behavior matches that of Adobe makeotf v2.0.90.
# https://github.com/adobe-type-tools/afdko/issues/95
LigatureCaretByIndex o_f_f_i 66 33;
LigatureCaretByIndex o_f_f_i 55;
} GDEF;

7
Lib/fontTools/feaLib/testdata/LigatureCaretByIndex.ttx vendored
View File

@ -6,7 +6,7 @@
<LigCaretList>
<Coverage>
<Glyph value="c_t"/>
<Glyph value="f_f_i"/>
<Glyph value="o_f_f_i"/>
<Glyph value="s_t"/>
</Coverage>
<!-- LigGlyphCount=3 -->
@ -17,11 +17,14 @@
</CaretValue>
</LigGlyph>
<LigGlyph index="1">
<!-- CaretCount=2 -->
<!-- CaretCount=3 -->
<CaretValue index="0" Format="2">
<CaretValuePoint value="33"/>
</CaretValue>
<CaretValue index="1" Format="2">
<CaretValuePoint value="55"/>
</CaretValue>
<CaretValue index="2" Format="2">
<CaretValuePoint value="66"/>
</CaretValue>
</LigGlyph>

8
Lib/fontTools/feaLib/testdata/LigatureCaretByPos.fea vendored
View File

@ -1,4 +1,10 @@
table GDEF {
LigatureCaretByPos [c_h c_k] 500;
LigatureCaretByPos f_f_i 600 300;
# The OpenType Feature File specification does not define what should
# happen when there are multiple LigatureCaretByPos statements for
# the same glyph. Our behavior matches that of Adobe makeotf v2.0.90.
# https://github.com/adobe-type-tools/afdko/issues/95
LigatureCaretByPos o_f_f_i 700 300;
LigatureCaretByPos o_f_f_i 900;
} GDEF;

9
Lib/fontTools/feaLib/testdata/LigatureCaretByPos.ttx vendored
View File

@ -7,7 +7,7 @@
<Coverage>
<Glyph value="c_h"/>
<Glyph value="c_k"/>
<Glyph value="f_f_i"/>
<Glyph value="o_f_f_i"/>
</Coverage>
<!-- LigGlyphCount=3 -->
<LigGlyph index="0">
@ -23,12 +23,15 @@
</CaretValue>
</LigGlyph>
<LigGlyph index="2">
<!-- CaretCount=2 -->
<!-- CaretCount=3 -->
<CaretValue index="0" Format="1">
<Coordinate value="300"/>
</CaretValue>
<CaretValue index="1" Format="1">
<Coordinate value="600"/>
<Coordinate value="700"/>
</CaretValue>
<CaretValue index="2" Format="1">
<Coordinate value="900"/>
</CaretValue>
</LigGlyph>
</LigCaretList>