error if a feature has not value

[u-fischer]

\documentclass{article}

\begin{document}
\font\test={file:texgyreheros-regular.otf:language=;} \test

abc
\end{document}

fails with

)...lltexmf/tex/latex-dev/luaotfload/luaotfload-features.lua:261: bad argument #
1 to 'lower' (string expected, got boolean).
<to be read again> 
\test 
l.304 ...:texgyreheros-regular.otf:language=;} \test

(The missing value is due a fontspec bug, see https://github.com/wspr/fontspec/issues/403, but imho luaotfload should catch it if possible.)

[zauguin]

I think there are three parts here:

• First, how to handle features with empty value in general. Currently they are not allowed, so when

  \font\test={file:texgyreheros-regular.otf:language=;} \test

  and therefore the requested font name is file:texgyreheros-regular.otf:language=;, the parsing stops after language without looking at the final =; because that would no longer be valid. We could keep it that way because empty values seem kind of useless anyway, we could allow them and just pass them on as empty strings or we could assign a special value. For example we could treat feat= the same as -feat by mapping the empty string to false.

  I'm not sure what I would prefer here, all options seem weird.

  • Better handling of parsing failures. Right now when a requested font name can not be parsed, we look at the maximal initial substring which can be parsed. So

    file:texgyreheros-regular.otf:language=;

  is parsed as

  file:texgyreheros-regular.otf:language

  which isn't completly unreasonable, but e.g.

  file:texgyreheros-regular.otf:somethingweird=;+smcp

  is parsed as

  file:texgyreheros-regular.otf:somethingweird

  silently dropping the additional feature. I think it would make sense to throw an error if parsing fails to avoid such hidden and hard to find changes, but that could break compatibility.

  • language/script should handle unexpected value types better. Currently ...:language or :+language or :language=5 lead to low level errors like you have seen, it might be better to create proper error messages in such cases. This has a pretty low priority though because the existing error isn't that bad: After all, the error is a bad argument because a bool has been passed instead of a string.