Multiple alternate features are broken

[khaledhosny]

In this example the second and third primes should be bigger and standing on the base line (the third is the biggest), compare with XeTeX output:

\input ifluatex.sty
\ifluatex
  \input luaotfload.sty
  \def\mode{mode=base}
\else
  \def\mode{}
\fi
\font\zero="XITS Math:\mode;script=math;language=DFLT"
\font\one= "XITS Math:\mode;script=math;language=DFLT;+ssty=1"
\font\two= "XITS Math:\mode;script=math;language=DFLT;+ssty=2"
\zero ^^^^2032 
\one  ^^^^2032 
\two  ^^^^2032 
\bye

[phi-gamma]

Confirmed with Context:

%% https://github.com/lualatex/luaotfload/issues/79

\definefontfeature[zero][default]
\definefontfeature[one][default][mode=base,script=math,language=dflt,ssty=1]
\definefontfeature[two][default][mode=base,script=math,language=dflt,ssty=2]
\definefont[zero][name:XITS Math*default]
\definefont[one] [name:XITS Math*one]
\definefont[two] [name:XITS Math*two]

\starttext
  \zero \char"2032 
  \one  \char"2032 
  \two  \char"2032 
\stoptext

[phi-gamma]

Can you try the feature spec without leading + character:

%% https://github.com/lualatex/luaotfload/issues/79
\ifdefined \directlua
  \ifdefined \luatexsuppresslongerror
    \input luaotfload.sty
  \fi
  \def\mode{node}
  \font\zero="file:latinmodern-math.otf:mode=\mode;script=math;language=DFLT"
  \font\one= "file:latinmodern-math.otf:mode=\mode;script=math;language=DFLT;ssty=1"
  \font\two= "file:latinmodern-math.otf:mode=\mode;script=math;language=DFLT;ssty=2"
\else
  \font\zero="[latinmodern-math.otf]:script=math;language=DFLT"
  \font\one= "[latinmodern-math.otf]:script=math;language=DFLT;+ssty=1"
  \font\two= "[latinmodern-math.otf]:script=math;language=DFLT;+ssty=2"
\fi
\zero ^^^^2032 
\one  ^^^^2032 
\two  ^^^^2032 
\bye

[khaledhosny]

This seems to work. The +foo=n is the XeTeX syntax and I now vaguely remember that I had to patch the parser to accept it as well. Now either fontspec has to be updated or support for that syntax re-added, if the later then while at it should be mad to start counting from 0 not one so that it is compatible with XeTeX (I just found that in TL 2013 I broke XeTeX and it was counting from one, I just fixed it).

[phi-gamma]

The +foo=n is the XeTeX syntax and I now vaguely remember that I had to patch the parser to accept it as well.

This fits the puzzle. Afair I stumbled on one rule in the option parser that I couldn’t make sense of.

Now either fontspec has to be updated or support for that syntax re-added

It’ll be handled in luaotflaod, but undocumented.

it should be mad to start counting from 0 not one so that it is compatible with XeTeX

Do you mean that the first script style gets index 0? We sure could have an exception for that, but I’m not sure how general it should be, e.g. if it should apply for other features (like stylistic sets) as well.

[khaledhosny]

Do you mean that the first script style gets index 0?

Right.

We sure could have an exception for that, but I’m not sure how general it should be, e.g. if it should apply for other features (like stylistic sets) as well.

It should apply to any multiple alternates feature. Actually, it should apply to any feature, so that +foo=0 does not disable the feature (since in ConText foo=0 is equal to XeTeX’s -foo).

[phi-gamma]

It should apply to any multiple alternates feature.

That’s gsub lookup type 3. Asking as a complete font n00b, is there a definitive list of those somewhere?

Actually, it should apply to any feature, so that +foo=0 does not disable the feature (since in ConText foo=0 is equal to XeTeX’s -foo).

If I did this (offset values by one) globally this would mess up compatibility with Luatex-Fonts on a syntactical level, which would make testing much more tedious and error-prone. But I’ll meet you halfway there: with this modification phi-gamma@0127869 all Xetex-style key-value requests are incremented by one before passing them on to the fontloader. Thus +ssty=0 is equivalent to ssty=1 and so on -- Xetex-style implies Xetex-behavior. Actually that even renders the initial + meaningful in some weird way. Btw. afaics none of the examples in the Xetex companion nor the reference actually mention the leading + for key-value options.

Speaking of syntax: according to the Xetex Reference, the following is a valid request, too:

"Charis SIL/GR:Small Caps=True;"

-- so effectively at least some options should work without the plus sign? If so, which ones? Also, the options letterspace, embolden (‽), extend, and slant accept floats as value.

[khaledhosny]

That’s gsub lookup type 3. Asking as a complete font n00b, is there a definitive list of those somewhere?

The type is determined from the lookup not from the tag, any tag can be used for any feature (except a few feature that has to follow a strict behaviour like init or medi).

Xetex-style implies Xetex-behavior.

That is what I was suggesting.

Btw. afaics none of the examples in the Xetex companion nor the reference actually mention the leading + for key-value options.

Key-value options indeed have no leading +, that is only for font features, but right the reference manual does not mention multiple alternates features. I’ll added that.

"Charis SIL/GR:Small Caps=True;"

Graphite (and AAT features) follow a different syntax, and since LuaTeX does not support them anyway, there is no need to support it (well you can parse it and issue a warning if you want).

[phi-gamma]

The type is determined from the lookup not from the tag, any tag can be used for any feature (except a few feature that has to follow a strict behaviour like init or medi).

So the type of a lookup is known only after the font is loaded, and any feature could be type 3 ... that’s not good for validation. Since it doesn’t make sense I’ve removed the test against an alternate list but kept the bogus test for an “integer” as a safeguard.

Key-value options indeed have no leading +, that is only for font features,

Okay. Reading XeTeX_ext.c I see that it uses different subparsers for both cases.

Graphite (and AAT features) follow a different syntax, and since LuaTeX does not support them anyway, there is no need to support it (well you can parse it and issue a warning if you want).

Irregular options fields are ignored.