[Trennmuster] Alternative Trennmusterverwendung mit LuaTeX

[Keno Wehr]

Lieber Stephan, liebe Freunde der automatisierten Typographie,

bei der momentan besprochenen Weiterentwicklung von TeX in Bezug auf 
sprachspezifische Typographie auf der Grundlage von Trennmustern stellt 
sich die Frage, inwieweit andere Sprachen als Deutsch mit ins Auge 
gefasst werden sollten.

Einige bisherige Diskussionsbeiträge legen nahe, dass die angedachten 
Entwicklungen für viele weitere Sprachen von Interesse sein könnten. Ich 
bezweifle das.

Ich sehe unsere Pläne vornehmlich als Projekt für die deutschsprachige Welt.
Das oder die Pakete, die wir veröffentlichen, sollten (auch) eine 
vollständige englischsprachige Anleitung bekommen, und der Code, den wir 
aufsetzen, sollte prinzipiell mit beliebigen Sprachen und den 
zugehörigen Trennmustersätzen umgehen können.

Dass es auf absehbare Zeit eine Nachfrage anderer Sprachgruppen geben 
wird, den Code zu nutzen, halte ich für unwahrscheinlich.
Man halte sich nur mal vor Augen, dass es – soweit mir bekannt ist – für 
keine andere Sprache als Deutsch etwas Vergleichbares zu unserem/Werners 
Wortlistenprojekt gibt. Nicht mal die Englischsprachigen haben so etwas.
Woher sollten denn da die Muster kommen, die es brauchen würde, etwa 
gewichtete Trennstellen einzusetzen?

Sich in Bezug auf vermutete Anforderungen fremder Sprachen eigene 
Beschränkungen aufzuerlegen, halte ich daher nicht für sinnvoll, 
natürlich – wie gesagt – bei prinzipieller Offenheit für andere 
Sprachgruppen mit entsprechenden Bedürfnissen.


Am 28.09.20 um 19:00 schrieb Stephan Hennig:
> Wenn zum Beispiel der Aufbruch von Dreifachligaturen steuerbar sein soll
> ({ffi} vs. f{fi}), dann müsste eine Schnittstelle dafür in den
> LaTeX-Code.  Dieses Problem betrifft vermutlich mehrere Sprachen.  Daher
> wäre ein LaTeX-Paket für den Ligaturaufbruch für alle Sprachen sinnvoll,
> in welchem dann auch die Muster verschiedener Sprachen kuratiert werden
> könnten.  Und vielleicht ebenso für Spezialtrennungen und das
> lange/runde s.  Ich habe davon noch keine rechte Vorstellung ...

Wie kürzlich bereits dargelegt bin ich der Meinung, dass es zumindest 
für langes/rundes s und Ligaturaufbruch ein einheitliches Paket geben 
müsste, da beide den „ligaturing“-Callback brauchen.
Ansonsten finde ich deine Überlegung durchaus sinnvoll; ich erwarte aber 
nicht, dass jemand außer uns da Muster einreichen wird.


Am 01.10.20 um 02:45 schrieb Stephan Hennig:
> Am 30.09.20 um 15:36 schrieb Keno Wehr:
>> Am 26.09.20 um 16:48 schrieb Stephan Hennig:
>>> 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.
> Das stimmt zwar.  Mit Prototyp meine ich aber wie zuletzt schon
> angedeutet nicht nur die Beispiele wie sie vorhanden sind, sondern
> vollwertige, anwenderfreundliche LaTeX-Pakete.  Mit denen, wie gesagt,
> das Aufbrechen von Dreifachligaturen gesteuert werden kann, oder welches
> auch sprachübergreifend funktioniert.  Das heißt, bei der Durchsicht der
> Knotenliste muss darauf geachtet werden, in welcher Sprache ein Wort
> vorliegt und gegebenenfalls müssen die richtigen Muster darauf
> angewendet werden. [...]

Sprachübergreifende Funktionsfähigkeit wäre übrigens auch schon 
innerdeutsch wichtig, da Babel allein sechs deutsche „Sprachen“ kennt 
(german, ngerman, austrian, ...).
Ich habe jetzt versucht, die Beispieldatei zum Ligaturaufbruch auch für 
die NR lauffähig zu machen. Wenn AR und NR im gleichen Dokument zum 
Einsatz kommen, funktioniert das aber nicht, da die Funktion 
„create_node_list_scanner“ in „pdnm_nl_manipulation.lua“ nur eine 
Sprache und einen Mustersatz als Argument akzeptiert. Wenn 
Ligaturaufbruch für mehrere Sprachen funktionieren soll, müssten da 
Arrays von Sprachen als Argument möglich sein.
Mehrere solcher Scannerfunktionen würden aufgrund der Problematik mit 
dem exklusiven Callback nicht helfen.

