Basic Problem Statement

I would like to enable some (but not all) stylistic alternate ".end" characters from an OpenType font, on condition that they replace terminal characters in a word.

Unfortunately, using the +salt feature enables them globally throughout text, which I do not want.

So far, I have tried using \directlua to build a chainsubstitution, then add it via RawFeature, but this is producing very odd results.

I expect this is likely an error in usage of \directlua on my part---one for which I would greatly appreciate correction.

Indeed, to me, my approach seems a bit of a hack, particularly when it comes to listing all the conditions to trigger substitution. If there is an altogether different method for making this substitution smartly, I am happy to hear about it.


This is a simple example of the problem. I am using Adobe Garamond Premier Pro. Regrettably, I am unaware of a free choice at hand which features the same ".end" characters for this situation.

For ease, (I think) I am setting "a.end" to replace "a" whenever "a" occurs just before a period.

With this snippet, the output is as expected only with the normal Roman and boldface fonts. All italic shapes somehow produce the "d.end" character instead.


    name = "asub",
    type = "chainsubstitution",
    lookups = {
        type = "substitution",
        data = {
          ["a"] = "a.end",
    data = {
      rules = {
          after  = { { "." } },
          current = { { "a" } },
          lookups = { 1 },

\setmainfont[{RawFeature=+asub}]{Garamond Premier Pro}



{\itshape a. } 

{\bfseries a. }

{\bfseries\itshape a. }


MWE Output

MWE Output


  • Using +salt does produce the correct "a.end" glyph, no matter what choice of bold and/or italic. On checking the different OTF files with FontForge, I see the "a.end" glyph is not in the same slot for each font, but the name is always the same.
  • This is just one example of such a broken substitution. The "h.end" character behaves similarly.
  • Does your font support Contxtuals=Final?
    – Davislor
    Commented Nov 3, 2021 at 4:05
  • @Davislor Sadly, no, Garamond Premier Pro does not. I checked otfinfo for each of the fonts, and fina is unlisted, confirmed by fontspec warning in console output on trying to add the feature. But that is a good point; it would surely make this a simpler matter were it available. Commented Nov 3, 2021 at 4:23
  • Unrelated: use a typesetting class (like article, say) for an MWE; minimal class is "regrettably" named and was intended to test for package-loading dependencies - it defines normalsize font and that's about it: tex.stackexchange.com/questions/42114/…
    – Cicada
    Commented Nov 3, 2021 at 7:14
  • It would be difficult to track down, but I suspect a bug in the fonts. Trying the MWE with Brioso Pro, which is another Adobe type family containing a.end and d.end in both roman and italic, I get the expected results in the regular and bold roman, but the final form of à in the regular and bold italic. But with Le Monde Livre Classic, the output of the MWE is perfect.
    – Thérèse
    Commented Nov 3, 2021 at 15:51
  • The only other font family I have with the necessary glyphs is LCT Sbire. The output is as expected in the upright faces, but shows an alternate ampersand in the italic faces.
    – Thérèse
    Commented Nov 3, 2021 at 16:13

1 Answer 1


This was caused by a bug in luaotfload. It will be fixed in version 1.19, but until that is released the development version can be used to avoid the error:


git clone --branch dev --depth 1 https://github.com/latex3/luaotfload.git
cd luaotfload
l3build install

Then compiling with lualatex-dev will use the development version of luaotfload instead of the last release and the code in the question works.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .