[Trennmuster] Alternative Trennmusterverwendung mit LuaTeX

[Keno Wehr]

Lieber Stephan, liebe Trennfreunde,
den bisherigen Rückmeldungen entnehme ich, dass Interesse und 
Einsatzbereitschaft vorhanden sind, die beschriebenen Projekte 
voranzutreiben.

Es sind sogar schon so viele Nachrichten eingetroffen, dass ich wohl 
Wochen brauchen werde, um die alle zu beantworten ...


Am 26.09.20 um 16:48 schrieb Stephan Hennig:
> Zunächst, mir schwebt ein Wegzug von GitHub vor.  Irgend welche Einwände
> gegen<URL:https://codeberg.org>?

Nein, keine Einwände.

>> 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.

Das ist natürlich ärgerlich; ich glaube aber dennoch, dass LuaTeX die 
zur Zeit am besten geeignete TeX-Variante für unsere Ziele darstellt. 
Ich nehme das Risiko in Kauf, das Projekt wieder aufzugeben, falls es 
mit den Callbacks gar nicht hinhaut.

> 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?

Von LMTX habe ich noch nie gehört.

Mir wäre es wichtig, auf absehbare (wenn auch unbestimmte) Zeit 
praktisch anwendbare (das heißt für jedermann leicht verfügbare und 
anwendbare) Ergebnisse zu erzielen, damit die schönen differenzierten 
Trennstellenauszeichnungen in der Wortliste, in die schon so viel Arbeit 
investiert wurde und über die schon so viel diskutiert wurde, endlich 
einen wirklichen Nutzen bekommen.

Ich würde für die Entwicklung einer ersten praktisch anwendbaren 
Paketversion daher lieber auf LuaTeX als auf LMTX setzen, da stabiler 
und weiter verbreitet.
Auf LMTX oder eine andere TeX-Weiterentwicklung könnte man später 
umsatteln, wenn sie sich durchsetzen sollte.

> 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 vorn bis hinten!?
Wenn das dein Anspruch ist, bin ich raus. Ein komplettes Handbuch habe 
ich noch nie durchgelesen, sondern nur bei Bedarf die relevanten 
Abschnitte konsultiert.

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

Das wäre ein Argument mehr, sich darauf vorerst nicht einzulassen.

>> 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.

Das vermute ich nämlich auch und leite hieraus eine klare Präferenz für 
die Variante b ab.

>> 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.

Hier gilt: Das Auge entscheidet. Der Algorithmus hat  sich nach der 
Ästhetik zu richten, nicht umgekehrt.

>    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.  ...

Dass die Penalties in die 3. Potenz erhoben werden, stimmt nicht; in die 
3. Potenz wird das Verhältnis aus tatsächlicher Dehnung und Dehnbarkeit 
bei der Berechnung der „badness“ erhoben. „badness“ der Zeile und 
„penalty“ der Umbruchstelle gehen quadratisch in die Demerit-Berechnung 
ein (siehe TeX-Book, S. 97/98).
Ich gehe davon aus, dass diese Berechnungsformel von D. Knuth nach 
sorgsamer Abwägung und unzähligen Versuchen aufgestellt wurde.
Diese Formel pauschal zu kritisieren ist natürlich einfach, aber man 
wird kaum ebenso einfach ein besseres Umbruchverfahren finden.
Aus Sicht des Deutschsprachigen krankt der knuthsche Umbruch vor allem 
daran, dass alle Trennstellen gleichgewichtet werden. Das ließe sich 
aber über ein differenzierteres Vorgehen bei der Einfügung der penalties 
für die potentiellen Trennstellen beheben, ohne dass der 
Umbruchalgorithmus selbst angetastet werden müsste.
Ein neuer Umbruchalgorithmus wäre zwar auch eine reizvolle 
Aufgabenstellung, aber ich fürchte, dass wir uns damit verheben würden 
und die Auslieferung eines brauchbaren Ergebnisses sich ad infinitum 
hinziehen würde. Man müsste ja dann auch mathematische Formeln 
einbeziehen ...

>> 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.ä.).

Soweit ich sehe, ist das immer noch so.
luatexbase wird offenbar nicht mehr gepflegt: Die aktuelle Version ist 
von 2015.
Stattdessen gibt es jetzt ltluatex, das den Großteil der Funktionalität 
(und auch den Lua-Namensbereich „luatexbase“) übernimmt und Bestandteil 
des LuaLaTeX-Kernels ist.

Es gibt in LuaTeX callbacks, mit denen zusätzliche Funktionen eingefügt 
werden können (z. B. pre_linebreak_filter) und andere, die eine 
bestimmte TeX-Funktion ersetzen (z. B. hyphenate). Für den zweiten 
callback-Typ kann nur *eine* Funktion hinterlegt werden.
Falls also zwei Pakete den hyphenate-callback beanspruchten, könnte auch 
ein Verwaltungsmechanismus nur eine Fehlermeldung ausgeben. Gleichzeitig 
so und so trennen, geht nicht.

>> 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.

Ja, aber für die Spezialtrennungen existiert ja schon ein Prototyp und 
bei Prototypen will ich nicht stehenbleiben.
Früher oder später wird man die gewichteten Trennungen mit den 
Spezialtrennungen zusammenbringen müssen. Ich vermute sehr, dass 
unabhängige Pakete aufgrund der Exklusivität des hyphentate-callbacks 
nicht funktionieren würden; es muss einen gemeinsamen Code für beides geben.

>> 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.

Ja.

>> 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. :-)

Oh! Dass du archäologisch tätig wirst, ist nicht unbedingt erforderlich.
Ich vermute, dass Günter das auch über „sprachauszug.py“ regeln kann.

>> 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?

Ja. Die Diskussion gibt es ja schon; das braucht hier nicht weiter 
besprochen zu werden.

>> 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)?

selnolig benutzt den LuaTeX-callback „ligaturing“ wie das 
padrinoma-Beispiel es auch tut. selnolig fügt allerdings keinen ZWNJ 
ein, sondern einen „whatsit“:

    local blocknode = node.new(whatsit, userdefined)
    blocknode.type = 100
    blocknode.user_id = identifier

selnolig benutzt ebenfalls Muster, aber keine liangschen (siehe 
selnolig-german-patterns.sty).
Das Weitere kann in der ausführlichen Paketanleitung nachgelesen werden.

>> 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 probiere das aus.

> 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?

Für diese Frage mache ich einen neuen Faden auf.

>> 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.

Ich auch nicht. Kann da jemand helfen?

Gruß
Keno
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/trennmuster/attachments/20200930/9d818cc9/attachment.htm>