> Die Interpunktion verschiedener Sprachen wäre auch richtig zu behandeln.
>   Ich meine, einmal gelesen zu haben, im Französischen wäre das Apostroph
> teil eines Wortes und auch Teil der Muster.

Ja, siehe hier: 
https://ctan.org/tex-archive/language/hyph-utf8/tex/generic/hyph-utf8/patterns/quote

Die gewöhnlichen Trennmuster für die dort aufgeführten Sprachen 
enthalten allerdings auch Muster mit Apostroph. Darum ist mir nicht 
klar, warum es diese Extradateien gibt.

Arthur, kannst du das erklären?


>    So etwas muss (so es denn
> stimmt) bei der Erkennung von Wörtern berücksichtigt werden.

Aber nur, wenn solche Sprachen jemals Berührungspunkte mit unserem 
Projekt haben werden.

Nehmen wir mal das Französische: „Eisenbahngesellschaft“ heißt dort 
„société de chemin de fer“. Bei dieser Art der Wortbildung gibt es keine 
Notwendigkeit für gewichtete Trennungen und Ligaturaufbruch.
Ich wage mal zu behaupten, dass unsere Anliegen für romanische Sprachen 
allgemein völlig irrelevant sind.

> Wir haben noch viel zu wenig Erfahrung mit den Lösungsansätzen, um zu
> sehen, wo deren Schwächen sind.  Ich würde gern vermeiden, dass wir
> jetzt irgendeine integrierte Implementierung zusammendengeln und in drei
> Monaten kommt jemand, der eine sprachspezifische Eigenheit nicht
> abgedeckt sieht, woraufhin wir uns fragen, wie man das in den
> verquickten Code noch reinquetschen kann.  Wie verhält es sich zum
> Beispiel mit bidirektionalem Text?  Funktioniert damit die Worterkennung
> derzeit?  Muss das Patternmatching dafür angepasst werden?

Für welche linksläufige Sprache wäre denn welches unserer Vorhaben relevant?
Gibt es irgendeinen Anhaltspunkt, dass wir darauf Rücksicht nehmen müssen?


Am 01.10.20 um 02:50 schrieb Stephan Hennig:
> Ich glaube, für die Koordinierung der hier angedachten Entwicklung wären
> folgende Listen ungeeignet:
>
> * Die Trennmusterliste, weil die Entwicklung/Koordination auf Englisch
>    erfolgen sollte, hier aber (sinnvollerweise) sehr viel Verkehr in
>    deutscher Sprache stattfindet, was auf Nichtmuttersprachler störend
>    wirken kann.  Englische Diskussionen über LuaTeX-Interna würden
>    andererseits hier stören.
> * tex-hyphen wäre zwar für die Koordinierung auch von Mustern für
>    andere Zwecke als die Silbentrennung geeignet, allerdings wären
>    sonstige Diskussionen über LuaTeX-Interna dort, wie hier, eher fehl am
>    Platz.
> * Die LuaTeX-Liste ist zwar für technische Diskussionen über
>    Knotenlisten geeignet, aber weniger für Diskussionen über
>    sprachspezifische Rechtschreibregeln, das Erstellen von Mustern,
>    Anwenderschnittstellen in LaTeX o.ä.
>
> Daher schlage ich vor, über kurz oder lang eine neue Liste zu erstellen
> und bis dahin auch hier in die englische Sprache zu wechseln und den
> Betreff jeweils mit [padrinoma] o.ä. zu markieren, damit
> Diskussionsinhalte auch im Nachhinein vom Rest der Welt nachgelesen
> werden können.

Aus den genannten Gründen sehe in englischsprachigen Diskussionen unter 
deutschen Muttersprachlern keinen Gewinn, sondern eine unnötige Belastung.

Bei schwierigen Problemen kann man gezielt auf den von dir genannten 
anderen Listen nachfragen. Überschaubare Einzelanforderungen können auch 
in einem Codeberg-Issue zur Sprache gebracht werden (von mir aus auch 
dort auf Englisch).
Solange Werner uns nicht rauswirft, können wir ansonsten einfach hier 
bleiben, die Berührungspunkte zum Trennmusterprojekt sind ja offenkundig:
http://projekte.dante.de/Trennmuster/WebHome#Was_TeX_bislang_nicht_kann
http://projekte.dante.de/Trennmuster/TeilProjekte#Spezialmuster

Wichtiger als eine englischsprachige Diskussion scheint mir eine 
nachvollziehbare Dokumentation der getroffenen Entscheidungen (zum 
Beispiel innerhalb des Lua-Codes) zu sein.

Schöne Grüße
Keno