2

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.

MWE

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.

\documentclass{minimal}
\usepackage{fontspec}

\directlua{
  fonts.handlers.otf.addfeature{
    name = "asub",
    type = "chainsubstitution",
    lookups = {
      {
        type = "substitution",
        data = {
          ["a"] = "a.end",
        },
      },
    },
    data = {
      rules = {
        {
          after  = { { "." } },
          current = { { "a" } },
          lookups = { 1 },
        },
      },
    },
  }
}


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


\begin{document}


a.


{\itshape a. }


{\bfseries a. }


{\bfseries\itshape a. }


\end{document}

MWE Output

MWE Output

Notes

  • 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.
jasonhathcock
  • 123
  • Does your font support Contxtuals=Final? – Davislor Nov 03 '21 at 04: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. – jasonhathcock Nov 03 '21 at 04: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: https://tex.stackexchange.com/questions/42114/why-should-the-minimal-class-be-avoided/42115 – Cicada Nov 03 '21 at 07: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 Nov 03 '21 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 Nov 03 '21 at 16:13
  • We make progress. Using https://gist.github.com/michal-h21/5922487ed74f3c1b6a34c49904971b0d by @michal.h21 (see https://tex.stackexchange.com/q/453224 for the context), we find that — in Garamond Premier Pro — a.end corresponds to 983046 and d.end to 983047, whereas in the italic a.end is 983045 and d.end is 983046. So the problem becomes making different features for the upright and the italic, referencing these numbers. Not sure I can do it — certainly not before this busy semester is done, but maybe someone else with the fonts can pursue this sooner. – Thérèse Nov 03 '21 at 16:51
  • @Thérèse Thank you so much for all this information, and for this resource to find the corresponding character numbers. The problem goes deeper than I first expected. This explains to me how the swap is happening with the italic fonts. I am still puzzled as to how the +salt feature gets it correct every time. – jasonhathcock Nov 03 '21 at 17:34
  • can you try with the dev version of luaotfload? You need to clone the git repo, switch to the dev branch and then l3build install will install it in your texmfhome (if you have texlive) in tex\latex-dev. You can then test it by compiling with lualatex-dev – Ulrike Fischer Nov 05 '21 at 08:17
  • @UlrikeFischer Thanks for the instructions; I had never tried installing the dev version from github until now. Unfortunately, the output of the MWE (with the class changed from minimal to article for safety) is the same. – Thérèse Nov 05 '21 at 11:31
  • @Thérèse you are sure that you used the new version? The log-file should show something like fontloader-2021-09-14.lua and luaotfload 2021-05-21 3.19-dev. I can't test it, but you could open an issue at the luaotfload tracker. – Ulrike Fischer Nov 05 '21 at 11:54
  • @UlrikeFischer The log opens with “This is LuaHBTeX, Version 1.13.2 (TeX Live 2021) (format=lualatex-dev 2021.10.24) 5 NOV 2021 07:55” … “Lua module: luaotfload 2021-05-21 3.18 Lua based OpenType font support”. I’ve opened an issue at https://github.com/latex3/luaotfload/issues/205 (though someone who understands the innards of fonts would probably describe it better). 3.19??? – Thérèse Nov 05 '21 at 12:09
  • @Thérèse this doesn't look as if you actually use the dev version. This should have the version 3.19-dev as I wrote above. – Ulrike Fischer Nov 05 '21 at 12:17
  • @UlrikeFischer Then I’m afraid I don’t know how to do this. I did git clone https://github.com/latex3/luaotfload.git, changed to the directory created, typed l3build install, and then lualatex-dev example.tex. Any missing steps? – Thérèse Nov 05 '21 at 12:23
  • @Thérèse Before l3build install, run git checkout dev to switch to the development branch. Otherwise you just reinstall the last released version. – Marcel Krüger Nov 05 '21 at 12:25
  • @MarcelKrüger Thank you! Success! The PDF output is at https://www.dropbox.com/s/8o2ojf8vjk23ob1/eg.pdf?dl=0 in case you want to write an answer with an image but don’t have the fonts. – Thérèse Nov 05 '21 at 12:38
  • @MarcelKrüger By the way, I tried the dev version of luaotfload with variable fonts. With the last released version, some variable fonts look as if their outlines have been chewed by rats, but with the dev version, almost all of those defects are gone. Excellent work! – Thérèse Nov 11 '21 at 03:12
  • @Thérèse Thank Hans Hagen and the Context guys. All I did was complain and provide example documents... (I noticed the issue while working on variable font support for harf mode, but that requires engine changes and therefore has to wait till TeX Live 2022.) – Marcel Krüger Nov 11 '21 at 08:06

1 Answers1

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:

Run:

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.

Marcel Krüger
  • 34,151