> There's not enough context in the attached diff to actually see > anything.
Oh, sorry, I thought it was clear that the diff is related to
`tfmdata.resources.sequences[50].steps[1].coverage[868]`.
> Can you try again but with "table.serialize" replaced with [...]
Thanks! [It took me a while to find out that I have to use the
`--luadebug` command-line option so that `debug.getinfo` is defined.]
The diff is attached (compressed this time, calling `diff` on sorted
input).
>> the tiny modification in the font's 'mark2base' lookup explodes,
>> causing four large, identical changes to `tfmdata` subtables.
>
> Lua tables are reference types, so those 4 subtables may actually be
> the same table, meaning that a single modification might change all
> of them.
Yes, it looks like that.
> Also, most of the subtables are unused, so you probably only need to
> change a single value anyways.
I don't think so. In `tfmdata`, the data from the 'mark2base' lookup
is no longer represented in a compact form. Instead, it is expanded
so that each accent glyph has all the necessary deltas for all base
glyphs. While this speeds up the processing of the 'mark2base'
lookup, it makes manipulation much more complicated. Of course I
could restrict the necessary changes of the diacritic for combinations
with base glyphs 'o' and 'u', say, omitting all other combinations,
but this is missing the point of what I want to do – for such a
restricted solution I could do what Hans has suggested, namely to
construct a simple 'kern' feature.
I think everything boils down to the question whether LuaTeX by
default loads a font internally with
```
f = fontloader.open("EBGaramond-Regular.otf")
fonttable = fontloader.to_table(f)
```
then converting `fonttable` to a `tfmdata` structure. I want to
access `fonttable` before this step happens. How can I do that?
>> In other words, it is unrealistic to modify `tfmdata` directly, and
>> I need to hook into LuaTeX's OpenType font handler one step
>> earlier, AFAICS. How can I do that?
>
> With the caveat that this depends on internal implementation
> details, and is therefore unsupported and could change at any time,
> "fonts.handlers.otf.readers.loadfont" is the earliest point that you
> can modify the font data: [...]
Thanks, but again, this code is manipulating `tfmdata` AFAICS, so
there is no advantage w.r.t. compactness of the 'mark2base' lookup
data.
Werner
ebgaramond.dump.diff.xz
Description: Binary data
