Today's fontspec update breaking fontspec_pass_args?

Question

A few hours ago, the following code worked perfectly (LuaLatex, TeXlive 2016 on Ubuntu):

\DeclareDocumentCommand \SetBaseFont { o m }
 { \__fontspec_pass_args:nnn \__fontspec_SetBaseFont:nn {#1} {#2} }
\cs_new:Nn \__fontspec_SetBaseFont:nn
 {
  \long\xdef\@basefontfeatures{#1}
  \long\xdef\@basefontname{#2}
  \global\@basefontsettrue
  \ignorespaces
 }

Now, it fails. In the intervening time, all I did was update texlive via tlmgr. No change to my own code. I did notice that fontspec was among the updated packages.

I have narrowed it down to the line with fontspec_pass_args in it.

Anyone else having a similar problem?

EDIT: Definitely a change in fontspec code (says this humble user). I edited out \__fontspec_pass_args:nnn everywhere it appeared in my own code. Then for my font definitions, unlike before, I needed to use the option brackets (even when no feature was needed): \SetBaseFont[]{Some Font} and now my code compiles. Fortunately, whatever the problem code does, was not something I needed. Note that I used similar code for fonts with much simpler definitions, so it's not a matter of \long\xdef or anything like that.

MORE EDIT:

In the log file (once I got my code to compile, by editing as described above) I see numerous messages that look like the following. I don't recall having seen them before, but maybe I just didn't notice. Since TU relates to fontspec, here is an example. The problem was actually detected by microtype. All the fonts I use are Open Type:

Package microtype Warning: Unknown slot number of character
(microtype)                `\textgreater '
(microtype)                in font encoding `TU' in protrusion list
(microtype)                `T1-default'.

Maybe that's related, maybe not.

YET MORE AGAIN:

My question actually answers itself! The reason that fontspec_pass_args causes an error, is simply that the latest version of fontspec (2.5c, from three weeks ago) no longer has that command. So, if others are not experiencing my problem, it was because they are not mimicking the older fontspec code, in their own code. But the strange messages about TU are still there, and mysterious.

Answer 1

There are two aspects to your question:

• The microtype / TU stuff will be fixed in a LaTeX2e update planned for sometime Really Soon

• With regard to your code breaking, I'll refer you to the expl3 programming style guide (l3styleguide.pdf):

Private functions (those starting \__) should not be used between modules.

But that's probably an overly brief explanation :)

The \__fontspec_pass_args:nnn function was designed to manipulate optional arguments so that you could write

\fontspec[<options>]{fontname}

OR

\fontspec{fontname}[<options>]

BUT NOT

\fontspec[<options>]{fontname}[<options>]

This was seen, how should I say, rather unfavourably amongst the LaTeX3 illuminati in the tex.sx chat room, because it goes against the general philosophy of the xparse package to provide a consistent way to deal with command arguments.

So it took me a while to drop it, perhaps unfortunately, and now fontspec allows the "double optional" form as well:

\fontspec[<options>]{fontname}[<options>]

This uses something along the lines of

\DeclareDocumentCommand \fontspec { O{} m O{} }

In 3rd party code, no-one should ever have needed to replicate the old behaviour provided by \__fontspec_pass_args:nnn.

Indeed, the API for fontspec provides a standard way to load fonts without using internal \__-commands. If that doesn't provide what is needed, feel free to file a feature request in the Github repository.