<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Lieber Stephan, liebe Trennfreunde,<br>
den bisherigen Rückmeldungen entnehme ich, dass Interesse und
Einsatzbereitschaft vorhanden sind, die beschriebenen Projekte
voranzutreiben.<br>
<br>
Es sind sogar schon so viele Nachrichten eingetroffen, dass ich wohl
Wochen brauchen werde, um die alle zu beantworten ...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 26.09.20 um 16:48 schrieb Stephan
Hennig:</div>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<pre class="moz-quote-pre" wrap="">Zunächst, mir schwebt ein Wegzug von GitHub vor. Irgend welche Einwände
gegen <a class="moz-txt-link-rfc1738" href="https://codeberg.org"><URL:https://codeberg.org></a>?</pre>
</blockquote>
<br>
Nein, keine Einwände.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<pre class="moz-quote-pre" wrap="">Laut
<a class="moz-txt-link-rfc1738" href="https://meeting.contextgarden.net/2020/talks/2020-09-07-hans-luametatex/context-2020-luametatex.pdf"><URL:https://meeting.contextgarden.net/2020/talks/2020-09-07-hans-luametatex/context-2020-luametatex.pdf></a>
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?</pre>
</blockquote>
<br>
Von LMTX habe ich noch nie gehört.<br>
<br>
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.<br>
<br>
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.<br>
Auf LMTX oder eine andere TeX-Weiterentwicklung könnte man später
umsatteln, wenn sie sich durchsetzen sollte.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
Von vorn bis hinten!?<br>
Wenn das dein Anspruch ist, bin ich raus. Ein komplettes Handbuch
habe ich noch nie durchgelesen, sondern nur bei Bedarf die
relevanten Abschnitte konsultiert.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<pre class="moz-quote-pre" wrap="">Von LMTX und den weiteren Plänen dazu habe ich ebenfalls bis auf den
oben erwähnten Link keinerlei Ahnung.</pre>
</blockquote>
<br>
Das wäre ein Argument mehr, sich darauf vorerst nicht einzulassen.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Das gleichzeitige Prüfen eines Wortes gegen verschiedene Muster sollte
nicht allzu schwierig umzusetzen sein.</pre>
</blockquote>
<br>
Das vermute ich nämlich auch und leite hieraus eine klare Präferenz
für die Variante b ab.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Ich vermute, dass drei verschiedene Güteebenen für Trennstellen in der
Praxis für einen sehr ordentlichen Umbruch ausreichen
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Dazu braucht man ein aussagekräftiges Maß für die Ordentlichkeit eines
Umbruchs.</pre>
</blockquote>
<br>
Hier gilt: Das Auge entscheidet. Der Algorithmus hat sich nach der
Ästhetik zu richten, nicht umgekehrt.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<pre class="moz-quote-pre" wrap=""> 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. ...</pre>
</blockquote>
<br>
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).<br>
Ich gehe davon aus, dass diese Berechnungsformel von D. Knuth nach
sorgsamer Abwägung und unzähligen Versuchen aufgestellt wurde.<br>
Diese Formel pauschal zu kritisieren ist natürlich einfach, aber man
wird kaum ebenso einfach ein besseres Umbruchverfahren finden.<br>
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.<br>
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 ...<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">LuaTeX stellt dafür keine Verwaltungsmechanismen zu Verfügung (Stand
damals), aber das Paket luatexbase (o.ä.).</pre>
</blockquote>
<br>
Soweit ich sehe, ist das immer noch so.<br>
luatexbase wird offenbar nicht mehr gepflegt: Die aktuelle Version
ist von 2015.<br>
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.<br>
<br>
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.<br>
Falls also zwei Pakete den hyphenate-callback beanspruchten, könnte
auch ein Verwaltungsmechanismus nur eine Fehlermeldung ausgeben.
Gleichzeitig so und so trennen, geht nicht.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">und zweitens bei
Anwendung gewichteter Trennung diese konsequenterweise auch auf die
Spezialtrennungen ausgedehnt werden sollte.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
Ja, aber für die Spezialtrennungen existiert ja schon ein Prototyp
und bei Prototypen will ich nicht stehenbleiben.<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Eine Vereinigung von Spezial- und Normaltrennungen in einer Musterdatei
würde wiederum eine neue Datenstruktur erfordern ist daher als zu
aufwendig zu verwerfen.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
Ja.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
<a class="moz-txt-link-freetext" href="https://github.com/sh2d/padrinoma/blob/master/examples/patterns/hyph-de-1901-nonstd.pat.txt">https://github.com/sh2d/padrinoma/blob/master/examples/patterns/hyph-de-1901-nonstd.pat.txt</a>
Hast du zur Erzeugung ein Skript, Stephan?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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. :-)</pre>
</blockquote>
<br>
Oh! Dass du archäologisch tätig wirst, ist nicht unbedingt
erforderlich.<br>
Ich vermute, dass Günter das auch über „sprachauszug.py“ regeln
kann.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Damit diese Frage hier nicht untergeht, wäre sie vielleicht besser in
einer eigenen Diskussion aufgehoben?</pre>
</blockquote>
<br>
Ja. Die Diskussion gibt es ja schon; das braucht hier nicht weiter
besprochen zu werden.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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)?</pre>
</blockquote>
<br>
selnolig benutzt den LuaTeX-callback „ligaturing“ wie das
padrinoma-Beispiel es auch tut. selnolig fügt allerdings keinen ZWNJ
ein, sondern einen „whatsit“:<br>
<blockquote>local blocknode = node.new(whatsit, userdefined)<br>
blocknode.type = 100<br>
blocknode.user_id = identifier<br>
</blockquote>
selnolig benutzt ebenfalls Muster, aber keine liangschen (siehe
selnolig-german-patterns.sty).<br>
Das Weitere kann in der ausführlichen Paketanleitung nachgelesen
werden.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
Ich probiere das aus.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<pre class="moz-quote-pre" wrap="">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?</pre>
</blockquote>
<br>
Für diese Frage mache ich einen neuen Faden auf.<br>
<br>
<blockquote type="cite"
cite="mid:a1464909-5961-efc9-5ab8-1e542a55f5c5@posteo.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Das müsste LuaTeX mit lccodes erklärt werden können. Ist aber kein
Gebiet, auf welchem ich mich gut auskenne.</pre>
</blockquote>
<br>
Ich auch nicht. Kann da jemand helfen?<br>
<br>
Gruß<br>
Keno<br>
</body>
</html>