[Trennmuster] Callbacks

[Keno Wehr]

Am 01.10.20 um 02:38 schrieb Stephan Hennig:
> Am 30.09.20 um 15:36 schrieb Keno Wehr:
>
>> 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.
> Ich dachte, luatexbase bzw. ltluatex würde die Callbacks exklusiv
> reservieren (solange niemand dazuwischenfunkt) und dann verschiedenen
> Interessenten geordneten Zugriff darauf gestattet.  Ist das nicht so?
> Ich habe das nicht mehr parat.

Im Prinzip ja, aber bei exklusiven Callbacks wie „hyphenate“ und 
„ligaturing“ kann nur eine Funktion angewandt werden.

Ich habe das mit den Padrinoma-Paketen „pdnm_hyph-mark-by-color.sty“ und 
„pdnm_hyph-mark-by-glyph.sty“ ausprobiert, die beide den Callback 
„hyphenate“ brauchen. Man kann zwar beide Pakete laden, wirksam ist aber 
immer nur das zuerst geladene Paket.
Wird „pdnm_hyph-mark-by-color.sty“ zuerst geladen, so werden die 
Buchstaben um die Trennstelle farbig markiert, wird 
„pdnm_hyph-mark-by-glyph.sty“ zuerst geladen, so wird an der Trennstelle 
ein Mittepunkt gesetzt. Beides gleichzeitig passiert nicht.

Dass zwei konkurrierende Trennalgorithmen nicht gleichzeitig angewandt 
werden können, finde ich wenig überraschend, insbesondere wenn man sich 
vor Augen hält, dass beide zunächst den Standard-TeX-Trennalgorithmus 
aufrufen. Woher soll die Maschine wissen, wie beide Algorithmen zu 
kombinieren sind?

Eher überraschend ist dagegen die Tatsache, dass keinerlei Fehlermeldung 
auftaucht, auch nicht in der Log-Datei. Die zweite Funktion, die für den 
Callback registriert wird, wird einfach ignoriert.


Am 02.10.20 um 09:55 schrieb Guenter Milde:
>> 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.
> Dann ist es Zeit für einen Master callback: ein "Ersatz-callback" (z.B.
> hyphenate) kann weitere callbacks bereithalten.
>
> Statt eines komplexen Gesamtpakets schwebt mir da eher ein plug-in
> Mechanismus vor.

Das scheint mir ein Holzweg zu sein. So einen „Master-Callback“ zu 
implementieren wäre vermutlich komplizierter als das „komplexe 
Gesamtpaket“, das gerade einmal zwei verschiedene Arten der 
Trennstelleneinfügung kombinieren müsste.

Ich meine, dass wir für das Gesamtprojekt zwei LaTeX-Pakete brauchen: 
eines für gewichtete Trennung und AR-Spezialtrennung (Callback 
„hyphenate“) und eines für Ligaturaufbruch und Lang-s-Ersetzung 
(Callback „ligaturing“).
Beide Pakete haben spezifische Anforderungen an die Kombination der 
beiden Knotenlistenmanipulationen.

Gewichtete Trennungen auf der Grundlage gewöhnlicher Trennmuster und 
Spezialtrennungen konkurrieren insofern nicht, als sie sich auf 
unterschiedliche Stellen im Wort beziehen; doch ist sicherzustellen, 
dass die durch den einen Algorithmus eingefügten Trennstellen das 
Einfügen durch den anderen Algorithmus nicht behindert. (Man beachte 
beispielsweise, dass „Abbauergebnis“ mit unseren Mustern 
„Ab-bau-ergeb-nis“ getrennt wird, „Abbau"-ergebnis“ mit expliziter 
Trennstelle hingegen das unerwünschte „Ab-bau-er-geb-nis“ ergibt). 
Zusätzlich ist bei gewichteter Trennung in „Kontrollücke“ die 
Spezialtrennung „Kontroll-lücke“ mit weniger Strafpunkten zu versehen 
als die Spezialtrennung „Kontrollük-ke“. Hier gibt es also 
Wechselwirkungen, die einen integrierten Ansatz nahelegen.

Beim Lang-s muss sichergestellt werden, dass die Ersetzung vor dem 
Standardligierungsalgorithmus erfolgt, da ſ und s unterschiedliche 
Ligaturen bilden können. Wenn erst ein Algorithmus Bindehemmer einfügt 
und dann die TeX-Ligierung aufruft, und dann ein anderes Paket, das 
dummerweise zu spät geladen wurde, daherkommt und eine Lang-s-Ersetzung 
vornehmen will, ist es zu spät. In diesem Fall würden dann die 
ſ-Ligaturen nicht gesetzt werden, selbst wenn der Algorithmus noch zur 
Ausführung kommt. Umgekehrt das Gleiche: Wenn erst ein Paket eine 
Lang-s-Ersetzung vornimmt und dann die Ligierung aufruft, ist es für die 
ZWNJs zu spät.

Man kann zwar auch erst mal alles separat implementieren, aber dann ist 
es Essig mit der Kombinierbarkeit.

Oder sehe ich das ganz falsch?

Keno