Closed jasperhabicht closed 1 year ago
The example in the documentation doesn't enable any features, it disables them o avoid such issues since feature handling in combo
fonts doesn't work. It also uses base
fonts which work much better in that context.
Generally 1-to-1 substitution features (like the ones in your example) should work for all fonts as long as mode=base
is used, while other features will apply the feature from the first font everywhere (which usually won't work).
We could document this, but I think we should just deprecate the whole mechanism and add a huge warning not to use it to the documentation.
The example in the documentation doesn't enable any features, it disables them o avoid such issues since feature handling in
combo
fonts doesn't work. It also usesbase
fonts which work much better in that context.
Thank you! You are indeed right in that the above code example works using mode=base
. I think a short notice in the manual would be helpful.
Did I get you right that you want to deprecate the combo-font mechanism? May I ask why, since I think that the combo-font mechanism is a nice thing to have because it allows font replacement for specific codepoints, that is, not based on scripts or languages and without using a fallback which would somehow require the relevant glyphs are not contained in the other font.
I closed this issue, since it is obviously not about a bug, but just something I got wrong. Feel free to reopen it, if you think there is something to be don.
The problem with combo:
is that it just uses some glyphs from another font without integrating it them correctly into the new font. As you saw font features break in various way. Them not being applied is one thing, but we also use features from a different font than the one the glyphs are from:
\documentclass{article}
\usepackage{luaotfload}
\font \serif = {name:lmroman10-regular.otf:mode=base;script=latn;language=DFLT} at 10pt
\font \sans = {name:lmsans10-regular.otf:mode=base;script=latn;language=DFLT} at 12pt
\font \combined = "combo: 1 -> \fontid \serif ; 2 -> \fontid \sans , 0x66*0x74; "
\begin{document}
\combined
Here all fs and ts are written in sans-serif and slightly bigger, but ligatures involving these characters like ff are not affected.
\end{document}
This is somewhat documented, but I can't imagine that it's ever the intended behavior. If we want to allow selecting individual characters from different fonts, then we should just extend the fallback
system to be more configurable.
In the manual (2022-10-03 v3.23) on page 22 (7. Combining fonts, 7.2 Combinations) there is an example showing how to combine different fonts which are then selected according to their codepoints.
The example shows that it should be possible to select font features for each of these fonts. However the following example shows that OpenType features are obviously not recognized except for the first font in the combo list. (This behaviour is also reported in the manual of the package
combofont
which seemingly relies on the mechanisms of theluaotfload
package.)I would expect that OpenType features are recognized for all fonts in the combo list, since the example in the manual acutally selects features for each of the fonts used in the combi list.