[Trennmuster] Alternative Trennmusterverwendung mit LuaTeX

[Stephan Hennig]

Am 25.09.20 um 22:52 schrieb Keno Wehr:

> Auf meine Frage nach einer Lua-Implementierung eines Trennalgorithmus 
> auf der TeX-hyphen-Liste sind zwei Antworten eingegangen:
> 
> Stephan Hennig weist auf sein padrinoma-Projekt hin 
> (https://github.com/sh2d/padrinoma), das erfreulicherweise weitestgehend 
> meiner Intention entsprechen zu scheint und in dem offenbar bereits ein 
> Großteil des benötigten Lua-Codes fertig vorliegt, ohne dass er bisher 
> auf dem CTAN veröffentlicht worden wäre.

Öffentlich verfügbar ist der Code ja.  Für eine CTAN-Paketierung
erschien er mir aber nie ausgereift genug.  Dazu später sicher mehr.


> Daher würde ich einstweilen gerne den von Stephan eingeschlagenen Weg 
> fortsetzen und biete hiermit meine Mitarbeit am padrinoma-Projekt an.

Herzlich willkommen!


> Bevor es sich lohnt, am konkreten Lua-Code weiterzuarbeiten, sollten wir 
> einige grundsätzliche Überlegungen zur Umsetzung anstellen.

Zunächst, mir schwebt ein Wegzug von GitHub vor.  Irgend welche Einwände
gegen <URL:https://codeberg.org>?  Das scheint von einem in Deutschland
eingetragenen Verein organisiert zu sein und basiert auf Gitea.  Womit,
anders als bei repo.or.cz, ein Issue-Tracker zur Verfügung steht.

Wie man bei GitHub Schreibrechte vergibt, hätte ich mir sowieso ansehen
müssen.  Daher erscheint dies ein guter Zeitpunkt für einen Umzug.  Um
im Gegenzug die Sichtbarkeit zu erhöhen, könnte ein Upload von padrinoma
auf CTAN dann nicht schaden. :-)


> Zu 1:
> Zur Unterscheidung von Trennungen unterschiedlicher Güte sind 
> verschiedene Vorgehensweisen denkbar.
> 
> Variante a)
> LuaTeX bietet einen callback namens „linebreak_filter“, der es 
> ermöglicht, den Zeilenumbruchalgorithmus zu ersetzen. Hiermit müsste 
> sich das beschriebene Verfahren prinzipiell umsetzen lassen. Dies wäre 
> nach meiner Einschätzung allerdings ein immenser Programmieraufwand, da 
> es hier um ein Herzstück von TeX geht.

Ich denke, dass so etwas als Spielwiese tatsächlich helfen würde.  Mit
den Callbacks in LuaTeX bin ich nie richtig warm geworden.  Ich erinnere
mich, dass das Anschlagen oder Ausbleiben der Callbacks für mich nie
vorhersehbar war bzw. es nicht so Zuverlässig zu steuern war, wie ich es
gern gehabt hätte.

Laut
<URL:https://meeting.contextgarden.net/2020/talks/2020-09-07-hans-luametatex/context-2020-luametatex.pdf>
ist die Entwicklung von LuaTeX mehr oder weniger zum Stehen gekommen, um
Stabilität zu gewährleisten.  Die weitere Entwicklung findet als
LuaMetaTeX (LMTX) statt.  Das ist einerseits positiv in dem Sinne, dass
existierender Code durch Änderungen an LuaTeX nicht entwertet wird.
(Ich hatte auf der tex-hyphen-Liste schon meine Verwunderung darüber
erwähnt, dass der padrinoma-Code mit einer geringen Änderung immer noch
läuft.)  Andererseits kann es sein, dass erst mit LMTX eine Loslösung
von der doch teils kruden Arbeitsweise von TeX erfolgt.  Vielleicht
würde LMTX daher eine günstigere Zielplattform darstellen als LuaTeX?

