latex3 / luaotfload

OpenType font loader for LuaTeX
Other
56 stars 6 forks source link

OpenType features not recognized for all fonts in combo list #248

Closed jasperhabicht closed 1 year ago

jasperhabicht commented 1 year ago

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 the luaotfload package.)

\documentclass{article}
\usepackage{luaotfload}
\font \sourceserifproRA = {name:Source Serif Pro-Regular:mode=node;language=DFLT;+tlig} at 10pt
\font \sourceserifproRB = {name:Source Serif Pro-Regular:mode=node;language=DFLT;+tlig;+smcp} at 10pt
\font \sourceserifproRC = "combo: 1 -> \fontid \sourceserifproRA ; 2 -> \fontid \sourceserifproRB , 0x30-0x39; "
\font \sourceserifproRD = "combo: 1 -> \fontid \sourceserifproRB ; 2 -> \fontid \sourceserifproRA , 0x30-0x39; "

\newcommand{\alphabet}{ABCDefgh}
\newcommand{\digits}{0123456789}

\begin{document}

\sourceserifproRA 
Source Serif Pro (without small caps): \par 
0123456789

\bigskip

\sourceserifproRB 
Source Serif Pro (with small caps): \par 
0123456789

\bigskip

\sourceserifproRC 
Source Serif Pro (with small caps only for U+0030 to U+0039): \par 
0123456789 --- not working

\bigskip

\sourceserifproRD
Source Serif Pro (with small caps except for U+0030 to U+0039): \par 
0123456789 --- not working

\end{document}

image

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.

zauguin commented 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.

jasperhabicht commented 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.

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.

zauguin commented 1 year ago

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}

image

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.