Font features no longer work with Babel

[borisveytsman]

Description

After the recent upgrade font features are no longer recognized if the font is declared as \babelfont

Check/indicate

• [x] Relevant for XeTeX
• [x] Relevant for LuaTeX
• [x] Issue tracker has been searched for similar issues?

Minimal example demonstrating the issue

\documentclass{article}
\usepackage[english]{babel}
\RequirePackage{fontspec}
\babelfont[english]{rm}
[
  Ligatures=TeX,
  Numbers=Lowercase,
  Extension=.otf,
  UprightFont=*-Regular,
  ItalicFont=*-Italic,
  BoldFont=*-Bold,
  BoldItalicFont=*-BoldItalic,
]{EBGaramond}
\begin{document}
1 2 3
\end{document}

Further details

The example above gives the following warnings

Package fontspec Warning: 
(fontspec)                OpenType feature 'Numbers=Lowercase' (onum) not
(fontspec)                available for font 'EBGaramond-Regular' with script
(fontspec)                'Latin' and language 'English'.

Package fontspec Warning: 
(fontspec)                OpenType feature 'Numbers=Lowercase' (onum) not
(fontspec)                available for font 'EBGaramond-Bold' with script
(fontspec)                'Latin' and language 'English'.

Package fontspec Warning: 
(fontspec)                OpenType feature 'Numbers=Lowercase' (onum) not
(fontspec)                available for font 'EBGaramond-Italic' with script
(fontspec)                'Latin' and language 'English'.

Package fontspec Warning: 
(fontspec)                OpenType feature 'Numbers=Lowercase' (onum) not
(fontspec)                available for font 'EBGaramond-BoldItalic' with
(fontspec)                script 'Latin' and language 'English'.

The numbers are output in upper case.

If I declare the font without babel, it works and produces correct output

\documentclass{article}
\usepackage[english]{babel}
\RequirePackage{fontspec}
\setmainfont
[
  Ligatures=TeX,
  Numbers=Lowercase,
  Extension=.otf,
  UprightFont=*-Regular,
  ItalicFont=*-Italic,
  BoldFont=*-Bold,
  BoldItalicFont=*-BoldItalic,
]{EBGaramond}
\begin{document}
1 2 3
\end{document}

[u-fischer]

It fails without babel too as soon as you declare the language:

\documentclass{article}
\usepackage[english]{babel}
\RequirePackage{fontspec}
\setmainfont
[
  Ligatures=TeX,
  Numbers=Lowercase,
  Extension=.otf,
  UprightFont=*-Regular,
  ItalicFont=*-Italic,
  BoldFont=*-Bold,
  BoldItalicFont=*-BoldItalic,
  %Script=Latin,
  Language=English
]{EBGaramond}
\begin{document}
1 2 3
\end{document}

[wspr]

I haven’t tested this yet but I think I see what is happening. @khaledhosny suggested that scripts (and I assumed languages) should be passed through to the engine even if the font didn’t have them.

What I neglected to pick up on about that is then certain font features wouldn’t necessarily be available since a fallback script or language wouldn’t have been chosen.

I don’t think I can check features without also checking for scripts/languages, so I suppose I should just stop checking and pass through the feature tag regardless, and let the engines sort it all out…

[wspr]

@jbezos — it looks like removing the check from fontspec will fix this issue. But perhaps in parallel I should check what the "correct" procedure here should be. Would it be helpful for me to add a fontspec option like TryLanguage=English which sets the font language only if the font supports it, otherwise keeps the font language setting as is?

[wspr]

@borisveytsman — the current develop branch fixes this issue, but there could be side-effects since we are now passing through all requested font features to the engine even if the font doesn't contain them. Are you in a position to be able to test slightly more broadly?

[wspr]

@zauguin — perhaps I should also ask for your opinion on this change, Marcel :) Do you agree this is the correct approach to take?

[jbezos]

@wspr To be honest, I don’t know what’s better.

[khaledhosny]

HarfBuzz may try other scripts if the font does not support the requested script (IIRC, it falls back to DFLT then latn), and for language it will use the defaultLangSys (AKA dflt) if the requested language is missing from the font. So fontspec might think the font doesn't support a feature but HarfBuzz ends up applying it.

So I suggest to check features only if both the requested script and language are present in the font, and to always pass along the requested features to be on the safe side as asking for an unsupported feature doesn't have any side effects.

[borisveytsman]

@wspr

@borisveytsman — the current develop branch fixes this issue, but there could be side-effects since we are now passing through all requested font features to the engine even if the font doesn't contain them. Are you in a position to be able to test slightly more broadly?

Surely.