Vor ein paar Stunden hat der folgende Code einwandfrei funktioniert (LuaLatex, TeXlive 2016 unter 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
}
Jetzt schlägt es fehl. In der Zwischenzeit habe ich nur Texlive über tlmgr aktualisiert. Keine Änderung an meinem eigenen Code. Mir ist aufgefallen, dass Fontspec zu den aktualisierten Paketen gehörte.
fontspec_pass_argsIch habe es auf die darin enthaltene Zeile eingegrenzt .
Hat jemand sonst ein ähnliches Problem?
BEARBEITEN: Definitiv eine Änderung im Fontspec-Code (sagt dieser bescheidene Benutzer). Ich habe alles entfernt, \__fontspec_pass_args:nnnwas in meinem eigenen Code vorkam. Dann musste ich für meine Schriftdefinitionen, anders als vorher, die Optionsklammern verwenden (selbst wenn keine Funktion benötigt wurde): \SetBaseFont[]{Some Font}und jetzt wird mein Code kompiliert. Glücklicherweise war das, was der Problemcode tut, nichts, was ich brauchte. Beachten Sie, dass ich ähnlichen Code für Schriftarten mit viel einfacheren Definitionen verwendet habe, es geht also nicht um \long\xdefoder so etwas.
WEITERE BEARBEITUNGEN:
In der Protokolldatei (nachdem ich meinen Code durch Bearbeiten wie oben beschrieben kompiliert hatte) sehe ich zahlreiche Meldungen, die wie die folgenden aussehen. Ich kann mich nicht erinnern, sie schon einmal gesehen zu haben, aber vielleicht ist es mir einfach nicht aufgefallen. Da TUes sich auf die Schriftartspezifikation bezieht, hier ein Beispiel. Das Problem wurde tatsächlich von Microtype erkannt. Alle von mir verwendeten Schriftarten sind Open Type:
Package microtype Warning: Unknown slot number of character
(microtype) `\textgreater '
(microtype) in font encoding `TU' in protrusion list
(microtype) `T1-default'.
Vielleicht hängt das damit zusammen, vielleicht auch nicht.
NOCHMALS:
Meine Frage beantwortet sich eigentlich von selbst! Der Grund für fontspec_pass_argsden Fehler ist einfach, dass die neueste Version von Fontspec (2.5c, von vor drei Wochen) diesen Befehl nicht mehr hat. Wenn also andere mein Problem nicht haben, liegt das daran, dass sie den älteren Fontspec-Code nicht in ihrem eigenen Code nachahmen. Aber die seltsamen Meldungen über TU sind immer noch da und mysteriös.
Antwort1
Ihre Frage hat zwei Aspekte:
Die Microtype-/TU-Probleme werden in einem bald geplanten LaTeX2e-Update behoben.
Bezüglich Ihres Codefehlers verweise ich Sie auf den expl3-Programmierstilleitfaden (l3styleguide.pdf):
Private Funktionen (die beginnen
\__) sollten nicht zwischen Modulen verwendet werden.
Aber das ist wahrscheinlich eine zu kurze Erklärung:)
Die \__fontspec_pass_args:nnnFunktion wurde entwickelt, um optionale Argumente zu manipulieren, so dass Sie schreiben können
\fontspec[<options>]{fontname}
ODER
\fontspec{fontname}[<options>]
ABER NICHT
\fontspec[<options>]{fontname}[<options>]
Dies sah man, wie soll ich sagen,eher ungünstigunter den LaTeX3-Illuminaten im Chatroom tex.sx, weil es der allgemeinen Philosophie des xparsePakets widerspricht, eine konsistente Möglichkeit zum Umgang mit Befehlsargumenten bereitzustellen.
Daher hat es eine Weile gedauert, bis ich es fallen gelassen habe, vielleicht leider, und jetzt fontspecist auch die „doppelt optionale“ Form zulässig:
\fontspec[<options>]{fontname}[<options>]
Dies verwendet etwas in der Art von
\DeclareDocumentCommand \fontspec { O{} m O{} }
Im Code von Drittanbietern hätte es niemand jemals nötig haben sollen, das alte Verhalten von zu replizieren \__fontspec_pass_args:nnn.
Tatsächlich fontspecbietet die API eine Standardmethode zum Laden von Schriftarten ohne Verwendung interner \__-Befehle. Wenn dies nicht das gewünschte Ergebnis liefert, können Sie gerne eine Funktionsanforderung im Github-Repository einreichen.