Allerdings habe ich die TeX-Entwicklung längere Zeit nicht verfolgt.
Ein Blick in das LuaTeX-Handbuch sagt mir, dass dieses erheblich
erweitert wurde.  Bei den Callbacks finde ich zwar nichts, was mir
jubelnd ins Auge springt, aber die Dokumentation erscheint mir insgesamt
deutlich mit Beispielen angereichert zu sein.  Ich müsste das Handbuch
sowieso nochmal neu von vorn bis hinten durchlesen, was derzeit aber
nicht in Frage kommt.

Von LMTX und den weiteren Plänen dazu habe ich ebenfalls bis auf den
oben erwähnten Link keinerlei Ahnung.


> Variante b)
> Die Grundidee ist hier, nicht mehr alle Trennstellen gleich zu bewerten, 
> sondern den penalty-Wert umso kleiner zu machen, je günstiger die 
> Trennstelle ist.
> [...]
> Trennstellen, die in allen Mustern enthalten sind, würden dann die 
> wenigsten Strafpunkte erhalten, Trennstellen, die nur in den Mustern mit 
> den ungünstigsten Trennstellen enthalten sind, die meisten. Prinzipiell 
> können beliebig viele Güteebenen berücksichtigt werden.
> 
> Mit ist keine Implementierung einer dieser beiden Varianten bekannt, 
> aber mit dem Code aus dem padrinoma-Projekt ist der Variante b ein gutes 
> Stück vorgearbeitet. Soweit ich es im Moment beurteilen kann, müsste nur 
> noch der Vergleich der Trennstellen aus unterschiedlichen Mustersätzen 
> und die daraus resultierende Wichtung der Trennstellen umgesetzt werden.

Das gleichzeitige Prüfen eines Wortes gegen verschiedene Muster sollte
nicht allzu schwierig umzusetzen sein.


> Ich vermute, dass drei verschiedene Güteebenen für Trennstellen in der 
> Praxis für einen sehr ordentlichen Umbruch ausreichen

Dazu braucht man ein aussagekräftiges Maß für die Ordentlichkeit eines
Umbruchs.  Die Demerits von TeX taugen dazu leider wenig.  Penalties in
die dritte Potenz erhoben (wenn ich mich recht erinnere) o.ä., sind
alles andere als anschaulich und für feine Abwägungen ungeeignet.  Auch
das ließe sich mit einer eigenen Lua-Implementierung des Absatzumbruchs
beheben.  ...


> Zu 2:
> Die Spezialtrennungen sind im padrinoma-Projekt bereits implementiert. 
> Dabei wird auf den bereits genannten LuaTeX-Callback „hyphenate“ 
> zurückgegriffen, in den nach einer standardmäßigen Worttrennung die 
> Spezialtrennungen eingefügt werden.
> Wenn man das mit der Nr. 1 zusammensieht wird klar, dass beide Projekte 
> gemeinsam implementiert werden müssen, da sie erstens den gleichen 
> Callback benötigen (bei unabhängiger Implementierung würde vermutlich 
> der eine Algorithmus den anderen überschreiben)

LuaTeX stellt dafür keine Verwaltungsmechanismen zu Verfügung (Stand
damals), aber das Paket luatexbase (o.ä.).


> und zweitens bei 
> Anwendung gewichteter Trennung diese konsequenterweise auch auf die 
> Spezialtrennungen ausgedehnt werden sollte.

Ich würde es zunächst etwas weniger ambitioniert angehen.  Wenn für alle
Probleme isolierte, prototypische Lösungen bestehen, kann man darüber
nachdenken, wie man die dann zusammenbringt.


> Eine Vereinigung von Spezial- und Normaltrennungen in einer Musterdatei 
> würde wiederum eine neue Datenstruktur erfordern ist daher als zu 
> aufwendig zu verwerfen.

Sehe ich auch so.  Am Dateiformat der Muster würde ich nichts ändern.
Da ein Mustersatz immer nur eine Ja/Nein-Aussage bezüglich einer
Position innerhalb eines Wortes geben kann, läuft das dann auf einen
Strauß von Mustern hinaus.  Aber das lässt sich gut durchschauen,
dokumentieren und automatisieren.


