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
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.
Best Answer
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:
Then compiling with
lualatex-dev
will use the development version of luaotfload instead of the last release and the code in the question works.