> BTW, it's very easy to patch the original `EBGaramond-Regular.otf`
> file using the XML dump as produced by the `ttx` font
> compiler/decompiler: For the 'mark' lookup you add glyph 'uni0364'
> to its 'MarkCoverage' table (as the 28th entry counting from zero),
> then adding an entry in the 'MarkArray' table:
>
> ```
> <MarkRecord index="28">
> <Class value="0"/>
> <MarkAnchor Format="1">
> <XCoordinate value="115"/>
> <YCoordinate value="440"/>
> </MarkAnchor>
> </MarkRecord>
> ```
>
> However, I consider this as a last-resort solution that I would like
> to avoid.
>
> So I ask again: Is there a solution to construct a tiny 'marktobase'
> feature with `fonts.handlers.otf.addfeature` (or something else)?
I had a closer look into the files of 'luaotfload', and my conclusion
is that there is no 'fonts.handlers.otf.addfeature' support for the
GPOS `mark2base` lookup type at all. Sigh.
With
```
f = fontloader.open("EBGaramond-Regular.otf")
fonttable = fontloader.to_table(f)
```
the OTF file modified as described contains the following data added
to `fonttable.glyphs[741]` (which is for glyph `uni0364`):
```
["anchors"] = {
["mark"] = {
["Anchor-0"] = {
["x"] = 115,
["y"] = 440,
["lig_index"] = 0 }
}
},
["class"] = mark,
```
It seems that I have to do a brute-force approach by directly
modifying `fonttable`. My question is: How can I insert this data to
the `fonttable` structure whenever the (unmodified)
`EBGaramond-Regular.otf` gets loaded? Is there a hook for that?
Werner