> Mein Hauptanliegen zu dieser Thematik wäre ein Skript im 
> Wortlistenrepositorium, das die Spezialtrennmuster erzeugen kann; soweit 
> ich sehe, gibt es das bisher nicht.
> Im padrinoma-Repositorium gibt es einen sechs Jahre alten 
> Spezialtrennmustersatz: 
> https://github.com/sh2d/padrinoma/blob/master/examples/patterns/hyph-de-1901-nonstd.pat.txt
> Hast du zur Erzeugung ein Skript, Stephan?

Das kann ich leider nicht sagen.  Das liegt alles auf einem anderen
Rechner, von dem ich auch noch ein paar andere Sachen bergen müsste.
Hier gab es einen Betriebssystemwechsel, der sich über mehrere Rechner
hinwegzog, was Spuren hinterlassen hat. :-)


> Die gewählte Methode hat allerdings ein anderes Problem: Es können nur 
> die Aufbruchstellen berücksichtigt werden, die in der Wortliste als 
> Fugen (< oder =) markiert sind. Im Duden (2006, S. 112) sind weitere 
> Ligaturaufbrüche vorgesehen: »Eine Ligatur wird nur gesetzt, wenn die 
> Buchstaben im Wortstamm zusammengehören.« Keine fl-Ligatur will der 
> Duden in »ich schaufle« und keine ft-Ligatur in »ich kaufte« sehen.
> In der Dokumentation zum nicht mehr gepflegten Skript 
> „prepare-ligature-wordlist.py“ schreibt Lukas Sommer:

Damit diese Frage hier nicht untergeht, wäre sie vielleicht besser in
einer eigenen Diskussion aufgehoben?


> Eine andere Überlegung ist, ob es überhaupt noch ein 
> Ligaturaufbruchpaket braucht, da es mit selnolig bereits ein recht gutes 
> gibt.
> Wir könnten überlegen, das uns in der Wortliste zur Verfügung stehende 
> Material zur systematischen Fehlersuche und -meldung an den 
> selnolig-Betreuer statt zur Implementierung eines eigenen Pakets zu 
> verwenden.

Wenn du nochmal zusammenfassen könntest, wie das Paket funktioniert?  An
welchem Punkt greift das ein?  Lässt sich das mit den restlichen
Problemen später unter einen Hut bringen (Rund-s-Ersetzung,
Dreikonsonantenregel mit f oder l)?


> Zu 4:
> Für die Rund-s-Lang-s-Ersetzung können die vorhandenen Skripte bereits 
> Pseudotrennmuster erstellen. Ohne diese getestet zu haben, ist mein 
> Eindruck, dass die Skripte weitgehend ausgereift sind.
> Das padrinoma-Projekt kann zweifellos im Hinblick auf die Anwendung 
> dieser Muster weiterentwickelt werden. Ein geeigneter LuaTeX-callback 
> wäre noch zu suchen.

Es gibt auch ein Beispiel im Zweig ex-long-s.  Die eigentlichen Muster
scheinen allerdings nicht dabei zu sein.  Du könntest es mal mit den
Mustern examples/patterns/hyph-de-1901-joint.pat.txt ausprobieren (wie
benötigt umbenennen).  Es wird vorher geprüft, ob es sich bei einem
fraglichen Glyphen tatsächlich um ein s handelt und nur dann ersetzt:

        if n.char == 0x73 ...
           n.char = 0x017f

Daher könnte das klappen.

Ich hielte es für hilfreich, Muster für gewisse Anwendungsfälle nicht
nur per Makefile erreichbar zu machen (ich sehe im Makefile ehrlich
gesagt nicht mehr durch), sondern Shellskripte zu erstellen, welche die
benötigten make-Kommandos konservieren/dokumentieren.

Beziehungsweise, ist ein Makefile für unseren Anwendungsfall überhaupt
sinnvoll?  Können damit denn irgend welche Zwischenschritte eingespart
werden?


> Außerdem stellt sich die Frage, ob für Texte mit Lang-s eigene 
> Trennmuster erforderlich sind oder TeX dazu überredet werden kann, bei 
> der Trennung ſ wie s zu behandeln.

Das müsste LuaTeX mit lccodes erklärt werden können.  Ist aber kein
Gebiet, auf welchem ich mich gut auskenne.

Viele Grüße,
Stephan Hennig