Hello Hans,
> Also, one can - as I posted before - apply some positioning feature,
> so I don't see what use a mark related extension one would add even
> if I would do that just because it's easy.
I repeat: The change in the 'mark2base' table is just a few lines – I
have to add a single anchor position for the diacritic and to add this
diacritic to the lookup's coverage – six lines of code or so in total
in the `glyphs` table. In `tfmdata`, as shown in the diff attached to
a previous mail, this corresponds to 1670(!) lines of code. It is
this enormous discrepancy that irks me.
This is *not* a criticism of LuaTeX. I fully understand why `tfmdata`
is constructed the way it is. It's just frustrating that there isn't
a simple and elegant solution to get the desired effect. I started
with reading Paul Isambert's excellent TUGboat article, not being
aware that the described machinery (involving the `glyphs` table)
isn't (any longer?) actively used for loading fonts in luatex (and
LuaLaTeX in particular).
> Also, one can - as I posted before - apply some positioning feature,
You can do that for selected pairs, but to do that *in general*, as
the 'mark2base' feature does, you need many, many such pairs, which I
consider not elegant.
> so I don't see what use a mark related extension one would add even
> if I would do that just because it's easy.
It's only easy if you want to handle selected pairs.
> Maybe if someone asked on the context list I'd bother.
Well, I'm not using ConTeXt...
Anyway, I'll try to find a programmatic solution based on `tfmdata`:
* Reconstruct the `mark2base` coverage table.
* Reconstruct a table of top anchor points of all related base
characters.
* Construct a proper entry for `tfmdata` based on those two tables.
Werner
