☰

Verschieben von Luacode in eine Lua-Datei, Zugreifen auf Glyphen nach Namen

tag-icon • tag-icon symbols luatex unicode luaotfload
Verschieben von Luacode in eine Lua-Datei, Zugreifen auf Glyphen nach Namen

Ich habe ein Paket, das (im Wesentlichen) den folgenden Code enthält (von einem Mitwirkenden auf Anfrage bereitgestellt)diese Frageauf tex.stackoverflow).

\begin{luacode}
  documentdata = documentdata or { }
  documentdata.fontchar = function (chr)
    local chr = luaotfload.aux.slot_of_name(font.current(), chr, false)
    print(chr)
    if chr and type(chr) == "number" then
      tex.sprint(string.format([[\char"%X]], chr))
    end
  end
\end{luacode}
\def\fontchar#1{\directlua{documentdata.fontchar "#1"}}

Diese Funktion sucht anhand des Namens nach einem Glyph einer Schriftart und druckt ihn in das TeX-Dokument.

Ich beginne gerade damit, das Paket in ein reines Lua-Paket umzuwandeln und möchte den Code in eine separate Lua-Datei verschieben. (Irgendwann sollte die Funktionnichtverwenden tex.sprint, aber eine Zeichenfolge zurückgeben, und ich würde gerne wissen, ob es möglich ist, solche Glyphen über Lua weiterzugeben, aber das ist ein Folgeproblem).

Wenn ich jedoch eine meiner Meinung nach korrekte Übersetzung mache, erhalte ich eine Fehlermeldung:

local character = {}

function character.char_by_name(name)
    local chr = luaotfload.aux.slot_of_name(font.current(), name, false)
    if chr and type(chr) == "number" then
      tex.sprint(string.format([[\char"%X]], chr))
    else
        tex.sprint('f') -- 'forte' character to show "not found"
    end
end

return character

Da steht luaotfload | aux : invalid parameters to slot_of_name (16, nil)false. Das klingt eigentlich vernünftig, wenn man bedenkt, dass die Dokumentation aux.slot_of_nameim luaotfloadHandbuch aux.slot_of_name(name : string)als Signatur der Funktion angibt. Angesichts dieser Dokumentation frage ich mich, warum das in dieser luacodeUmgebung überhaupt funktioniert hat.

Hier ist das komplette MWE. Ich nehme an, dass es kompiliert werden kann, wenn lilyglyphs(oder die Musiksammlung) in TeX Live installiert wird, da es die verwendete spezielle Schriftart mit installiert. Dies ist die .texDatei, in der das obige Lua-Beispiel gespeichert ist character.lua:

\documentclass{scrartcl}
\usepackage{luaotfload,luacode}

\begin{luacode}
  documentdata = documentdata or { }
  documentdata.fontchar = function (chr)
    local chr = luaotfload.aux.slot_of_name(font.current(), chr, false)
    if chr and type(chr) == "number" then
      tex.sprint(string.format([[\char"%X]], chr))
    end
  end
\end{luacode}
\def\fontchar#1{\directlua{documentdata.fontchar "#1"}}

% Alternative implementation in Lua file
\directlua{lua_char = require('character.lua')}
\newcommand{\luafontchar}[1]{\directlua{lua_char.char_by_name(#1)}}

\font\mainfont="emmentaler-11" at 20pt

\begin{document}
    \mainfont
    \noindent
    \fontchar{clefs.C}\\
    \fontchar{clefs.G}\\
    \fontchar{flags.u7}

    \bigskip
    \luafontchar{Something}
\end{document}

Die Aufrufe zum \fontcharErzeugen der erwarteten Glyphen aus der Schriftart Emmentaler \luafontcharverursachen den genannten Fehler und drucken die Fallback-Glyphe.

Ergebnisse

verwandte Informationen