[Trennmuster] Alternative Trennmusterverwendung mit LuaTeX

[Guenter Milde]

Liebe Trennfreunde,

On 26.09.20, Stephan Hennig wrote:
> Am 25.09.20 um 22:52 schrieb Keno Wehr:

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

Nein. Andererseits bedeutet es noch ein Nutzerkonto mehr, falls man dort
mitarbeiten will. Das spräche für Leute aus der Trennmustergruppe für
repo.or.cz

> > Zu 1:
> > Zur Unterscheidung von Trennungen unterschiedlicher Güte sind 
> > verschiedene Vorgehensweisen denkbar.

...

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

Letztendlich läuft es auf ein Antesten der verschiedenen Ansätze hinaus.

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

Ja, ich denke die Projekte müssen kompatibel aber nicht unbedingt "aus einem
Guss" sein. Entscheidend ist eine "Aufrufkette" für die Hooks.


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

Bei der Aufbereitung der Wortliste zu patgen-Eingabedateien mache ich gern
mit.

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

Da müsste ein "Trennfilter" für sprachauszug.py leicht zu machen sein, wenn
klar ist was genau gewollt ist.

... 
... [Ligatur im eigenen Thread] 
...

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

An den Lang-S Skripten habe ich lange nicht mehr gearbeitet. Nach all den
Änderungen an der Worlistenauszuichnung (Gesangstexttrennungen...) ist da
eine gründliche Durchsicht dran, bevor es wieder sinnvoll verwendet werden
kann.

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

Eine Suche nach "s vor Trennstelle" reicht definitiv nicht (Gegenbeispiel
eſſen vs. Hausſchlüſſel). Auch "s vor [<=>]" reicht noch nicht, da es
reguläre Schluss-S-Fälle vor "-" und viele Ausnahmen und Sonderfälle
gibt. Mit den de-1901-Latf Mustern müsst dagegen die Ersetzung "alle
klein S zu Lang-S, außer am Schluss und vor Pseudo-Trennstelle" das
gewünschte Ergebnis zeigen.  Dazu gibt es die Python-Implementierung in
skripte/python/patuse/de_Latf_conversion.py.



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

Das am Makefile Verbesserungsbedarf besteht, sehe ich auch so. Wer, wie,
wann das passiert sollte einen eigenen Thread wert sein.

Vielleicht wären ja Unter-Makefiles in den verschiedenen Unterverzeichnissen
sinnvoll. Andererseits haben wir da noch die halbfertige Baustelle der
Umsortierung der Skripte... :(

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

Zumindest bei "make all", wenn einige der Muster schon aktuell sind.


Günter